User Privacy & Data Protection

MyFoodRepo is designed with user data privacy at its core. The application does not collect any directly identifying personal information (name, email, phone number) from mobile app users.

User Authentication Without Personal Data

Mobile app users authenticate using a participation key provided by researchers or study coordinators. This key is used to link the user to a specific research cohort or study. The authentication process works as follows:

  1. Users receive a unique participation key (not an email address or password)
  2. When registering or logging in via the mobile app, users provide this participation key
  3. The system creates an anonymous user account with:
    • A randomly generated UUID as the user identifier
    • A system-generated email address in the format {uuid}@anonymous.myfoodrepo.org (not a real email)
    • A randomly generated password (not set or known by the user)
  4. These credentials are used internally by the authentication system (Devise Token Auth) but are not personal data - users never see or use these credentials directly

Collaborator Authentication

See Signing up as cohort manager for more details.

Collaborators (researchers, annotators, and administrators who access the web interface) use a different authentication system than mobile app users. Collaborators authenticate using:

  1. Email and password authentication: Collaborators sign in with their email address and password via the web interface
  2. Invitation-based access: New collaborators are invited by existing administrators or cohort managers via email invitations (using Devise Invitable). Invitations can specify the collaborator’s role within a cohort (manager or annotator)
  3. Two-factor authentication (2FA): WebAuthn is used as a second factor for collaborator authentication:
    • When a collaborator logs in with email and password, if they have at least one registered WebAuthn credential, they are signed out from the password-based session and redirected to complete WebAuthn authentication before being signed back in
    • A collaborator without any registered WebAuthn credential is allowed to authenticate with email/password, but every subsequent page in the collab interface redirects them to the “Add Passkey” form until they register one — registration is therefore an enforced setup step rather than a blocking step at login
    • Collaborators can add and delete their own WebAuthn credentials from their profile; deleting the last credential will trigger the same enforced registration flow on the next page load
    • This provides an additional layer of security for accessing sensitive research data and administrative functions
  4. Role-based access: Collaborators have different permission levels:
    • Sitewide roles: Basic, developer, or admin (controls system-wide access)
    • Cohort roles: Manager or annotator (controls access within specific research cohorts)

This two-tier authentication approach ensures that only authorized personnel can access the web interface while maintaining complete anonymity for mobile app users.

Data Collection

The primary data captured by the system concerns dishes (meals):

  • Dish pictures: Photographs of meals taken by users
  • Dish composition: Food items and their quantities consumed (annotations)
  • Consumption data: When and how much of each food item was consumed (intakes)
  • Optional descriptions: Free-text descriptions of dishes (optional)

In addition, the following non-identifying user data may be stored to operate the service:

  • App locale: The language code chosen in the mobile app (e.g., en, fr, de)
  • Push notification tokens: Opaque device tokens used to deliver mobile notifications
  • Cohort manager notes: Free-text notes written by cohort managers about a participant (e.g., “vegan”, “no lactose”); these should not contain directly identifying information
  • Dietary preferences: Free-text dietary preferences attached to a participation
  • Consumption timestamps and timezones: When meals were consumed and the device’s timezone at the time

User accounts are not linked to a name, email address, phone number, or precise location. They are identified only by system-generated UUIDs and a participation key. Cohort managers are responsible for keeping the participant ↔ participation key mapping outside of MyFoodRepo and for avoiding identifying content in free-text fields.

Deletion and Anonymization

Because mobile app accounts hold no directly identifying data, “deleting” such an account is an anonymization rather than an erasure:

  • From the mobile app: when a user deletes their account, the backend re-anonymizes it — a new random password is set, all authentication tokens are cleared, and the email is reset to the {uuid}@anonymous.myfoodrepo.org form. The dishes, annotations and intakes already collected are kept, since they carry no identifying data and are part of the study’s research record.
  • From the web interface: MyFoodRepo administrators can anonymize an account that is not yet anonymous, and can delete a user outright. A full deletion removes the user together with their dishes, annotations, intakes, comments and push tokens, and strips the user reference from the version history. It is only possible for a user with at most one participation.

Deleting a participant’s data is therefore a request to make to the MyFoodRepo team; cohort managers cannot delete a user from their cohort page.