End-to-end encryption
In an end-to-end encrypted exchange, readable content is available at the authorized endpoints and not to intermediary servers that relay or store it. The important question is where keys are created, where they travel, and which software can access them.
A browser-based one-time link can fit this model when the sender encrypts locally and the recipient's browser decrypts locally using key material that the server never receives. Trust still remains in the delivered client code, devices, browser, and dependency supply chain.
Zero-knowledge in consumer products
In formal cryptography, a zero-knowledge proof has a precise meaning: proving a statement without revealing the underlying secret. Storage and sharing products often use 'zero-knowledge encryption' more broadly to mean the provider lacks the keys required to read customer content.
That can be a useful description if it is backed by design details. It should not imply that the provider knows literally nothing. The service still sees requests, timestamps, sizes, account identity, subscription state, and abuse signals.
The metadata boundary
Metadata can reveal relationships and behavior without revealing content. A file size, time of access, account email, IP address in infrastructure logs, or payment record may be personal data. Good architecture limits collection, uses pseudonymous identifiers, separates privileges, and deletes operational data on defined schedules.
A clear privacy notice should name these categories rather than allowing a content-encryption claim to obscure them.
How to assess a claim
Look for answers to concrete engineering questions:
- Does encryption happen before upload?
- Can the server receive or reconstruct the decryption key?
- Are passphrases transmitted or processed locally?
- Is encryption authenticated so tampering is detected?
- What metadata is stored, and for how long?
- Can the service reset access in a way that secretly recovers encrypted content?