Why Zero-Knowledge Architecture Should Be the Default
Short answer: if a service only needs to deliver a secret once, it should never see the secret. VanishingVault defaults to encrypting in your browser and keeping the key in the URL fragment after #, so servers store ciphertext they cannot read. Privacy by architecture — not by a policy page that can change tomorrow.
Related: what is zero-knowledge encryption · ZK vs end-to-end encryption · how we built it on Cloudflare.
What “default zero-knowledge” means here
Zero-knowledge architecture (not a zero-knowledge proof) means the service is designed so operators cannot read user content even with full database access. For VanishingVault, the default path is:
- Client-side encryption — AES-256-GCM via the Web Crypto API before upload.
- Fragment key — decryption material lives after
#in the share URL and is not sent in the HTTP request. - Ciphertext-only storage — edge/KV holds an opaque blob until burn-after-read or expiry.
- No vendor recovery — if the link is lost, we cannot reconstruct the secret. That is intentional.
Contrast that with common “encrypted” SaaS: TLS in transit plus encryption at rest with provider-managed keys. Useful against some disk theft — useless against the provider reading content. Bitwarden, Proton, and similar products describe the same key-custody idea for vaults and drives; we apply it to ephemeral secret links.
Why not trust the server by default?
Traditional secret pastes encrypt on the server or hold keys in the operator path. That creates insider risk, expands breach blast radius to plaintext, and turns legal process into a decrypt request. For a product whose only job is to courier a secret once, that trust is unnecessary complexity.
Defaulting to ZK flips the question from “how hard do we lock the vault where we keep your plaintext?” to “how do we avoid having plaintext at all?”
What default ZK buys you
True data ownership
Plaintext stays on devices that hold the key.
Breach containment
Stolen server blobs remain unreadable without the fragment key.
No content mining
The host cannot scan or monetize what it cannot decrypt.
Honest limitations
- Browser / client trust. Encryption runs in JavaScript you download. A compromised front-end can steal plaintext before encrypt. Prefer HTTPS, current browsers, and documented crypto.
- Bearer URL. Anyone with the full link (including the fragment) can decrypt once. Share over a private channel; treat forwards as exposure.
- No password-reset recovery. Lost key means lost secret. Fine for one-time handoffs; wrong model for a lifelong vault without a recovery kit.
- Feature trade-offs. Servers cannot search, scan, or AI-summarize ciphertext. If you need that, you are back to trusting a processor — consciously.
- Metadata. Providers may still know that a blob existed and when. ZK protects content, not always traffic analysis.
For durable API credentials used by machines every day, use a vault or OIDC — see API key management with one-time secrets. Use VanishingVault when a human needs to hand something off once.
Implementation sketch
// Key stays in the fragment — not in the HTTP path sent to the server
function generateSecureUrl(secretId, decryptionKey) {
return `https://vanishingvault.com/s/${secretId}#k=${decryptionKey}`;
}
// Server stores only ciphertext + TTL; never the key
async function storeEncryptedSecret(encryptedData) {
const secretId = crypto.randomUUID();
await kv.put(secretId, encryptedData, { expirationTtl: 60 * 60 * 24 * 7 });
return { secretId };
}Full edge details: how we built zero-knowledge secret sharing on Cloudflare.
Frequently Asked Questions
Why should zero-knowledge be the default for secret sharing?
Because the courier does not need to read the secret to deliver it. If encryption happens in the browser and the key never reaches the server, a host breach or insider cannot turn ciphertext into plaintext. That is a stronger default than “we encrypt at rest with our KMS.”
How does the URL fragment key work?
The decryption key is placed after # in the share link. Per HTTP rules (RFC 9110), URL fragments are not sent to the server in the request. The recipient’s browser reads the fragment locally, fetches ciphertext, and decrypts with Web Crypto. The server only ever stores the encrypted blob.
What are the honest limitations?
You still trust the browser page that runs the crypto. A malicious or compromised front-end could steal plaintext before encryption. The full URL is a bearer secret — anyone with it can decrypt once. Lost links cannot be recovered by the provider. Metadata (that a secret existed) may still exist until deletion.
Is this the same as a zero-knowledge proof?
No. Zero-knowledge proofs prove statements without revealing secrets. Zero-knowledge architecture here means the provider has zero knowledge of your plaintext because keys stay on the client. See our guide on what zero-knowledge encryption means.
When should I not use this model?
When you need server-side search, content scanning, password reset of stored vaults, or long-lived machine credentials with rotation policies. Those jobs belong to password managers, vaults, and OIDC — use one-time ZK links for human handoffs.
Conclusion
Make zero-knowledge the default wherever the product job is “carry a sealed envelope,” not “search and analyze content.” VanishingVault uses client-side crypto and fragment keys for that reason — with honest limits around browser trust and bearer URLs.