Trust Center

Filarr Trust Center: security, privacy, compliance.

Filarr encrypts your files on your device before they are sent. Our servers only store encrypted data they cannot read, along with the encrypted copy of your key. The only exception, at your choice: databases you entrust to the black box hosted by Filarr. This page documents what that means, and what we cannot do.

Updated 27 October 2026

End-to-end encryption

Every file is encrypted with AES-256-GCM on your device, in the browser for Filarr Send. For a Filarr Send share, the key travels in the URL fragment (#), the part of a link browsers never send to the server (RFC 3986). For a file request, the depositor seals their key to your X25519 public key, also carried in the link fragment. Our servers store only opaque ciphertext and metadata.

Cryptographic architecture and threat model →

What we can — and cannot — do

This is a direct consequence of end-to-end encryption. It is also our commitment. It does not apply to databases entrusted to the hosted black box (see below).

What we cannot do

Read your files from what we store: encrypted data, and a copy of your key that only opens with your password or your recovery phrase.
Analyse or scan your files server-side, including for automated moderation or eDiscovery.
Recover your data without your password or your recovery phrase.
Recover a Filarr Send file whose full link, which carries the key, was lost.
Pass plaintext content to a third party, including an authority: our servers only store it encrypted. Exception: databases you entrust to the hosted black box, decrypted by our servers while they remain entrusted.

What we can do

Provide limited metadata in response to a valid legal request: timestamps, country and /16 subnet. The full IP address is only recorded after a serious report, within the limits set out in the privacy policy.
Revoke and delete a share by its id, upon report (see Trust & Safety).

Black box hosted by Filarr

To serve a database as an API, something has to decrypt it. By default, that is a black box you run yourself, on your machine, your server or your Cloudflare account: our servers only see encrypted blocks from it. The black box hosted by Filarr is a paid option that spares you from installing it. In return, the databases you entrust to it are no longer end-to-end encrypted while they remain entrusted. This section states exactly what changes, what protects it, and how to check it.

What stays end-to-end encrypted, and what no longer does

No longer end-to-end encrypted, for entrusted databases only and while they remain entrusted:

What is no longer end-to-end encrypted, who decrypts it, and why
what	decrypted by	why
all rows and all columns of the entrusted databases, whether a view shows them or not	the hosted service	it manages their key and serves the API from its copy
what is written to them while they remain entrusted (by you, vault members, the API)	the hosted service	the current key is passed to it while the database remains entrusted
your software’s requests and the responses	the hosted service	it serves the API
the same requests and responses, in transit	the Cloudflare account that manages `filarr.com`, that of Filarr’s API, which also hosts the service	the `<name>.gate.filarr.com` address is a name in its zone: it terminates encryption in transit (TLS) itself
the key of an external database connected to the box, and its rows	the hosted service	the scheduled sync runs there
files the box receives, while they pass through	the hosted service	it encrypts them for your deposit box after receiving them

Stays end-to-end encrypted:

databases you have not entrusted, your notes, your files and your vaults;
the keys of your account and your vaults: an entrusted database’s key is derived from them one way, and cannot be used to recover them;
what is written to a database after you take its key back: the key changes, and the new one is never passed to the service;
the folder where received files are filed: only your devices file them.

Filarr’s main API still only processes encrypted blocks, sealed keys and counters. The key it passes to the service is sealed to the service’s public key, which Filarr’s apps embed: it is never in plaintext in its database, nor in its backups.

Our commitments

Not to log the content of entrusted databases, requests and responses.
To use this content only to serve your API.
To keep its copies in the European Union: each box lives in a Cloudflare Durable Object created in the EU jurisdiction.
To erase the key and the copy when you take it back, and give you a signed receipt.
To deploy a version of the service only from a signed tag of its public repository, through the integration pipeline, at least seven days after its publication, except for a security fix, flagged as such.
To have no console, no administrative route that reads content, and no human access to content in ordinary operation.
To show “API hosted by Filarr · not end-to-end encrypted” on each entrusted database, for everyone who sees it, and to notify the members of a vault.
For entrusted databases, to act as your processor under the GDPR: DPA annex for the hosted box.

These are Filarr’s commitments, not protection by end-to-end encryption.

What protects what, ranked by strength

What protects what, ranked by strength, with its exact limit
strength	protection	its exact limit
encryption	one database, not the account	the entrusted key opens one database, at one generation
encryption	taking the key back cuts off the future	what the service processed before is covered only by the commitments
encryption	the key is never in plaintext in the API database or its backups	this covers neither traffic in transit, nor the service itself, which holds its private key
none	a hosted box’s traffic, in transit	it is not end-to-end encrypted: the account that manages `filarr.com` terminates TLS; the consent says so
verifiable	the code fingerprint the service announces equals the published version’s	this checks what the service announces, not the running code (see the limits)
verifiable	everything is traced	consents, service versions, sleeps, take-backs, erasure receipts, in the access log
verifiable	it shows	the notice on each entrusted database, for everyone who sees it
commitment	isolation, no logging of content, copies in the EU, no other use	see the limits
commitment	erasure	a signed receipt proves the service carried out the order, not that no copy exists elsewhere

How to check

1. The public deployment log. Each version published, then deployed, has its line: version, tag, commit, code fingerprint, publication date, deployment date, and, for a security fix, the advisory and its severity. It is in the journal.jsonl file on the release-journal branch of the public filarr-work/filarr-gate repository, and Filarr’s API serves it at https://api.filarr.com/public/gate-host.
2. The announced codeHash. Each hosted box publishes its version and code fingerprint, signed by the service key:
```
curl -s https://ctl.gate.filarr.com/.well-known/filarr-gate-host.json
```
Filarr’s apps show this fingerprint in Settings › API access, and the access log keeps each deployed version: compare it with the one in the public log.
3. The SHA256SUMS file. codeHash is sha256: followed by the SHA-256 of the version’s SHA256SUMS file. This file lists the published archives and the very service module that is deployed. From a clone, at the version’s tag:
```
npm ci
node scripts/pack-check.mjs release   # builds twice, compares, writes release/SHA256SUMS
sha256sum release/SHA256SUMS          # "sha256:" + this = the announced codeHash
```
then compare release/SHA256SUMS with the one of the version published on GitHub.

As of 27 October 2026: version 0.3.1, published on 16 October 2026, deployed on 26 October 2026 (UTC), codeHash sha256:8755b3858e7d6b2a0092547adc10b46a1014e3ae673abd65d61d9beeff4852b2. Security fixes deployed without the seven-day delay in 2026: 0.

The limits, stated as they are

No remote attestation. Cloudflare Workers does not offer it: no one, Filarr included, can prove to you that the running code is the announced code. Comparing the codeHash checks what the service announces. That is why deployment goes through a public pipeline, with a seven-day delay and a public log.
Script isolation is no barrier to an account administrator. The service runs in the same Cloudflare account as Filarr’s API, in a separate script, with its own secrets and its own storage: a defect in or compromise of the API code does not reach them. An administrator of that account, however, can deploy code and change the configuration. What frames this is the deployment pipeline, the public log and our commitment, not a technical barrier.
Transit is not end-to-end encrypted. The account that manages filarr.com terminates TLS. An interception by that account would leave no public trace, as the certificate is legitimately its own.
Copies stay in the EU, transit does not. A request passes through the Cloudflare point of presence nearest the caller, which may be outside the European Union. TLS termination within the European Union only is not offered.
Cloudflare is the host. Entrusted databases are decrypted in memory on its machines; with regard to Cloudflare, their protection relies on its contractual commitments. Our zone rules do not cover its internal logs.
The receipt proves the order, not the absence of copies. It proves that the service carried out the erasure; it cannot prove that no copy exists elsewhere.
The external security review has not yet taken place. It is scheduled; the offer opened before it, on 27 October 2026, after an internal security review. This page will state the date of the external review once it has been carried out.

How to take the key back

From Settings › API access, on desktop or web, “Take back the key…” offers two paths:

Simply revoke. The API stops at once. The service erases the key and its copy, and delivers a signed receipt; the database keys change: what is written afterwards is end-to-end encrypted again.
Move to your own black box, without interrupting your software:
1. install Filarr Gate yourself (server, workstation, Docker or your Cloudflare account);
2. receive a new token, shown once; the hosted box sends yours its settings (app keys, webhooks, saved queries), sealed for it;
3. change the address in your software; the old one can redirect to the new one for 30 days (308), without reading or keeping anything;
4. “Erase and change the keys”: the service erases the key and its copy, the databases move to the next generation, a signed receipt is added to the log.

External database keys are not passed on: Filarr held them, so change them with their provider, then give the new ones to your black box.

A vault’s owner or admin can also withdraw a database of their vault from a hosted box, even if they did not create it.

If the subscription is no longer paid, if your plan drops below Pro or if your organization forbids hosting, the box goes to sleep: it no longer serves the API, nothing is erased for 30 days, and it wakes up if the cause goes away. At the end of that period, it is erased, with a signed receipt. During sleep, you can move it to your own black box or request immediate erasure.

Data residency

Your files are end-to-end encrypted before they leave your device: the host cannot read them, wherever it keeps them. They are stored on Cloudflare R2, in Cloudflare’s “Western Europe” region — a location hint, with no binding jurisdiction (this region may include the United Kingdom); the accounts database is served from the same region.

Cloudflare is a US company. The decisive point is therefore not location but end-to-end encryption: a demand for content, including under the CLOUD Act, can only obtain unreadable encrypted data. This does not apply to databases you entrust to the hosted black box: they are no longer end-to-end encrypted.

Public sub-processor list →

For account data (email, billing), Filarr is the data controller. For files and metadata processed on behalf of a business customer, and for databases entrusted to the hosted black box (DPA annex), Filarr acts as a processor: a Data Processing Agreement (DPA, GDPR Article 28) is available and can be signed on request.

Data-subject rights (access, rectification, erasure, objection, portability): write to contact@filarr.com. You can also delete any share at any time from “My shares”, without an account.

Transparency about our maturity: Filarr is published by an individual at launch stage. We claim no certification we do not hold. An independent security audit and, where relevant, an ISO 27001 effort are planned as the professional user base grows. We prefer documenting the architecture precisely (verifiable) over displaying badges. The hosted black box opened before this external review, after an internal one: see its section.

Trust & Safety

End-to-end encryption makes server-side content scanning impossible — we own that. For databases entrusted to the hosted black box, we commit not to analyse their content. For illegal content, a reporting mechanism (DSA-aligned) is present on every recipient and deposit page: it acts on the link id and metadata, never the content. Anonymous deposits are protected by a proof-of-work and per-address quotas, and any share can be taken down upon a substantiated report.

Security and responsible disclosure

Cryptographic architecture and threat model
security.txt (responsible disclosure, RFC 9116)
Desktop client source code published (BSL 1.1 → Apache 2.0 on April 19, 2030), readable and buildable. The precise term is “source available”: until that date the licence restricts some production uses, so it does not meet the OSI’s open source definition. The server and the Filarr Send cryptography are not published. Source code and licence

Found a vulnerability? Email contact@filarr.com. Please allow a reasonable time before any public disclosure.

Binary integrity

Every Windows build is Authenticode-signed (SSL.com certificate, SHA-256), and the executable’s SHA-512 digest is recomputed after signing and published with the release: you can compare it before installing. There is no macOS version yet.

Personal storage guardrails

When you connect your own bucket, the address you provide is validated before any connection: HTTPS required, no credentials in the URL, and internal addresses refused — loopback, RFC 1918 private ranges, link-local, and cloud metadata endpoints, including their decimal and hexadecimal spellings and their IPv6 equivalents. Redirects are never followed, and only one custom endpoint is accepted per seven-day period. These rules exist so that a configuration field cannot become a way to make our infrastructure talk.

Bring your own storage →