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. This page documents what that means, and what we cannot do.
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.
What we can — and cannot — do
This is a direct consequence of end-to-end encryption. It is also our commitment.
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.
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).
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.
GDPR and compliance
For account data (email, billing), Filarr is the data controller. For files and metadata processed on behalf of a business customer, 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.
Trust & Safety
End-to-end encryption makes server-side content scanning impossible — we own that. 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.
See alsoPrivacyTermsLegal notice