Data protection
This page maps the actors of Concepts to the roles of the General Data Protection Regulation (GDPR), and lists the personal data that each application and each shared service stores, where it stores it, and for how long. It gives only the facts that come from the code in this repository. A hosting provider adds the facts of its own setup, for example its sites, its staff and the services of other parties that it uses. Contract templates uses these facts in a data processing agreement and in switching clauses.
This page is not legal advice. The roles depend on the contracts and on the facts of each hosting provider. Let counsel check them before you use them.
The roles under the Cyber Resilience Act and the Product Liability Directive, for example when a party becomes the manufacturer, are a different subject (#2196).
Roles
| Actor | Role | Data |
|---|---|---|
| Operator (the customer organization) | Controller | The data of its deployment: the accounts, posts, messages and media of its applications, and the users of the lldap and of the Authelia of its group. |
| Hosting provider | Processor of the operator, for the data of the deployments | It stores, backs up, transmits and logs the data of the deployments on the instructions of the operator. |
| Hosting provider | Controller, for its own data | The accounts of the panel, the users of the lldap of the hosting-provider group, its audit records (the audit_event table of api/, the journal, Loki and the audit log of OpenBao), and the users of Grafana, NetBox and Windmill. |
| DNS, SMTP and the backup target | Sub-processors of the hosting provider | See Other parties. |
| Edsger and the Fediversity maintainers | Supplier of the software. Not a processor, because they do not get access to the data of a deployment. | None. When Edsger runs infrastructure for a hosting provider or an operator, it becomes a processor or a sub-processor for that infrastructure, and a contract for that processing is necessary. |
| Application users | Data subjects of the operator | Their accounts and content. The applications also store content of the accounts of other instances that federate with the instance. |
| The staff of the operator | Data subjects of the hosting provider (panel accounts) and of the operator (the users of its lldap) | The panel account, and the user in the lldap of the operator group. |
The development infrastructure of the project, for example git.fediversity.eu, is not a part of a deployment, and this page does not cover it.
Who does what
- Instructions. The configuration of a deployment in the panel is the documented part of the instructions of the operator. The schema is in Operator configuration.
- Erasure requests. The party that controls the data does the erasure. The operator erases the data of its deployment, for example with the account deletion of the application, or when a member of
lldap_admindeletes a user of its lldap. The operator has no shell on the nodes. Thus the hosting provider runs the commands that need a shell on the instruction of the operator, for examplemedia-backup-<app> erase. The hosting provider erases its own data, for example a panel account. The hosting provider guide tells how to erase each type of data, and what stays in the backups. - Restores. After a restore from a backup that is older than an erasure, the party that controls the data does the erasure again. The hosting provider tells the operator which service it restored and the date of the backup. See Do the erasures again after a restore.
- Federated content. The operator is also the controller of the content that its applications get from other instances, because the operator decides to federate. Mastodon and PeerTube federate by default, and the panel does not ask the operator to choose. The operator limits federation in the settings of each application, for example
LIMITED_FEDERATION_MODEof Mastodon,federationof PeerTube andACTIVITY_PUBof Pixelfed. - Records of processing (GDPR Art. 30). The operator and the hosting provider each keep a record. The tables below give the facts that come from the software.
- Privacy policy. The panel does not show a privacy policy, and a hosting provider cannot set one for the applications of an operator (#2088). The operator sets the texts of its applications in the settings of each application, and the link of the Authelia portal in
privacy_policyof the Authelia settings.
Where a deployment keeps its data
Each operator group has its own nodes for valkey, Authelia, SMTP and lldap (core/setups/groups/operator.nix, core/components/operator/default.nix). The PostgreSQL databases are on the central PostgreSQL node of the hosting provider. The buckets are on the Garage node of the hosting provider, with a prefix for each operator (core/resources/garage/default.nix). Garage keeps one copy of each object (replication_factor = 1 in core/resources/garage/server.nix). The backups of an application are restic repositories in its <app>-backups bucket on the same Garage (core/components/operator/app-resources.nix).
The retention of the backups is in Know how long the backups keep personal data. The retention of the journal, of Loki, of the nginx access log and of the audit_event table is in Know which personal data the logs keep. This page does not repeat these periods.
In the tables, "not set in the code" means that the code sets no value, thus the default of the upstream application applies. This page does not give the upstream defaults. Find them in the documentation of the application version that the deployment runs.
Personal data per application
Mastodon
| Store | Personal data | Retention |
|---|---|---|
The mastodon database (PostgreSQL) |
The accounts and their email addresses, the posts, the direct messages, the follows, the sessions. | Until the user or a moderator deletes the data. The operator can set IP_RETENTION_PERIOD, SESSION_RETENTION_PERIOD and USER_ACTIVE_DAYS in settings. They are not set in the code (core/components/operator/mastodon/default.nix). |
The mastodon bucket (Garage) |
The uploads of the users, and cached media of other instances. | The operator can enable mediaAutoRemove and set olderThanDays for the cached media. They are not set in the code. MEDIA_CACHE_RETENTION_PERIOD, CONTENT_CACHE_RETENTION_PERIOD and USER_ARCHIVE_RETENTION_PERIOD are not set in the code. |
The mastodon namespace of the valkey of the group |
The cache, for example queued jobs and timelines. | valkey writes snapshots and an append-only file on its node (core/components/shared/valkey/valkey.nix). |
| The journal | What Mastodon writes to its log. | The retention of the journal and of Loki. |
Mastodon sends email through the SMTP node of the group, from noreply@<domain>. Users log in with the Authelia of the group (OIDC). The code does not turn off the local password login.
PeerTube
| Store | Personal data | Retention |
|---|---|---|
The peertube database (PostgreSQL) |
The accounts and their email addresses, the videos and their metadata, the comments, the watch history. | Until the user or a moderator deletes the data. The operator can set history.videos.max_age. It is not set in the code (core/components/operator/peertube/default.nix). views.* is not set in the code. |
The peertube-videos and peertube-playlists buckets |
The uploaded videos and the streaming playlists. | Until PeerTube deletes them. |
/var/lib/peertube on the node |
The files that are not in a bucket, for example avatars, thumbnails, captions, and the logs of PeerTube. | log.* and storage.tmp* are not set in the code. |
The peertube namespace of the valkey of the group |
The cache and the job queue. | As for Mastodon. |
The operator can enable the export and the import of user accounts (export.users.enabled, import.users.enabled). They are not set in the code. The operator can also set the sign-up rules (signup.*), for example whether sign-up is open.
Pixelfed
| Store | Personal data | Retention |
|---|---|---|
The pixelfed database (MariaDB on the node) |
The accounts and their email addresses, the posts, the direct messages, the follows. | Until the user or a moderator deletes the data. The operator can set ACCOUNT_DELETION and ACCOUNT_DELETE_AFTER. They are not set in the code (core/components/operator/pixelfed/default.nix). |
The pixelfed bucket |
The uploaded images and videos, and the avatars. | Until Pixelfed deletes them. The operator can set IMAGE_STRIP and MEDIA_EXIF_DATABASE, which control the metadata of an image, for example a location. They are not set in the code. |
A local redis, or the pixelfed namespace of the valkey of the group when pixelfed-cache is routed (core/components/operator/pixelfed/node.nix) |
The cache and the job queue. | Not set in the code. |
| The journal | What Pixelfed writes to its log. | The retention of the journal and of Loki. LOG_* is not set in the code. |
Registration is open by default (OPEN_REGISTRATION in core/components/operator/pixelfed/node.nix). The operator can close it.
Personal data of the shared services
| Service | Store | Personal data | Retention |
|---|---|---|---|
| lldap (one for each group) | The lldap-db database (PostgreSQL) |
The users, their email addresses, names and avatars, and their groups. The first administrator gets the email of the configuration. |
Until a member of lldap_admin deletes the user (core/components/shared/lldap/default.nix). |
| Authelia (one for each group) | Its database (PostgreSQL), encrypted with a storage key | The consents, the second factors, the identity verification tokens and the OIDC state of each user. | Not set in the code. The session lifetime, the inactivity limit and the regulation (the ban after failed logins) are not set in the code, and the operator can set them (core/components/shared/authelia/default.nix). |
| Authelia | The journal | What Authelia writes to its log. Upstream, this includes the user name and the client IP address of a failed login. | The retention of the journal and of Loki. |
| SMTP (maddy, one for each group) | The mail queue, and the journal | The addresses, the headers and the content of the mail that passes, for example password resets and notifications. | The retention of the queue is not set in the code (core/components/shared/smtp/default.nix). |
| Panel | Its database (PostgreSQL) | The accounts of the operators, with the email address and the user name from the OIDC login, the sessions, and the deployments with their configuration (panel/src/panel/models.py). |
Until a panel administrator removes the account. The panel first queues the destroy of each deployment of the account. The session lifetime is the default of Django, and no job removes expired sessions. |
api/ |
Its database | The deployment and build tables (the configuration and the build logs), and the audit_event table (the actor of each action). |
The audit_event table: see the logs section of the hosting provider guide. No job removes old rows of the build table. |
| Grafana | Its database (SQLite) | The accounts that the first OIDC login makes. | Not set in the code. |
| NetBox, Windmill | Their databases | The accounts of the administrators. | Not set in the code. |
| OpenBao | The journal | The audit lines. See the logs section of the hosting provider guide. | The retention of the journal and of Loki. |
| Telemetry (Loki, Tempo, Mimir) | Buckets on Garage | A copy of the journal of each node. See the logs section of the hosting provider guide. | services.fediversity-telemetry.retentionDays. |
Other parties
The software sends data to these parties. The hosting provider lists the parties that it uses in its contract, see Annex IV.
| Party | Data that it gets |
|---|---|
| Domain registrar (Openprovider in the code) | The domain names. The registrar records the contact handle of the account of the hosting provider as the owner, the administrative and the technical contact of each domain (core/effects/tf/incus/operator/registrar.tf). The contact data does not go into the OpenTofu state. |
| External DNS provider | The DNS records of the domains, which contain no personal data from the software. core/effects/octodns/ can publish to an external provider. The code does not turn on the query log of the BIND nodes of the hosting provider. |
| SMTP smarthost | All mail that the SMTP nodes send: addresses, headers and content. The smarthost is smtp.smarthost of the group. Without a smarthost, the SMTP node sends the mail to the mail server of the recipient. |
| Backup target | The backups. In the code, the backup target is the Garage of the hosting provider, thus no other party gets the backups. There is no copy to a target outside of the deployment (#2101). When a hosting provider adds an external target, that target is a sub-processor. |
| ACME certificate authority (Let's Encrypt by default) | The domain names, and the email of the configuration as the contact of the ACME account (core/resources/ssl/acme.nix). |
Unknowns
The code does not show these facts. A hosting provider finds them in its setup or in the upstream documentation:
- the upstream defaults of the retention settings that the code does not set, see the tables above;
- the retention of the mail queue of maddy, and what the smarthost keeps;
- the retention of the job logs of Windmill, of the change log of NetBox, and of inactive Grafana accounts;
- how long Authelia keeps old consents and second factors;
- what the registrar, the external DNS provider and the ACME certificate authority keep, and where they process it;
- the location of the nodes, and whether the disks are encrypted (#2180).