Loading today’s stories
Build1 distinct publisher3 min readUpdated
Four mainstream suites encrypt at rest and in transit and stop there, because a server has to read the document to reconcile two people typing. The fix exists, and it bills you in search.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Key custody is the part that decides everything downstream. Encryption at rest protects the disks in the provider's building and TLS protects the hop from your browser to their front door, but the provider holds the decryption keys in both cases, so neither narrows what the company itself can read [2]. The honest reading of "encrypted" on a collaboration vendor's page is a statement about attackers outside the building.
The reason sits in the merge algorithm rather than in any security decision. Live editing, the kind where a colleague's cursor moves in front of you, needs something that processes edit operations and reconciles two people typing into the same paragraph, and both dominant approaches, operational transformation and CRDTs, were designed around a server or at minimum a shared relay doing that work [3]. Take plaintext away from the server in one of those designs and you lose more than conflict resolution: the search index, the preview thumbnail and the live spell-checker were built on the same access [4].
CRDTs are the exception worth knowing about, because they merge deterministically from the data structure itself, with no arbitration required [6]. That property is what lets encrypted operations be relayed as opaque blobs and merged on each client after decryption [7]. So the cryptography is not the blocker. A handful of newer products, mostly encrypted note-taking and password-manager-adjacent tools, already ship sync built this way, while mainstream office suites have not [8]. What is left is migration cost and a feature bill: retrofitting a CRDT-and-encryption architecture onto a decade of shipped product is work most vendors have declined, and server-side full-text search either gets meaningfully harder or moves to the client [9][1].
Search appears on both sides of the source's argument, named as a reason vendors do not build this and as the most common casualty for buyers who pick a tool that did [9][11]. In a procurement conversation that is the whole negotiation. Most other things in a document suite have some client-side substitute. Workspace-wide search does not have a good one yet, which is why the feature that sells the suite is also the feature that keeps the plaintext on the server.
A caveat about where this comes from: the argument is published by Haven, which sells encrypted email and chat and does not ship collaborative documents at all [12], and which says features requiring server-side plaintext get built without it or do not get built [13]. That is a vendor describing a constraint it has chosen to live inside, and it should be read with the discount that implies. The technical account still holds, and it leads somewhere narrow rather than sweeping. For meeting notes and drafts that will be public anyway, provider access rarely matters in practice; for legal strategy memos or unreleased financial terms, where "the vendor got a subpoena or got breached" is a planning scenario, it is the only property that matters [10].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
Google Docs, Notion, Microsoft 365 and Confluence all encrypt documents at rest and in transit, and none of them is end-to-end encrypted, meaning the provider can read the contents on their servers.
"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; neither stops the provider itself from reading the document, because the provider holds the decryption keys.
If the server cannot read the content, then in a naive design it also cannot help merge conflicting edits, generate a searchable index, render a preview thumbnail, or run the spell-checker.
End-to-end encrypted messaging works because a message, once sent, is a discrete unit: encrypt it once, deliver it, done, whereas a live-collaborative document is a continuous negotiation between multiple editors.
CRDTs, unlike operational transformation, do not strictly require a trusted server to resolve conflicts, because any two versions of the document can be merged deterministically using only the data structure itself, with no arbitration needed.
End-to-end encrypted real-time collaboration is technically possible by encrypting CRDT operations client-side, having the server relay opaque ciphertext blobs between collaborators, and having each client decrypt and merge locally.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Single vendor explainer, no citations or named implementations
Every claim traces to one item authored by a vendor in the adjacent encrypted-communications market. The architectural core is coherent and self-consistent in most places, but nothing is cited: no CRDT or OT literature, no protocol documentation, no named product implementing encrypted CRDT sync, and no statement from any of the four suites characterised. The piece also carries an internal tension between its claim that CRDTs were designed around a server and its later claim that CRDTs need no trusted arbiter, which lowers confidence in the framing even where the underlying property is real.
No named products, releases or usage figures
The cluster reports only that 'a handful of newer products' ship client-side-encrypted CRDT sync and that the pattern is uncommon in mainstream suites. No product, vendor, release, version, deployment or user count is given, and the statements about the four named suites describe a longstanding architectural posture rather than an observable adoption event. There is nothing measurable to score without inferring facts the source does not provide.
Mildly overstated: 'the fix exists' rests on unnamed shipping products
The article is unusually restrained for vendor content: it concedes the provider's read access rarely matters for everyday work, names the search regression as a real cost, and discloses the author's business. The overstatement is narrow but present, the load-bearing assertion that the mechanism is already shipping is supported only by an unnamed 'handful of newer products', and the hardest parts of encrypted group editing (key rotation, membership change, metadata exposure, compliance tooling) are absent, which makes the problem look closer to solved than the evidence in the cluster shows.
Vendor-authored, adjacent commercial interest, disclosed late
The piece is written and originally published by Haven, a seller of encrypted email and chat, and closes by presenting Haven's own refusal to add server-side plaintext features as a virtue. The argument that at-rest and in-transit encryption is insufficient directly favours end-to-end encrypted vendors. Mitigating factors keep this below the top of the range: Haven states plainly that it does not sell collaborative documents, does not pitch a product as the answer, and does not name competitors as inferior. Disclosure appears only in the final paragraph, after the argument has been made.
Moderate on framing, weak on verification
Confidence is limited by a one-publisher, one-item cluster with an interested author and no citations, which caps how far any claim can be trusted independently. It is not lower because the claims that matter most for a reader are self-attributed and checkable in kind: what the 'encrypted' label covers, why a merge-participating server needs plaintext, the deterministic-merge property of CRDTs, and the author's own commercial position. The verification-dependent claims, chiefly which products already ship encrypted CRDT sync and why incumbents declined, remain unconfirmed.
security
A staging password went into a Google Doc, and Google's autocomplete found it first1 distinct publisher
leadership
The year's most useful AI tool at one desk was a folder full of Markdown1 distinct publisher
build
Notion's agent stack is live, not slideware, and it only changes one of your decisions1 distinct publisher
build
A NetworkPolicy in another repo broke invoicing while every dashboard reported success1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 22, 2026