Google Docs, Notion, Microsoft 365, and Confluence all encrypt your documents at rest and in transit. None of them are end-to-end encrypted, meaning the provider can read the contents on their servers, and this isn't an oversight. Real-time collaborative editing and end-to-end encryption are pulling in opposite directions, and most of the industry has, so far, picked collaboration.
"Encrypted" on a cloud storage or document platform's marketing page almost always means encrypted at rest, on the provider's disks, and in transit, over TLS while it travels between your browser and their servers. Both are real protections against an attacker who steals a hard drive or intercepts network traffic. Neither stops the provider itself from reading the document, because the provider holds the decryption keys. That's a deliberate architectural choice, not a corner cut, and it exists because of how collaborative editing actually works.
The technical conflict
Real-time collaborative editing, the kind where you can see a coworker's cursor and their keystrokes appear in your document within milliseconds, relies on the server actively participating in resolving what happens when two people type in the same place at the same time. The dominant approaches are operational transformation and CRDTs (conflict-free replicated data types), and both were designed with a server, or at minimum a shared relay, that processes the actual edit operations to merge them correctly.
If the server can't read the content, in a naive design it also can't help merge conflicting edits, generate a searchable index, render a preview thumbnail, or run the spell-checker that flags a typo as you type. Every one of those features, the ones that make a cloud document tool feel effortless, depends on server-side access to plaintext in the architectures most of these products were built on.
Contrast with encrypted chat
End-to-end encrypted messaging works because a message, once sent, is a discrete unit: encrypt it once, deliver it, done. A live-collaborative document is closer to an ongoing negotiation between multiple editors happening continuously, and encrypting that negotiation without a party who can read it to referee the merges is a much harder problem, one the field has only recently started solving well.
What's actually changing
CRDTs, unlike operational transformation, don't strictly require a trusted server to resolve conflicts, because they're designed so that any two versions of the document can be merged deterministically using only the data structure itself, no arbitration needed. That property is what makes end-to-end encrypted real-time collaboration technically possible: encrypt the CRDT operations client-side, let the server relay opaque ciphertext blobs between collaborators, and each client decrypts and merges locally.
A handful of newer products, mostly encrypted note-taking and password-manager-adjacent tools, ship real-time sync built this way. It remains uncommon among mainstream office suites, partly because retrofitting a CRDT-and-encryption architecture onto a decade of existing product is a bigger undertaking than most vendors have chosen to make, and partly because features like server-side full-text search, which most business users expect, get meaningfully harder or move client-side entirely when the server can't read the content.
What each model actually protects against
| Threat | At-rest + in-transit encryption | End-to-end encryption |
|---|---|---|
| Network eavesdropper | Protected (TLS) | Protected |
| Stolen server hard drive | Protected | Protected |
| Provider compelled by legal order to hand over content | Provider can comply | Provider has nothing readable to hand over |
| Malicious or coerced insider at the provider | Has plaintext access | No plaintext access |
| Provider breach exposing document contents | Depends on breach scope | Ciphertext only, unreadable without client keys |
What this means for choosing a tool
For most day-to-day collaborative work, meeting notes, project plans, drafts that will eventually be shared publicly anyway, the provider's ability to read the document rarely matters in practice. The gap matters for a specific category: documents where the threat model includes the platform itself, legal strategy memos, unreleased financial terms, anything where "the vendor got a subpoena or got breached" is a scenario worth planning for, not just an abstract risk.
For that category, the practical options today are narrower than for messaging: end-to-end encrypted collaborative editing exists but isn't yet the default anywhere close to universal, and picking a tool built that way from the ground up currently means trading away some of the polish of mainstream suites, full-text search across your whole workspace being the most common casualty.
Where Haven fits
Haven doesn't do collaborative documents, we're encrypted email and chat, but the same architectural tension shows up in our own design decisions: features that would require server-side plaintext access get built without it, or don't get built at all, rather than quietly widening what the provider can read.
Originally published at havenmessenger.com
