Data subject requests

A person can ask to see, to correct, to erase or to get a copy of the personal data that a deployment or a hosting provider holds about them. This page tells, for each store that holds personal data, which party answers such a request, and which mechanism the code in this repository gives for it. Where the code gives no mechanism, the page says "no mechanism found".

This page is not legal advice. It does not tell if a request is valid, which data is in its scope, or how much time the answer can take. It tells only what the code can do.

The stores and their personal data are in Data protection. The part state-register has the full list of the state that the system stores. This page does not repeat these lists.

Who answers a request

The party that controls the data answers the request. Data protection gives the roles:

  • The operator is the controller of the data of its deployment: the accounts and the content of its applications, and the users of the lldap and of the Authelia of its group.
  • The hosting provider is the controller of its own data: the accounts of the panel, the users of the lldap of the hosting-provider group, the audit records, and the accounts of Grafana, NetBox and Windmill.
  • The hosting provider is the processor of the operator for the data of a deployment. For some stores of a deployment, only the hosting provider has a tool, for example a command on a node or a backup. Then the operator answers the request, and the hosting provider does the step.
flowchart TD
  request["Request of a person"] --> which{"Which data?"}
  which -->|"Data of a deployment"| operator["Operator answers"]
  which -->|"Data of the hosting provider"| provider["Hosting provider answers"]
  operator --> app["Functions of the application"]
  operator --> lldap["lldap of the group"]
  operator --> config["Configuration in the panel, for example deleteData"]
  operator -->|"asks for a step on a node, a log or a backup"| provider
  provider --> panel["Panel account page and admin pages"]
  provider --> api["Routes of api/"]
  provider --> node["Commands on a node, logs, backups"]

Mechanisms that the code gives

Mechanism Who uses it What it does
The account page of the panel The account /account/ shows the user name and the email address of the account. /account/history/ shows the audit events of the account (AccountDetail and AccountHistory in panel/src/panel/views.py).
The admin pages of the panel A panel administrator /admin/ shows, changes and removes an account (panel/src/panel/admin.py). Before a removal, the panel queues the destroy of each deployment of the account through api/. If api/ does not queue a destroy, the removal does not occur (_destroy_deployments in panel/src/panel/models.py).
GET /audit-events of api/ The party that the authorization callback permits It gives the audit events of one actor on all deployments (api/src/fediversity_api/routes/audit.py). With the panel, an account reads its own events, and a superuser reads the events of each account (reads_all_history in panel/src/panel/views.py).
/domain_contacts/{contact_id} of api/ The operator, through the Domain contact form of the panel GET gives the contact from the state, and PUT makes the contact at the registrar equal to the body (api/src/fediversity_api/routes/domains.py). DELETE deletes the customer at the registrar and the state, and refuses while a domain of the registrar account names the contact.
DELETE /deployments/{id} of api/ The operator, through the panel It destroys a deployment with all its data. See Know what a destroy keeps.
deleteData of an application The operator, in the configuration of the deployment With enable false and deleteData true, the next deployment deletes the database, the buckets, the generated secrets and the cache of the application (core/components/sharedOptions.nix). It deletes the data of all users of the application, not of one person.
The web UI of lldap A member of lldap_admin of the group lldap serves its web UI at https://users.<domain>/ (the label is in core/components/shared/lldap/ui-subdomain.nix). A member of lldap_admin manages each user of the group there. Without lldap_admin, the web UI shows a user only their own account (core/resources/ldap/lldap-provider.nix). The management functions are functions of lldap, which is not in this repository.
media-backup-<app> erase <bucket> <key> A person with a shell on the node of the application It removes one object from the media backup and from all of its history (core/resources/garage/media-backup.sh). No route of api/ and no page of the panel runs this command.
Retention No person The logs, the audit events, the jobs of Windmill and the backups expire after a period. See Know which personal data the logs keep and Know how long the backups keep personal data.

The panel and api/ have no route that finds, changes, erases or exports the data of one user of an application. The functions of the application do this work. This repository does not contain the code of the applications, thus this page does not describe these functions. Find them in the documentation of the application version that the deployment runs.

Data of a deployment

The operator answers a request about this data.

Store Access Rectification Erasure Export for one person
The database, the buckets and the local files of Mastodon, Pixelfed or PeerTube The functions of the application, by the user or by an administrator of the application. The code adds no mechanism. The functions of the application. The code adds no mechanism. The account deletion of the application. The operator settings ACCOUNT_DELETION and ACCOUNT_DELETE_AFTER of Pixelfed apply to it. deleteData erases the data of all users of the application. PeerTube: the operator can set export.users.enabled in settings (core/components/operator/peertube/default.nix). The code sets no value. Mastodon and Pixelfed: the functions of the application. The code adds no mechanism.
The cache of an application (the valkey of the group, or a local redis) No mechanism found. No mechanism found. No mechanism found for one person. deleteData deletes the cache of the application as a whole. No mechanism found.
The users of the lldap of the group The user reads their own account at https://users.<domain>/. A member of lldap_admin reads each user there. A member of lldap_admin changes the user there. A member of lldap_admin deletes the user there. No mechanism found.
The database of the Authelia of the group (consents, second factors, OIDC state) No mechanism found. No mechanism found. No mechanism found. No mechanism found.
The mail queue and the journal of the SMTP node of the group No mechanism found. No mechanism found. No mechanism found. The journal expires. No mechanism found.
The journal of the nodes of the deployment, and its copy in Loki No mechanism found for one person. The lines of one deployment have the label deployment_id in Loki. No mechanism found. No mechanism found for one person. The lines expire. No mechanism found.
The media backup of an application No mechanism found. A backup is only for a restore, see Erase personal data. No mechanism found. media-backup-<app> erase <bucket> <key> on the node, for each object. The hosting provider does this step. No mechanism found.
The restic backups (the databases, the local files, the caches) No mechanism found. No mechanism found. No mechanism for one record. An erased record stays until the backup expires, see Erase personal data. restic forget and prune remove whole snapshots before then. No mechanism found.
The *-backups buckets that a destroy keeps No mechanism found. No mechanism found. A timer deletes the bucket at the end of the grace period. An expires_at in the retention record deletes it earlier. No mechanism found.

After a restore from a backup that is older than an erasure, the erasure must be done again. The operation "Record an erasure" of an application keeps the time and the reference of each erasure on the node, and a restore from an older snapshot lists them until "Confirm the erasures". See Do the erasures again after a restore.

The export of a deployment for a migration gives all the data of the deployment to a different hosting provider, and stops its applications. It is not an export for one person. See Export a deployment for a migration.

Data of the hosting provider

The hosting provider answers a request about this data. The persons are the staff of the operators and the staff of the hosting provider.

Store Access Rectification Erasure Export for one person
The account of the panel The account reads /account/. A panel administrator reads the account at /admin/. A panel administrator changes the account at /admin/. The account page has no form for the user name or the email address. A panel administrator removes the account at /admin/. The removal also removes the deployments of the account, after the panel queued their destroy. The panel has no page where an account removes itself. No mechanism found.
The deployments of an account and their configuration, in the panel and in api/ The operator reads them in the panel. The operator changes the configuration in the panel. The operator deletes the deployment. The panel keeps the row of a deleted deployment (deleted_at in panel/src/panel/models.py) until the account is removed. No mechanism found.
The audit_event table of api/ /account/history/ of the panel, or GET /audit-events. No mechanism found. No mechanism found for one person. api/ removes the events that are older than its retention. No mechanism found.
The audit lines in the tenant audit of Loki No mechanism found for one person. No mechanism found. No mechanism found. This tenant refuses the deletion API of Loki (deletion_mode = "disabled" in core/components/hosting-provider/telemetry.nix). The lines expire. No mechanism found.
The domain contact of an operator (the OpenTofu state and the registrar) The operator reads it at Domain contact on the account page, through GET /domain_contacts/{contact_id}. The operator changes it in the same form, through PUT. A change of a name makes a new customer at the registrar. The call deletes the old customer, unless a domain names it. The operator erases it with "Erase contact" in the same form, through DELETE. The call refuses while a domain of the registrar account names the contact. The removal of the panel account erases it also. No mechanism found.
The users of the lldap of the hosting-provider group The user reads their own account at https://users.<domain>/. A member of lldap_admin reads each user there. A member of lldap_admin changes the user there. A member of lldap_admin deletes the user there. No mechanism found.
The database of the Authelia of the hosting-provider group No mechanism found. No mechanism found. No mechanism found. No mechanism found.
The accounts of Grafana, NetBox and Windmill The administration pages of each service. The code adds no mechanism. The administration pages of each service. The code adds no mechanism. The administration pages of each service. The code adds no mechanism. No mechanism found.
The jobs of Windmill No mechanism found for one person. No mechanism found. No mechanism found for one person. Windmill removes a completed job after services.fediversity-windmill.jobRetentionDays. No mechanism found.
The journal, Loki, the nginx access log and the audit lines of OpenBao No mechanism found for one person. No mechanism found. No mechanism found for one person. The lines expire. No mechanism found.
The backups of the databases of these services No mechanism found. No mechanism found. No mechanism found. An erased record stays until the backup expires. No mechanism found.

The removal of a panel account first erases the domain contact of the account. A contact that a domain of the registrar account names stays, and the panel writes a warning to its log. The removal does not remove the audit events of its actor or the user in lldap. Each of these is a different store with its own row in this table.

Where no mechanism exists

The code gives no mechanism for these requests:

  • An export of the data of one person, for all stores but the accounts of the applications. The export of a deployment is for the deployment as a whole (#3058).
  • Access, rectification or erasure for one person in the logs, the telemetry, the jobs of Windmill and the audit records. Only the retention removes this data. The account history of the panel gives access to the audit events of one actor (#3062).
  • Access, rectification or erasure in the database of Authelia and in the caches of the applications (#3061).
  • Erasure of one record from a restic backup before it expires. The procedure removes whole snapshots (#3060).
  • A page where a panel account removes itself, or changes its user name or email address (#3056).
  • One command or one page that finds all the data of one person in all stores. A party that answers a request goes to each store (#3057).

#2194 tracks the compliance needs of customers in the EU, and these gaps belong to it.