Trust Center

Security, privacy, compliance

Filarr is built so your files are encrypted on your device before anything leaves it — the key never leaves your browser. We therefore cannot read, scan, or hand over your content to anyone. This page documents exactly what that means, and what we cannot do.

The zero-knowledge model

Every file is encrypted with AES-256-GCM in your browser. 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.

❌ Read your file content — impossible, we do not hold the key.
❌ Scan your files server-side (including for automated moderation or eDiscovery).
❌ Recover a file whose key (in the link) was lost.
❌ Hand over plaintext content to a third party, including on legal demand — we never hold it in clear.
✅ Provide limited metadata (timestamps, country + /16 subnet, never the full IP) in response to a valid legal request.
✅ Revoke and delete a share by 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 that end-to-end encryption neutralizes any demand (including the CLOUD Act) for content: what could be handed over is unreadable ciphertext. The full list of our sub-processors and their locations is public.

→ Public sub-processor list

GDPR & 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.

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.

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 & responsible disclosure

Cryptographic architecture & 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.

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. Apple notarisation is not in place yet: on macOS the app is distributed outside the Mac App Store and Gatekeeper will show a warning. We would rather write that here than let you find out.

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 also: Privacy · Terms · Legal notice