Key points
- The provider stores ciphertext without holding the content-decryption keys.
- Encryption must happen before protected content reaches provider-controlled systems.
- Metadata and account data can remain visible and sensitive.
- “Zero knowledge” in product architecture is not the same thing as a zero-knowledge proof.
The useful question is: zero knowledge of what?
A credible claim names the protected fields, where encryption occurs, who can obtain keys, and what the server still processes. “Military-grade encryption” says little. A field-level boundary—task titles and notes are encrypted, while membership and timing metadata remain visible—can be tested.
The architecture normally combines client-side encryption, a key hierarchy, an authentication flow that does not hand reusable password material to the server, and recovery that does not silently create a provider-held master key. Each layer has different failure modes.
Zero-knowledge architecture vs zero-knowledge proofs
A zero-knowledge proof is a cryptographic protocol for proving a statement without revealing the underlying secret. A zero-knowledge application architecture is a broader product property: the provider is designed not to receive the plaintext or decryption keys for a stated content scope. A product may use the architecture without using zero-knowledge proofs.
Because the term is overloaded, architecture claims should be read as an explicit data-flow statement rather than as the name of one algorithm.
What zero-knowledge architecture does not guarantee
It does not make endpoints trustworthy, hide every piece of metadata, prevent an authorized collaborator from copying content, or prove that the shipped client matches published source code. It also does not replace access control, secure software delivery, backups, incident response, or compliance work.
If an attacker controls a device after decryption, the attacker can see what that device can see. If a user loses every unlocking secret and no provider-readable recovery path exists, the protected content may be unrecoverable. Those are consequences of the boundary, not contradictions of it.
Common questions.
Can a zero-knowledge service see any user data?
Yes. The claim normally covers a defined content scope. The service may still see account data, device and security signals, billing records, record relationships, timestamps, and other metadata needed to operate.
Does zero knowledge mean anonymous?
No. A service can know who has an account while being unable to decrypt that account’s protected content.
Is zero-knowledge architecture automatically end-to-end encrypted?
They overlap, but the terms answer different questions. End-to-end encryption describes who can decrypt a communication. Zero-knowledge architecture describes the provider’s knowledge and key custody across a product.
Primary sources
Definitions prefer standards bodies, government guidance, and the first-party SealTask architecture. Links open the complete source.
- 01 SealTask security architecture Product-specific encryption boundary, server visibility, protocols, and current limitations.