End-to-end encryption in collaboration tools, explained

Encryption in transit, at rest, and end to end

These three get used as if they're one claim, and they protect against three different attackers. Encryption in transit, TLS between your device and a server, stops someone eavesdropping on the network. It says nothing about what happens once your data arrives: the server decrypts it and can read it.

Encryption at rest protects the copy on the server's disks or backups, so a stolen hard drive or a leaked backup file is unreadable. The server still holds the key and decrypts the data routinely to do its job: search it, render it, back it up.

End-to-end encryption is the only one of the three that excludes the server itself. Data is encrypted before it leaves your device and only decrypted on a recipient's device; the operator's servers never hold a key capable of reading it, so there's nothing to compel, breach, or have an employee misuse.

Who holds the keys decides what the claim means

The whole question collapses to key custody. If a service can decrypt your content for any reason, to index it for search, generate a preview, run an AI summary, it holds a key that can decrypt it, and "end-to-end encrypted" isn't an accurate description no matter the marketing.

This isn't theoretical. In March 2020, The Intercept reported that Zoom's website, security white paper, and in-app interface all described meetings as end-to-end encrypted, including a padlock icon that said so directly. Zoom in fact used transport encryption to its own servers and retained the ability to decrypt meeting content; a spokesperson later clarified that "end to end" in Zoom's other literature meant the connection was encrypted "from Zoom end point to Zoom end point," a description of encryption in transit to Zoom's own infrastructure, not of a connection only the two participants could decrypt.

Envelope encryption: one content key, wrapped per member

Group tools don't usually re-encrypt a whole document separately for every member who can read it. The standard pattern is envelope encryption: encrypt the data once with a content key, then encrypt, or "wrap", that content key separately for each person who should open it, using each person's own key. Google's Cloud KMS documentation describes the general version plainly: a data key does the actual encrypting, and a second key wraps the data key so it can be stored and distributed safely.

Applied to a shared note or board, the document itself is encrypted once. What changes per member is a small wrapped copy of that one content key, sized in bytes rather than the size of the document. Unwrap it with your own private key and you can decrypt the document; you were never issued a second copy encrypted under your own key.

What adding a member actually does

Adding someone to shared, encrypted content means minting a new wrapped copy of a content key for them, not copying any data. The IETF's Messaging Layer Security standard, RFC 9420, documents this pattern for group messaging: an existing member fetches a new member's public key material and broadcasts an update that lets the newcomer initialize their own view of the group's current keys.

A detail worth knowing if a vendor claims a new member can read a group's full history: a well-built scheme doesn't require that. Under MLS's semantics, a client that joins later can read and send new content, but content sent before they joined isn't something their key material can open. Whether a product exposes older history anyway is a product decision layered on the cryptography, not something key wrapping itself requires.

What removing a member actually does, and what it can't undo

Removal runs the same mechanism in reverse: generate a new content key and rewrap it for everyone except the person removed, so new entropy reaches every remaining member and nobody else. RFC 9420 is explicit that this is what makes a removal meaningful rather than cosmetic, describing the new key material added at a removal as "not known to the removed member," which the standard credits with giving the group what it calls post-compromise security.

Here is the limit that matters most, and it's a statement about physics, not engineering: rotating a key only protects what's encrypted after the rotation. A former member who decrypted and viewed content while they still held a valid key has that content. No later rotation reaches back into a device that already decrypted something and erases what that person read. Removing someone is forward-looking access control, not retroactive erasure, and any claim that it's the latter should be read skeptically.

What the server can still see: metadata

Perfect content encryption still leaves a server needing to know some things to function. At minimum it typically needs to know who a message or update is for, to deliver it, which already reveals group membership and who talks to whom even when nobody can read what was said.

Signal's own engineering blog is a useful illustration of how hard the next layer is, since it's a vendor narrating its own limitation rather than a claim about someone else's product. It explains that while a messaging service always needs to know where to deliver something, it traditionally also needs the sender's identity, to stop spoofing and apply abuse protection, and that this sits outside the encrypted payload, visible to the server, the way an address on the outside of a sealed envelope is visible to the postal service even though the letter inside isn't. Signal built a separate mechanism, sealed sender, specifically to strip that one piece of metadata out, framed as its own distinct work layered on top of message encryption, not a side effect of it.

The general lesson: timing, recipient lists, group size, and often filenames are parts of a system content encryption alone doesn't touch. A vendor's claim should say which of those remain visible to it, not just whether the content is sealed.

How to evaluate a vendor's "we can't read your data" claim

A few concrete questions do most of the work.

• Does the documentation say where keys are generated and held? If it doesn't specify client-side generation, assume the server can reach the key.
• Does a server-side feature, search, previews, AI summaries, actually work on your content? If so, something on the server can decrypt your data, regardless of the marketing page, which is the gap Zoom was caught in.
• Is the claim scoped to one feature or to the whole product? A product can genuinely seal one surface while leaving another, say a live web view, unsealed, and a vendor that states which is which is more credible.
• Does a claim about removing a member describe future access or past access? Cryptography can revoke what someone decrypts going forward; it cannot reach into a device that already decrypted something and take it back.

How this works in Forkbench

Per Forkbench's security page, notes are end-to-end encrypted on every plan including the free one: each field is sealed on your machine before it's stored, so what sits on Forkbench's servers is opaque bytes. There's no passphrase; one account key encrypts every note, and each Mac you enroll opens it with its own Secure Enclave key rather than a password. Opening notes in a browser doesn't change that: the browser mints a throwaway key pair in the tab, you approve a short code on your Mac, and your Mac seals the notes key to that tab rather than handing it over.

Shared work uses the envelope pattern this post describes. Per Forkbench's security page, a shared Thread gets its own key rather than reusing your account key, so inviting someone to one Thread grants exactly that Thread, nothing else. Removing somebody rotates that key and re-seals its contents for everyone who remains, and Forkbench states the limit directly: what a removed person already read is theirs, so the removal flow names the secrets so you can rotate them at the provider.

Forkbench also documents where it doesn't apply this: Talk, its web companion for watching a live agent session, is described on the same page as "the one thing on this page that is not end-to-end encrypted," because rendering a live conversation in a browser means holding its parsed text while that conversation is active. More on what else is visible once someone joins a Thread is in what a colleague can see when you invite them.