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).
Transparency report
Count of legal data requests received. Updated when received; in the meantime, the zeros below are accurate.
0
Subpoenas
0
Court orders
0
National security letters
0
User data disclosed
Updated whenever a request is received. The zero-knowledge architecture means even with a court order we can't produce decrypted content — there's nothing on our servers but ciphertext.
Open-source commitment
Security claims should be auditable, not trusted. Our plan to make ours so:
- Encryption protocol spec published as a public document. Anyone can verify the cryptographic choices without reading our code.
- Reference implementation of the protocol open-sourced under a permissive license. Self-hosted version becomes possible.
- Reproducible builds so the JavaScript shipped from snapsend.site can be byte-matched against the public source.
Public timeline: protocol spec by Q3 2026; reference server open-sourced by Q4 2026. If we miss these dates, you can hold us to them — this page exists as the public commitment.
Want to verify the architecture yourself?
Read the full how-it-works page