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 in Legal roles.

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_admin deletes a user of its lldap. When the operator disables an application, its data stays. To erase all the data of an application, the operator sets deleteData with enable false (see the operator configuration). The backups of the application stay for the grace period of the hosting provider. 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 example media-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_MODE of Mastodon, federation of PeerTube and ACTIVITY_PUB of Pixelfed.
Records of processing (GDPR Art. 30). The operator and the hosting provider each keep a record. The tables below and the state register give the facts that come from the software.
Privacy policy. The hosting provider sets the URL of its privacy policy in PRIVACY_POLICY_URL, and the panel links to it from each page. The operator sets privacyPolicyUrl for its deployment, else the deployment uses the URL of the hosting provider. The applications link to that URL: the operator configuration tells how for each application. The code does not supply the text of a policy. The hosting provider and the operator each write the text for the processing that they do.

Where a deployment keeps its data

The state register lists each store of state with its node and its path. This section gives the layout of a deployment.

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, or a local redis when the group has no valkey node	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 offsite backup of a local redis goes to the `mastodon-backups` bucket (`core/components/operator/local-cache-backup.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, or a local redis when the group has no valkey node	The cache and the job queue.	As for Mastodon, in the `peertube-backups` bucket.

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 (PostgreSQL)	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.
`/var/lib/pixelfed/storage/app` on the node	The files that are not in the bucket, for example profile headers, custom emoji, and the avatars from before `PF_LOCAL_AVATAR_TO_CLOUD`.	Until Pixelfed deletes them.
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.	The code sets no retention on the cache. The offsite backup of a local redis goes to the `pixelfed-backups` bucket (`core/components/operator/local-cache-backup.nix`).
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

The state register lists each store of the shared services: lldap, Authelia, SMTP, the panel, api/, the OpenTofu state backend, OpenBao, SPIRE, NetBox, the DNS zones, Windmill, Grafana, the telemetry, the journal and the backups. For each store it gives the node and the path, the personal data and its data subjects, the retention, the encryption, the backup and the procedure to erase. The build makes the register from the code, thus this page does not repeat it.

Where the data is

The hosting provider declares its legal entity, the country and the data center of the data, and its sub-processors in the provider option of the panel, see Publish where the data is. The panel shows this on the page of each deployment and on the public page /provider/. This agrees with GDPR Art. 28 for the sub-processors, and with Data Act Art. 28 for the jurisdiction of the infrastructure. When a hosting provider declares nothing, the panel shows "Not declared".

Other parties

The software sends data to these parties. The hosting provider lists the parties that it uses in its contract, see Annex IV, and in provider.subProcessors of the panel.

Party	Data that it gets
Domain registrar (Openprovider in the code)	The domain names. The registrar records a contact handle as the owner, the administrative, the technical and the billing contact of each domain (`core/effects/tf/incus/operator/registrar.tf`). Each handle is a domain contact of the operator, which the operator picks for each role of each deployment. A role without a pick takes the owner. The contacts in the registrar account have the contact data that the operator gave, and the operator is the registrant of record of each domain that a deployment registers or transfers. The state of a deployment keeps the handles only. The contact data is in the state of the contact, see Personal data of the shared services.
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. A group can also copy the backups to a target outside the site. That target is a sub-processor. It gets the backups encrypted, and it does not get the keys. It keeps them up to 8 days more than the Garage. No group sets a target by default (#2101).
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 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;
whether the disks are encrypted (#2180).