DPA Annex: black box hosted by Filarr

Preamble

This annex supplements Filarr’s Data Processing Agreement (DPA). It governs the processing of personal data by Filarr (published by Mathis Belouar-Pruvot, an individual, personal publisher, contact details in the Legal Notice, the “Processor”) on behalf of the customer (the “Controller”) when the Controller entrusts one or more databases to the black box hosted by Filarr.

For the entrusted databases only, and while they remain entrusted, these databases are no longer end-to-end encrypted: their key is managed by our servers, which decrypt them to serve the API chosen by the Controller. For these databases and this processing, this annex therefore prevails over the provisions of the DPA that describe content as encrypted and unreadable by the Processor (Sections 2, 3, 6 and 7 of the DPA). In all other respects, the DPA applies unchanged.

1. Definitions

• Hosted box: an API access whose Filarr Gate black box is run by a Filarr service rather than by the Controller.
• Entrusted database: a Filarr database that the Controller has checked, one by one, in the hosting consent, and that has been neither withdrawn nor erased since.
• Hosted service: the filarr-gate-host program, which runs the public Filarr Gate code for each hosted box.
• Hosting consent: the versioned text hebergement-v1 that the Controller accepts for each entrusted database, by checking the database, checking the “I understand…” statement and confirming their identity.
• Taking the key back: withdrawing a database, revoking the access, or moving to a black box run by the Controller itself. The keys of the databases concerned then change.
• Sleep: the state of a hosted box that no longer serves the API, with nothing erased (Section 4).
• Erasure receipt: the document signed by the hosted service that attests that an erasure was carried out (Section 10).

2. Roles

2.1. For the personal data contained in the entrusted databases, and for the other data processed by the hosted service under Section 5, Filarr acts as a processor within the meaning of Article 28 GDPR, on behalf of and on the instructions of the Controller.

2.2. The Controller is the holder of the account that creates the hosted box. Where the box is billed to an organization, or an entrusted database belongs to an organization’s vault, the Controller is that organization, represented by the person who entrusts the database. Where the Controller itself acts as a processor on behalf of a third party, Filarr acts as a sub-processor and the Controller passes these obligations on in its own contract.

2.3. A database that belongs to a vault can only be entrusted by the owner or an admin of that vault. Any owner or admin of the vault can withdraw it, even if they did not create the box. The other members of the vault are informed by a notice visible on the database and in the vault, and by a notice the next time they open the vault. It is the Controller’s responsibility to inform data subjects other than these members.

2.4. Filarr remains the controller, under its privacy policy, of the data needed to provide the option itself: account, billing, record of consents, access log, call counts.

3. Subject matter, nature and purpose

3.1. Subject matter: running, on behalf of the Controller, the Filarr Gate black box on the databases it entrusts, in order to serve the API it has configured.

3.2. Nature: receiving the key of each entrusted database, sealed by the Controller’s device for the hosted service; decrypting the entrusted databases; holding a decrypted copy in memory; keeping, at rest, an encrypted state (app key hashes, webhook secrets, saved queries, keys and states of external syncs, encrypted blocks); answering requests from the Controller’s software; carrying out the writes that this software requests; sending the configured webhooks; running saved queries, SQL and the MCP protocol; scheduled sync with an external database over an HTTPS connector; receiving files and encrypting them for the Controller’s deposit box; counting calls.

3.3. Purpose: serving the API chosen by the Controller, and nothing else. The Processor does not use this data for any other purpose: no analytics, no indexing, no profiling, no advertising, no model training, and no disclosure to third parties other than the recipients the Controller has configured itself (software holding an app key, webhook receivers, external databases).

4. Duration

4.1. The processing of a database begins with the hosting consent given for that database. It lasts as long as the database remains entrusted.

4.2. It ends when the key is taken back, when the database is withdrawn, when the access is revoked, when the database is automatically withdrawn (Section 4.4) or at the end of a sleep (Section 4.3). The hosted service then erases what it holds and delivers a signed erasure receipt (Section 10).

4.3. Sleep. A hosted box goes to sleep when the subscription that carries it is suspended or cancelled for non-payment (after the subscription’s seven-day grace period), when the creator’s plan drops below Pro, when the organization forbids hosting, or in the event of an emergency stop of the service by Filarr. During sleep:

• the service stops serving the API, stops syncs and deposits, and clears its memory;
• the sealed key and the encrypted state are kept, so that the box can wake up; nothing is erased;
• the box wakes up on its own if the cause goes away (payment received, plan restored, ban lifted);
• the Controller can at any time request immediate erasure or take the key back.

Sleep lasts 30 days. If its cause still exists at the end of that period, the service erases the box and delivers a signed erasure receipt. A sleep caused by an emergency stop of the service never leads, on that ground alone, to erasure.

4.4. New version of the consent. If the text of the hosting consent changes, boxes in service continue for 30 days; the database carries a notice. Without a new consent by the 30th day, the database is withdrawn from the box, with an erasure receipt.

5. Categories of data and data subjects

5.1. The Processor does not know in advance what data is processed: it is determined by the Controller, who chooses the databases it entrusts and their content. It includes:

• all rows and all columns of the entrusted databases, including those no view shows;
• everything written to them while they remain entrusted, by the Controller, by vault members or by the API;
• the requests of the Controller’s software and the responses;
• the rows of an external database connected to the box, and the key of that external database;
• the files the box receives, while they pass through, before they are encrypted for the deposit box;
• the data carried by the configured webhooks.

5.2. The data subjects are those whose data the Controller puts in its databases (for example its customers, prospects, employees, suppliers, or the members of its vaults).

5.3. The Processor has no way of knowing whether an entrusted database contains special categories of data (Article 9 GDPR) or data relating to criminal convictions (Article 10). It is for the Controller to assess, in light of the measures described in Annex 1 and their limits, whether the hosted box is suitable for the data it entrusts, and to carry out an impact assessment where required.

5.4. The following are not covered by this processing: databases not entrusted, and the Controller’s notes, files and vaults, as well as the keys of its account and of its vaults. The key of each entrusted database is derived one way: it cannot be used to recover the account key or a vault key.

6. Processor obligations

The Processor:

a) processes data only on the documented instructions of the Controller. These instructions are: the hosting consent, the box configuration made from Settings › API access (app keys, webhooks, saved queries, external databases, file filters) and this annex. If Union or Member State law requires other processing, it informs the Controller before processing, unless that law prohibits it. It immediately informs the Controller if it considers that an instruction infringes the GDPR or other applicable data-protection law;

b) ensures that persons authorized to process the data have committed to confidentiality. In ordinary operation, no person accesses the content of entrusted databases: there is no administrative route that reads this content, and no console;

c) implements the technical and organizational measures described in Annex 1;

d) complies with the conditions for engaging sub-processors in Section 7;

e) assists the Controller in responding to data-subject requests (Section 8);

f) assists the Controller in meeting its obligations under Articles 32 to 36 GDPR, taking into account the nature of the processing and the information available to it: security (Annex 1), breach notification (Section 9), impact assessment (the Processor provides this annex, the Trust Center and access to the public code of the service);

g) at the end of the processing, erases the data in accordance with Section 10;

h) makes available the information necessary to demonstrate compliance with Article 28 GDPR and allows the audits provided for in Section 11;

i) keeps a record of the processing carried out on behalf of the Controller (Article 30(2) GDPR).

7. Sub-processors

7.1. The Controller authorizes the following sub-processors for this processing:

7.2. The general conditions of Section 5 of the DPA apply: public list on the Sub-processors page, prior notice before any addition or replacement, right to object, equivalent protection obligations imposed on each sub-processor.

7.3. The recipients the Controller chooses itself are not Filarr sub-processors: its software, its webhook receivers and the providers of its external databases.

8. Data-subject rights

8.1. The Processor has no tool to search for or look up a person in an entrusted database. The Controller therefore answers requests for access, rectification, erasure, restriction, portability or objection itself, from its Filarr apps: a row changed or deleted in an entrusted database is also changed or deleted in the hosted service’s copy at the next sync. It can also withdraw the database or take the key back at any time.

8.2. If a data subject sends a request about an entrusted database directly to the Processor, the Processor forwards it without undue delay to the Controller, without answering it on the merits, unless the Controller instructs otherwise.

8.3. On request, the Processor provides the Controller with the information it holds about the processing (consent dates, service versions, sleeps, erasure receipts), which also appears in the access log.

9. Personal data breach

9.1. The Processor notifies the Controller of any personal data breach affecting an entrusted database or the other data in Section 5, without undue delay after becoming aware of it, and no later than 72 hours after becoming aware of it.

9.2. The notification is sent by email to the address of the account that created the box and, for a box billed to an organization, to the people who manage its billing. To the extent the information is available to the Processor, it describes: the nature of the breach, the databases and period concerned, its likely consequences, the measures taken or proposed, and a point of contact. As the Processor does not know the content of the databases, it generally cannot state the number of data subjects or records concerned. Information that is not immediately available is provided afterwards, in phases.

9.3. When a vulnerability is fixed by a security fix deployed without the seven-day delay (Annex 1, item 6), each hosted access receives a notice in its log, and the public deployment log records it. This notice does not replace the notification in Section 9.1 when a breach is identified.

10. Data at the end of processing

10.1. At the end of the processing of a database or a box (Section 4.2), the hosted service erases everything it holds for it: the sealed key, the database keys, the decrypted copy, the box state and the external database keys. The sealed key is erased from the database of Filarr’s API as soon as erasure is requested.

10.2. The service then delivers a signed erasure receipt (Ed25519 signature by the service key), stating the reason, the date of the request and of the erasure, the databases and key generation held, what was erased, and the version and fingerprint of the service code. The receipt is added to the access log, shown in Filarr’s apps and can be checked against the service public key they embed. Withdrawing a single database produces a partial receipt.

10.3. Return. The entrusted databases remain in the Controller’s account at all times, end-to-end encrypted as before: there is no data to return. When the Controller moves to a black box it runs itself, the service sends it, sealed for that new box, the settings package (app key hashes, webhooks, saved queries). External database keys are not included: the Controller must change them with their provider.

10.4. What the receipt proves, and what it does not. The receipt proves that the service carried out the erasure order; it cannot prove that no copy exists elsewhere. The hosting provider’s own restore mechanisms may keep, for the period it sets, earlier encrypted versions of these items. After the key is taken back, the database keys change: what is written afterwards is end-to-end encrypted again, under keys the hosted service never received, which is guaranteed by encryption. What the service processed before the key was taken back remains covered only by the commitments in this annex.

10.5. The Processor keeps, as controller, the hosting log of the access (consents, service versions, sleeps, withdrawals, erasure receipts), which contains no database content, for five years.

11. Audits and information

11.1. The Processor makes available:

• the source code of the hosted service and of Filarr Gate, published in the public filarr-gate repository, and the steps to rebuild a version and its fingerprint;
• the public deployment log (version, tag, code fingerprint, publication date, deployment date, and security fixes with their advisory);
• the code fingerprint (codeHash) that each hosted box announces, signed by the service key, recorded in the access log at each deployment and comparable with that of the published version;
• this annex and the Trust Center.

11.2. External security review. A security review of the hosted service by an independent third party is planned. As of the date of this version, it has not yet taken place. The Trust Center will state its date once it has been carried out.

11.3. Document-based or on-site audits are possible under the conditions of Section 9 of the DPA (notice, confidentiality and security of other customers). They cannot cover Cloudflare’s facilities, whose inspection is governed by Cloudflare’s own terms.

12. Transfers outside the European Union

12.1. Copies stay in the European Union: the state of each hosted box and its execution are located in Durable Objects created in the EU jurisdiction at Cloudflare.

12.2. Transit may leave the European Union. A request and its response pass through the Cloudflare point of presence nearest the caller, where encryption in transit (TLS) is terminated: if the software calling the box is outside the European Union, the request and the response are decrypted in transit there. TLS termination within the European Union only is not offered.

12.3. For a hosted box, Filarr’s main API only processes encrypted blocks, sealed keys and counters, under the conditions of Section 6 of the DPA.

12.4. Cloudflare, Inc. and Stripe, Inc. are established in the United States. Transfers to these companies rely on the European Commission’s adequacy decision on the EU–US Data Privacy Framework (Implementing Decision (EU) 2023/1795 of 10 July 2023), provided the company appears on the Framework’s official list, and, failing that or in addition, on the European Commission’s Standard Contractual Clauses (Implementing Decision (EU) 2021/914) included in their data processing agreements. For entrusted databases, end-to-end encryption does not apply: the protection of the transferred data relies on these contractual safeguards and on the measures in Annex 1.

13. Final provisions

13.1. This annex is accepted by the Controller when it entrusts a database to the hosted box. It remains in force as long as a database is entrusted and, for Sections 9, 10 and 11, until complete erasure.

13.2. A signed copy is available on request at contact@filarr.com.

Annex 1: technical and organizational measures

1. Script isolation

The hosted service is a separate Worker script, filarr-gate-host, in the same Cloudflare account as Filarr’s API. It has its own Durable Objects and its own secrets. The API script declares no binding to them (no database, no storage, no Durable Objects, no service binding), and vice versa; a test reads the configuration of both scripts and fails if such a binding appears.

What isolation guarantees: a box’s sealed key is never in plaintext in the API database, nor in its backups, its history or an export; a defect in or compromise of the API code gives access neither to the service’s secrets, nor to its Durable Objects, nor to a key in plaintext.

2. Keys

• The key of each entrusted database is sealed by the Controller’s device to the service public key (X25519), pinned in Filarr’s apps; an app never seals to a key that is not in its embedded list. The token exists in plaintext only in the device’s memory, for the time of sealing, and then in the hosted service’s memory; it is never displayed.
• The service private keys (HOST_ENC, X25519; HOST_SIG, Ed25519) are secrets of the service script only. The key managed by our servers is the hosted service’s.
• A hosted access token is refused by Filarr’s API unless it is presented with the service’s signature.
• Each database key is specific to that database and to one generation; it is derived one way and opens neither the account, nor a vault, nor another database.
• At rest, each box’s state is encrypted (AES-256-GCM) under a key that only exists in memory. The decrypted copy of the databases only lives in memory.

3. No logging of content

• The service is configured without logs, without traces and without log export (observability block present and fully disabled, no Logpush, no trace consumer); a test refuses any enabled trace and the absence of that block.
• The code writes no request, response, row, file name, webhook or external database address to a console output; the only output is an error code from a closed list.
• Only the following are measured: the number of calls per hour and per access, error codes, durations.
• For *.gate.filarr.com addresses, rules of the filarr.com zone disable the managed firewall, the bot challenge and JavaScript detection, without logging the requests concerned; no other zone Worker is routed there and no log export covers these names.

4. Location of copies

Each box’s Durable Objects are created in the EU jurisdiction: storage and execution within the European Union.

5. Transit

Requests and responses pass through the Cloudflare point of presence nearest the caller, which may be outside the European Union. Encryption in transit (TLS) is terminated by the filarr.com zone, managed by the same Cloudflare account as Filarr’s API: these requests and responses are not end-to-end encrypted.

6. Code deployment

• A version of the service is deployed only through the continuous integration pipeline, from a signed tag of the public filarr-gate repository; no deployment from a workstation; the deployment token exists only in the pipeline.
• A public log lists each version published and deployed: version, tag, code fingerprint, publication date (the date the pipeline received the tag), deployment date.
• At least seven days separate the publication of a version from its deployment; the pipeline refuses an earlier deployment.
• Sole exception: the security fix, reserved for fixing a vulnerability that puts at stake the confidentiality or integrity of the entrusted databases, their keys, the tokens or the isolation, described in a security advisory of the public repository. It is triggered by Filarr’s security officer, sole holder of the signing key reserved for that role, and starts from the latest deployed version. The public log records it at deployment (“security fix, seven-day delay waived”, advisory id and severity); each hosted access receives a notice; the details of the vulnerability are published in the advisory no later than 30 days afterwards; the Trust Center keeps count of the exceptions used per year.
• Cloudflare account: members kept to a minimum, two-factor authentication required, no token able to deploy outside the pipeline, account audit log reviewed at each deployment.

7. No remote attestation

Each box announces the version and fingerprint of its code, signed by the service key; anyone can compare them with those of the published version. This comparison checks what the service announces. Cloudflare Workers offers no remote attestation: no one, Filarr included, can prove that the running code is the announced code. This is framed by the deployment pipeline, the public log and Filarr’s commitments.

8. Access and management

There is no web management interface on the service, no administrative route that reads content, and no console. The box is configured only from Filarr’s apps, through requests signed by the identity key of the access creator, each accepted only once. No person accesses the content in ordinary operation.

9. Consent, transparency and control

• Express consent, database by database, with identity confirmation; record of the version, language and fingerprint of the accepted text, its author, its date and the device.
• The notice “API hosted by Filarr · not end-to-end encrypted” on each entrusted database, for everyone who sees it; notice to vault members; event in the vault’s activity feed.
• An organization can forbid hosting for its members and its vaults.
• Withdrawal of a database, revocation or taking the key back at any time; change of database keys; signed erasure receipt.

10. What these measures do not protect against

• Script isolation is no barrier to an administrator of Filarr’s Cloudflare account: such an administrator can deploy code and change the zone configuration. What frames this is deployment through the pipeline only, the public log, the planned external review and Filarr’s commitments, not a technical barrier.
• Requests and responses are not end-to-end encrypted in transit; an interception by the account that manages the zone would leave no public trace, as the certificate is legitimately its own.
• The data is decrypted in memory on Cloudflare’s machines; with regard to Cloudflare, as host, its protection relies on Cloudflare’s contractual commitments, not on encryption.
• The zone rules do not cover Cloudflare’s internal logs.
• The erasure receipt proves that the service carried out the order, not that no copy exists anywhere else.
• What the service processed before the key was taken back remains covered only by the commitments.