Fediversity

Contract templates

This page gives two templates for the contract between a hosting provider and an operator:

The templates follow the structure of the texts of the European Commission and give the clause numbers of these texts. They do not repeat the legal text. Use the text of the Commission, and add the parts in this page that the hosting provider fills in. The facts in the annexes come from the code in this repository, and from Data protection. A hosting provider adds the facts of its own setup, and removes the facts that are not true for its setup.

These templates are not legal advice. Let counsel check the complete contract before you use it. The facts in the annexes describe the software in this repository. They do not describe the setup of a hosting provider.

The roles under the Cyber Resilience Act and the Product Liability Directive are a different subject (#2196).

Data processing agreement

The agreement follows the standard contractual clauses between controllers and processors of Commission Implementing Decision (EU) 2021/915. The operator is the controller, and the hosting provider is the processor. See Roles.

Clauses

Keep the text of Section I and II of the clauses. Make these choices:

Clause What the hosting provider fills in
Clause 5, docking clause Keep it or remove it. It is optional.
Clause 7.1, instructions The documented instructions are the contract, and the configuration of each deployment in the panel (Operator configuration).
Clause 7.3, duration The term of the contract, and the retrieval period of the switching and exit clauses.
Clause 7.6, documentation and compliance How the operator asks for an audit, and which reports the hosting provider gives, for example the threat model and the SBOM of each node.
Clause 7.7, sub-processors Option 1 (prior specific authorisation) or Option 2 (general written authorisation). For Option 2, the notice period before a change of sub-processor.
Clause 7.8, international transfers Whether a sub-processor in Annex IV is outside of the EEA, and the transfer tool for it.
Clause 8, assistance Who does which erasure. See Who does what. 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.
Clause 9.2, notification of a breach The time in which the hosting provider tells the operator about a breach, and the contact of each party.
Clause 10, non-compliance and termination What happens with the data at the end. Refer to the switching and exit clauses, and to the backup retention.

Annex I: list of parties

The hosting provider fills in the name, the address, the contact person and the activities of each party. Give the contact for security incidents. The project has security@fediversity.eu for the vulnerabilities of the software, see SECURITY.md. That address is not the contact of a hosting provider.

Annex II: description of the processing

Item Pre-filled text
Categories of data subjects The users of the applications of the operator. The staff of the operator that are users of its lldap. The users of other instances, whose content the applications get by federation.
Categories of personal data Account data (user name, email address, name, avatar, password hash, second factors). Content (posts, direct messages, images, videos, comments). Social graph (follows). Usage data (sessions, watch history, client IP addresses in the logs). The data of the mail that the SMTP node sends. See the tables in Data protection.
Sensitive data The software does not ask for sensitive data. Users can put it in their content and direct messages. The hosting provider fills in the restrictions and the safeguards that apply.
Nature of the processing Hosting, storage, backup, restore, transmission of mail, logging and monitoring of the applications that the operator deploys.
Purposes To operate the applications that the operator selects in the panel, on the instructions of the operator.
Duration The term of the contract, and the retention periods in Know which personal data the logs keep and Know how long the backups keep personal data.
Processing by sub-processors See Annex IV.

Annex III: technical and organizational measures

These measures are in the code. The hosting provider adds its own measures, for example the physical security of its sites, the access of its staff, and its incident process. The open gaps are a part of the annex, so that the operator knows them. The threat model gives more detail.

Measure In the code Gap
Encryption in transit TLS on the public names. mTLS to OpenBao. TLS to PostgreSQL with sslmode=require. The S3 API of Garage is plain HTTP. LDAP is plaintext (#2139). Other traffic between the services (#2179).
Encryption at rest The media backups and the restic backups are encrypted. The storage of Authelia is encrypted with a storage key. The disks of the hypervisors are not encrypted (#2180).
Isolation Each deployment runs in its own Incus instances. Each operator has its own address range and a network ACL on the bridge. Each operator group has its own lldap, Authelia, SMTP and valkey. Bucket names have a prefix for each operator. The PostgreSQL node and the Garage node are shared between the operators.
Access control Single sign-on with Authelia. The administration ports admit only adminSources. When adminSources is empty, the ports are open to all addresses. A second factor is not required for the admin interfaces (#2181).
Secrets OpenBao holds the secrets and rotates the database credentials. -
Logging The journal, Loki, and the audit log of OpenBao. The nginx access log keeps only the network of a client. The audit log of OpenBao is not tamper-evident (#2270).
Availability and backup A daily restic backup of each database and of the files, and a media backup of the buckets. The backups are on the same Garage as the data (#2101). Garage keeps one copy of each object. No replication (#2187).
Vulnerability management A monthly update of the pinned inputs, a daily vulnix scan, an SBOM for each node, and the process in SECURITY.md. -
Erasure The account deletion of the applications and of lldap. media-backup-<app> erase for the media backups. A destroy of a deployment removes its databases, its secrets and its buckets. A destroy also removes the backups, without a grace period (#2097).

Annex IV: sub-processors

The hosting provider lists the parties that it uses. A party outside of the hosting provider that gets personal data, for example a contact address, is a sub-processor. The software sends data to the parties below. See Other parties for the data that each of them gets.

Sub-processor Processing Location Note
Domain registrar Registration of the domain names Fill in. The code uses Openprovider. The contact data of the domains is that of the hosting provider.
External DNS provider Publication of the DNS records Fill in. Only when the hosting provider publishes to an external provider.
SMTP smarthost Relay of all mail that the SMTP nodes send Fill in. The smtp.smarthost of each group. Without a smarthost, the mail goes to the server of the recipient.
Backup target Storage of the backups Fill in. In the code, the backups are on the Garage of the hosting provider, thus there is no sub-processor. A hosting provider that adds an external target lists it.
ACME certificate authority Issue of the TLS certificates Fill in. Let's Encrypt by default. It gets the domain names and the email of the configuration, which is the contact of the ACME account.

Switching and exit clauses

The clauses follow the non-binding model contractual terms and standard contractual clauses of Commission Recommendation C(2025) 7750, Annex VI (SCC Switching and Exit) and Annex VII (SCC Termination). The hosting provider is the provider of a data processing service, and the operator is the customer.

The software does not have a self-service export, thus use Option A of Annex VI (switching with a plan), not Option B (automated tools).

What is not implemented

These parts of a switch are not in the software. Until they are, the hosting provider does them by hand, and the plan of Appendix 1 says how:

  • an export of a deployment to a different hosting provider, and an import from one (#612, #100);
  • the start of a migration of a deployment from the panel (#78);
  • standard scripts to move the data of each NixOS service (#607);
  • a grace period for the backups after a destroy (#2097). A destroy removes the backups of the deployment, thus the export must be complete before the destroy.

The operator cannot read the backups or the S3 keys of its deployment from the panel. The panel and api/ do not have an export or a download.

Annex VI, Option A

Clause What the hosting provider fills in
1.1, information Refer to this page and to Data protection.
1.2, switching and exit plan The on-line register of the data structures and the formats (1.2.2) is the exportable data below, and Operator configuration. Give the test procedure (1.2.4): a restore of the export into a test deployment.
1.3, initiation The notice period (at most two months), the address for the notice, and the time for the confirmation of receipt. Give which of the three options (1.3.2) the hosting provider supports: a different provider, on-premises, or erasure only.
1.4, transitional period The transitional period (at most 30 days). During it, the deployment stays on line.
1.5 and 1.6, obligations The steps of the hosting provider: it makes the exports, gives them and the keys to the operator, and keeps the deployment on line. The steps of the operator: it gives the destination, and it tells the hosting provider that the import is complete.
1.7, unsuccessful switching What the hosting provider does when the import fails, for example a second export.
1.8, data retrieval and erasure The retrieval period (at least 30 days). After it, the hosting provider destroys the deployment, and confirms the erasure in the time that it gives. The confirmation says when the backups are erased. See backup retention.
1.9, switching charges The charges until 12 January 2027. After that date, no charges, except data egress costs for parallel use.
1.10 to 1.12 Keep the text.

Exportable data and formats

This list is the input for Appendix 1 of Annex VI. The hosting provider makes these exports by hand.

Data Format How to get it
The configuration of a deployment JSON, in the schema of Operator configuration GET /deployments/{id} of api/, with a token from the panel.
The databases of Mastodon, PeerTube, lldap and Authelia Plain SQL from pg_dump --clean --if-exists --no-owner --no-privileges The same command as the backup, or a restore of the latest restic snapshot of the <app>-backups bucket.
The database of Pixelfed Plain SQL from mariadb-dump As above.
The media of the applications S3 objects, with their keys A copy of the media buckets, for example with rclone.
The files of PeerTube Files of /var/lib/peertube A restore of the file backup, or a copy from the node.
The data of a single user The export format of the application The user exports the data in the application, for example the account archive of Mastodon. For PeerTube, the operator enables export.users.enabled.
The keys that the data needs Text The storage key of Authelia, and the secrets of the applications that encrypt data in their database. Without them, a part of the export cannot be read.

The digital assets of the operator are the domain names and the configuration. When the registrar account is that of the hosting provider, a transfer of each domain is a part of the switch. The software is under the EUPL v1.2, thus the operator, or a different hosting provider, can run the same software.

The exempt data (trade secrets) is fill in. The hosting provider gives the data that it keeps as its own controller, for example the panel accounts and its audit records. See Roles.

Annex VII, termination

Clause What the hosting provider fills in
1.1 to 1.3, termination process Refer to Annex VI. Without a switch, the retrieval period of 1.8 applies, and then the destroy.
1.4, extended data retention Whether the operator can ask for a longer retention, and the charge. A destroy removes the backups, thus a longer retention means that the hosting provider keeps the deployment on line, or keeps an export.
1.5 to 1.7 Keep the text.

Open points

Counsel, or the hosting provider, decides these points:

  • the retention periods that the code does not set, see Unknowns;
  • which charges and periods the hosting provider gives in Annex VI.