Name the assets and actors
Assets include plaintext, keys, ciphertext, recipient identity, metadata, notifications, and availability. Consider a database thief, network attacker, malicious insider, compromised deployment account, hostile browser extension, endpoint malware, link-preview service, and unintended recipient. Each has different capabilities.
Protect the cryptographic boundary
Generate keys with a cryptographically secure random source. Use a reviewed authenticated-encryption construction and unique nonces. Keep keys out of requests, logs, telemetry, DOM attributes, analytics, crash reports, and persistent browser storage unless the design explicitly requires persistence.
Bind important metadata—such as content type or protocol version—as authenticated additional data when it must not be altered. Define size limits before allocation and reject malformed ciphertext without exposing useful oracle behavior.
Treat delivered code as trusted
The server may not possess stored keys, yet it delivers JavaScript that handles them. An attacker controlling deployment could modify that code to copy plaintext or fragments. Restrict administrative access, protect the build pipeline, pin and review dependencies, deploy a strong Content Security Policy, and monitor production assets.
“Zero knowledge” should describe a narrow, verified data property—not imply that the entire service is immune to compromise.
Account for endpoints and recipients
Encryption cannot stop screen capture, clipboard managers, browser extensions, malware, shoulder surfing, or intentional forwarding after decryption. Minimize display time, avoid unnecessary copying, and encourage rotation after sensitive bootstrap handoffs.
Validate claims with failure tests
Inspect network requests and logs for key leakage. Test modified ciphertext, nonce reuse prevention, concurrent reads, expired objects, dependency compromise scenarios, backups, browser history, accessibility paths, and cache behavior. Commission independent review before presenting architectural intent as a security guarantee.
A sound design says exactly which attacker loses access to which asset, under which assumptions. Anything broader is marketing, not a threat model.
Sources and review basis
This guide is maintained as defensive-security education. The editorial team reviews its recommendations against current implementation experience and these authoritative references: