How true end-to-end encryption differs from common alternatives

A practical comparison of email, shared drives, chat apps, and true E2EE workspaces

In day-to-day work we usually share sensitive material in three ways: email, shared drive links, and chat apps. All three can be “secure enough” for normal use. But they are not the same thing as true end-to-end encryption (E2EE).

True E2EE means: the content is encrypted on our device and only decrypted on the recipient’s device. The service in the middle cannot read it.

A simple mental model

There are three levels we see in practice:

1. Transport encryption
   Data is encrypted while it moves between servers (often TLS). The sender and receiver services can still read it. [1][2]

2. Provider-managed encryption at rest
   Data is encrypted on the provider’s storage. The provider still controls the key chain needed to operate features like preview, indexing, scanning, recovery, and compliance tooling. [4][11]

3. True end-to-end encryption
   Data is encrypted on our device and decrypted only by intended recipients. The service in the middle cannot read it. [8][9]

1) Email

What we usually get

Most modern email is protected mainly by TLS in transit between servers. That helps against passive interception while the message travels. [1][2]

But TLS is not true E2EE. Email is processed by mail systems on the sending and receiving sides, and messages may be stored in mailboxes, archives, backups, and forwarding chains.

What true E2EE email looks like (rare in practice)

End-to-end encrypted email exists (for example OpenPGP or S/MIME), but it requires setup, key management, and compatible tooling on both sides. That’s why many organizations don’t use it consistently with external counterparties. [3][12]

Practical takeaway: email is strong for coordination. It is not ideal for long-lived confidential document workflows unless we deliberately add end-to-end controls.

2) Shared drive links (Google Drive, OneDrive)

What we usually get

Mainstream business drives encrypt data in transit and at rest. That is good hygiene and reduces a lot of everyday risk. [4][11]

However, in default configurations this is not true E2EE. The provider can generally decrypt content as part of operating the service, because the provider controls the keys and must support server-side features (preview, indexing, scanning, recovery, etc.). [4][11]

The important nuance

Some providers offer client-side encryption modes where the customer controls keys and the provider cannot decrypt. This moves closer to true E2EE, but it typically introduces feature limitations compared to standard sharing. [5][6][7]

Practical takeaway: shared drives are convenient and familiar. They are not automatically a sealed boundary unless we enable a client-controlled encryption mode and accept the trade-offs.

3) Chat apps (WhatsApp, Signal)

What we usually get

Signal conversations are end-to-end encrypted. [8]
WhatsApp protects messages with end-to-end encryption using the Signal protocol. [9][10]

Why chat apps still struggle for document workflows

Chat streams are built for conversation, not structured production:

• versions and approvals get buried in long threads
• decisions are hard to anchor to a single file
• access control is usually “member of the chat”
• auditability and lifecycle controls are limited compared to a workspace model

Practical takeaway: chat apps are excellent for quick, confidential coordination. They are awkward for structured workflows where we need clear versions, decisions, and controlled access.

What “true E2EE” means in a workspace

A true E2EE workspace tries to combine:

• the privacy model of secure messaging (provider cannot read content), and
• the workflow model of professional work (documents, comments, decisions, permissions)

The trade-off is consistent: when the server cannot read content, it cannot perform server-side features that require cleartext.

Quick comparison

References

[1] Google Workspace Admin Help — Send email over a secure TLS connection
https://support.google.com/a/answer/2520500

[2] Canadian Centre for Cyber Security — Email security best practices (ITSM.60.002), PDF
https://www.cyber.gc.ca/sites/default/files/ITSM.60.002-email-security-best-practices-en.pdf

[3] UK National Cyber Security Centre — Protect email in transit (notes OpenPGP / S/MIME and deployment considerations)
https://www.ncsc.gov.uk/collection/email-security-and-anti-spoofing/protect-email-in-transit

[4] Microsoft Learn (Purview) — Data encryption in OneDrive and SharePoint (BitLocker + per-file encryption)
https://learn.microsoft.com/en-us/purview/data-encryption-in-odb-and-spo

[5] Google Drive Help — Get started with encrypted files in Drive, Docs, Sheets & Slides (Google Workspace client-side encryption)
https://support.google.com/drive/answer/10519333

[6] Google Workspace Admin Help — Client-side encryption FAQ
https://support.google.com/a/answer/14328489

[7] Google Developers — Google Workspace Client-side Encryption overview (explains that CSE prevents Google servers from decrypting)
https://developers.google.com/workspace/cse/guides/overview

[8] Signal Support — Is it private? Can I trust it?
https://support.signal.org/hc/en-us/articles/360007320391-Is-it-private-Can-I-trust-it

[9] WhatsApp — Answering your questions about privacy on WhatsApp
https://www.whatsapp.com/privacyquestions

[10] WhatsApp — Security Advisories
https://www.whatsapp.com/security/advisories

[11] Microsoft Support — How OneDrive safeguards your data in the cloud
https://support.microsoft.com/en-us/office/how-onedrive-safeguards-your-data-in-the-cloud-23c6ea94-3608-48d7-8bf0-80e142edd1e1

[12] UK Information Commissioner’s Office — Encryption scenarios
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/security/encryption/encryption-scenarios/