Security model

This page honestly describes what Filenymous protects, what it does not, and what servers see. It is checked against the source code (MIT).

Encryption used (browser WebCrypto)

Direct transfer, streaming and extension: file key derived with HKDF-SHA256 from the link secret, AES-256-GCM in 64 KiB chunks with a unique IV per chunk and the header as authenticated data (no reordering or replay). This is on top of WebRTC’s DTLS.
Optional transfer password: PBKDF2-SHA256 (310,000 iterations), HMAC challenge-response; the password never crosses the wire. An optional expiry is mixed into the key.
Dropzone and Sharewall: session keys via HKDF-SHA256 (one key per contributor or per direction), optional password via PBKDF2-SHA256 (200,000 iterations), mutual proof before any exchange.
One-time secret: AES-256-GCM, key via HKDF-SHA256, optional password via PBKDF2-SHA256 (310,000 iterations); the server keeps only the ciphertext and sha256(token).
Whistleblowing channel: hybrid encryption with ephemeral ECDH P-256 + HKDF-SHA256 + AES-256-GCM to the organisation’s public key; the private key stays in the organisation’s browser (protected with PBKDF2-SHA256, 310,000 iterations).

The key is after the # of the link. Browsers never send this fragment to the web server or the relay, and analytics never send it either.
Consequence: anyone who gets the full link can open the share. Send it over a trusted channel, add a password sent another way, and beware of histories, screenshots and link previews.

Signaling relay (wss://www.opendpe.net/filenymous-signal/): pairs browsers. It sees IP addresses, the share code, WebRTC parameters (ICE candidates, SDP) and timing. It does not store them; it uses IPs in memory for rate limiting (for the whistleblowing channel, only as an HMAC with a rotating key).
TURN relay (fallback when a direct connection fails): sees IPs and forwards already-encrypted bytes. The public STUN server (Google) used for address discovery also sees your IP.
Redis (on the server) holds encrypted data only: one-time secrets (24 h by default, 7 days max) and reports (90 days; organisation mailboxes 365 days), without the keys.
Web server and proxy access logs may record IPs like on any website; the application itself does not log request content.
Analytics: self-hosted cookieless Umami, page path only, disabled on secret, report and Sharewall pages.

Peer-to-peer, each peer sees the other’s IP address (that is how WebRTC works), unless the connection goes through TURN.
To hide your IP, use a VPN. Tor Browser disables WebRTC, so peer-to-peer transfers don’t work there.

An AI agent that reads a Sharewall (CLI or MCP) sends everything it reads to its model provider. It can only join if the host ticked “Allow AI agents”.
A secret created by an AI assistant is seen in plain text by the assistant and its provider: create real secrets yourself in your browser.

A compromised device (malware, malicious extension) on the sender or recipient side.
Leak or sharing of the full link, or a weak password.
A compromised web server serving modified JavaScript: like any web app, you trust the code delivered on each visit (the source is public, but served files are not signed).
Traffic analysis and metadata (who talks to whom, when, approximate size) by the relay, the host or the network.
A recipient copying or republishing what they received.

No external security audit has been carried out yet. The code is open source (MIT) and vulnerability reports are welcome via GitHub.

Updated 2026-10-19