Verifiable, not marketing
Open DevTools, watch the network tab when you create a share. You'll see ciphertext only. No marketing phrases will tell you more than 30 seconds of your own inspection.
Architecture
Zero-knowledge means a specific, verifiable property: the encryption key never reaches our server.
Encryption
AES-256-GCM via the Web Crypto API. Same primitive that protects banks. No homegrown crypto, no proprietary protocols.
Key transport
The encryption key lives in the URL fragment (the part after #). Browsers never transmit fragments in HTTP requests — that's a fundamental web property, not a SnapSend choice.
Server access
Our backend stores ciphertext + IV + an opaque ID. We have nothing that can decrypt your data — not even with subpoena power.
Deletion
Each share has a hard TTL plus a one-time read flag. On read, the KV record is purged within seconds. There are no recoverable backups.
Threat model
Every security tool defends against some threats and not others. Here's exactly where the line is.
SnapSend defeats
- Operator compromise — even if our servers are breached, the attacker gets ciphertext only.
- Subpoena / legal compulsion — we have no key, so we have nothing to compel.
- Network intercept — TLS in transit, AES-256-GCM at the cipher layer.
- Replay — each share has a unique random IV; tampered ciphertext fails AEAD verification.
- Brute force on share IDs — IDs are 21-character nanoid (~125 bits of entropy).
SnapSend does NOT defeat
- Endpoint compromise — if the recipient's browser is compromised when they decrypt, the plaintext is exposed. Zero-knowledge protects the operator side, not the device side.
- Frontend compromise of SnapSend itself — if our delivered JavaScript is malicious, encryption can be subverted. Mitigated by Subresource Integrity (planned), reproducible builds (planned), and your ability to inspect the code in DevTools.
- Metadata leakage — timestamps, file sizes, IP addresses, request frequency. We encrypt content, not the fact that you used the service.
- Recipient retention — if the person you share with copies the secret somewhere, that's outside our model. We can only guarantee what happens on our servers.
Responsible disclosure
Found a vulnerability? Email us. We respond within 48 hours and won't pursue legal action against good-faith research. No formal bug bounty yet, but we publicly credit any real finding in the audit log below — and the first ten valid reports get a SnapSend Pro lifetime account.
Audit log
Public record of vulnerabilities reported, disclosed, and fixed. Empty so far. We'll publish the first finding the day it's reported, with a credit to the researcher (with permission).
Want to verify the architecture yourself?
Read the full how-it-works page