Threat model
End-to-end encrypted file transfer, with nothing uploaded
“Encrypted” on most file-sharing sites means encrypted in transit and encrypted at rest — with the provider holding the keys to both. Here the keys are agreed between the two browsers and never leave them, which is a different claim: we cannot read your files even if we wanted to.
Short answer
What makes a file transfer end-to-end encrypted?
The two endpoints must agree on a key that no one in the middle ever holds. Here the browsers derive a shared secret over ECDH P-256 and seal every chunk with AES-256-GCM. The server only relays the introduction, so it has no key, no ciphertext and no file to hand over.
Send something private
Share the code; the other person enters it to connect
Keys are generated in the browser when you connect and discarded when you close the tab.
How it works
- 1
Keys are made where the file is
Each browser generates an ECDH P-256 key pair locally and exchanges only the public halves. The shared secret is derived on both sides via HKDF and never transmitted.
- 2
You verify there is no one in the middle
Once connected, both screens show the same safety words, derived from the shared key. Read them aloud. If they match, no third party negotiated its own key with either of you.
- 3
Every chunk is sealed on its own
Each block of the file is encrypted with AES-256-GCM before it leaves your machine. A tampered or truncated chunk fails authentication and stops the transfer rather than landing on disk.
“Encrypted” is not one claim, it is three
| What is claimed | Who can read the file | Typical of |
|---|---|---|
| Encrypted in transit (TLS) | The provider, once it arrives | Almost every website |
| Encrypted at rest | The provider, which holds the keys | Cloud storage and upload-and-share sites |
| End-to-end encrypted | Only the two endpoints | This tool |
The practical difference shows up when someone else asks for your data: a subpoena, a breached backup, an over-broad internal tool, a policy change three years from now. A provider that holds the plaintext has something to hand over. Here there is no copy and no key to produce.
What our server actually sees
A signalling service is still needed to introduce two browsers that do not know each other’s addresses. Being specific about what passes through it matters more than any badge:
- The 6-digit code, held in memory with a short expiry, so the second browser can find the first.
- The connection negotiation (SDP and ICE candidates), which contains network addresses — not file data.
- The usual transport-level facts of any web request: an IP address, a timestamp, a rate-limit counter.
- It does not see file names, sizes or contents — those are exchanged over the encrypted channel after the handshake.
- It does not see the encryption keys, which are derived independently on each side and never transmitted.
- It does not store your file, because the file never travels through it at all.
What encryption here does not protect you from
- The other person. Once they have the file, it is theirs — encryption governs the pipe, not what happens at the far end.
- A compromised device on either side. Malware on your laptop reads the file before it is ever encrypted.
- Metadata at the network level. Your ISP can see that two addresses exchanged a lot of encrypted data, just not what it was.
- Skipping the safety-word check. The verification step is what closes the door on a man-in-the-middle; if neither of you reads the words, you are trusting the handshake blindly.
Frequently asked questions
Is this actually end-to-end encrypted, or just HTTPS?
Both, and they are separate layers. HTTPS protects the page and the signalling. On top of that, the two browsers agree a key over ECDH P-256 and encrypt every chunk of the file with AES-256-GCM, so the payload is unreadable to anything between them — including us.
What are the safety words for?
They are derived from the shared key, so they only match if both sides negotiated the same secret. Reading them aloud confirms nobody slipped into the middle of the handshake. It takes five seconds and it is the one check software cannot do for you.
Can you be compelled to hand over my file?
There is nothing to hand over. The file is never uploaded, never stored, and the keys exist only in the two browsers for the duration of the connection.
Do you log anything?
The signalling service keeps the room state it needs, with a short time-to-live, plus ordinary rate-limiting data. File names and contents never reach it, so they cannot be logged.
Is AES-256-GCM per chunk better than encrypting the whole file?
For streaming, yes. Each chunk carries its own authentication tag, so corruption or tampering is caught as it arrives instead of after a multi-gigabyte download, and the transfer can resume from a clean boundary.
Does this meet my company’s compliance requirements?
That is a question for whoever owns your compliance programme. What we can state plainly is the mechanism: no server-side copy, no server-held keys, end-to-end encryption with published algorithms. We make no certification claims.
Send something you would not upload
Contracts, medical scans, passport photos, unreleased work — the kind of file where “where did this end up” has a real answer.
Start a transfer