Security
Deadrop is designed so your secrets stay private — from us, from the network, from everyone except the person you share the link with. This page explains exactly how, including the limits of what any tool like this can promise.
- — We can't read your secrets
Your secret is encrypted in your browser before it ever reaches us. The server stores ciphertext it cannot decrypt.
- — Only your recipient can decrypt it
The decryption key lives only in the link fragment (the part after
#), which browsers never send to servers. We never have it. - — One view, then gone — atomically
Retrieval and deletion happen in a single atomic step on the server. Even two simultaneous requests with the correct key can never both receive the secret — exactly one wins, the other finds it already burned.
- — No content logging, no tracking on secret pages
The server never logs secret content, hints, key material, or anything derived from the link fragment. Secret reveal pages load no analytics at all; marketing pages use self-hosted, cookieless analytics that we run ourselves.
- — Auto-expire
Unopened secrets self-destruct after their expiration window (1 minute to 7 days). Nothing lingers.
- — Open source and specified
The encryption library is open source and the whole protocol is written down in a normative spec that every implementation must honor. Crypto on GitHub · Read the spec
Technical details
| Cipher | AES-256-GCM (Web Crypto API), 96-bit random IV, 128-bit auth tag |
| Key | Fresh 256-bit random key per secret — never reused, never sent to the server |
| Access gate | The server stores a 128-bit truncated SHA-256 hash of the key and compares it in constant time before releasing or burning anything |
| Password option | PBKDF2-SHA256, 600,000 iterations, NFC-normalized — the password combines with the URL key, so possession of the link alone cannot decrypt a password-protected secret |
| Burn | Single atomic compare-and-delete on the datastore — no window where two readers both succeed |
| Overwrite protection | A secret id can never be silently replaced while it is live — duplicate creation is rejected |
| Rate limiting | Per-real-client-IP buckets behind our edge (creation 10/min, retrieval 60/min) — and forwarded-IP headers are only trusted when requests carry cryptographic proof they came through our edge |
| What we store | Ciphertext, IV, the truncated key hash, the optional hint, and an expiry — nothing else, nothing decryptable |
Honest limits
No web-delivered tool can be more trustworthy than the code your browser runs. We say this plainly because vendors who don't are hiding the same facts:
- — You trust the JavaScript we serve
A malicious server could ship altered code. Mitigations: the crypto is a published open-source package, the protocol is specified, and a self-hosted server option means you can run the whole thing on infrastructure you control.
- — The link itself is sensitive
The fragment never reaches our server, but it can leak wherever you paste it: chat logs, clipboard managers, browser extensions, screen shares. Treat the link like the secret it unlocks.
- — Password hints are semi-public
Anyone holding the link can read the hint before entering the password — that's what hints are for. Never put the password itself, or anything that gives it away, in the hint.
- — Burned means burned
There is no recovery, no admin restore, no backup of secret content. If the recipient says they never saw it, someone (or something) else opened the link first — rotate the credential.