Apple removed its strongest encryption setting from UK customers in February 2025. The EU’s Chat Control proposal failed in the Council by a single vote in March 2026. The phrase “end-to-end encrypted” sits at the center of those fights — and almost nobody describes what it actually means.
The most common misconception — that E2EE just means “the data is encrypted” — would also describe HTTPS, your bank’s website, and the lock icon in every browser. None of those is end-to-end. The distinction matters because it’s the difference between an app saying we won’t read your data and one saying we can’t. The first is a privacy policy. The second is a mathematical claim about what’s physically possible.
What End-to-End Encryption Actually Means
End-to-end encryption means message content is encrypted on the sender’s device, stays encrypted across every server and network it crosses, and is decrypted only on the recipient’s device. The “ends” are the two devices belonging to the parties in the conversation. Nothing in the middle — including the company that built the app and runs the servers — holds the keys to read what’s inside.
The contrast is with transport encryption, the kind of encryption that secures most of the open internet. HTTPS encrypts data only between your device and the server you’re connected to. The server then has the data in plaintext, processes it, and re-encrypts it on the way to its destination. That works for your bank, which needs to read your transactions to do its job. It does not work for private messaging, because the operator of the server can read every message that passes through.
E2EE replaces “trust the company not to read your data” with “the company is not in possession of the keys to read your data.” One is a promise. The other is a property of the system.
How a Message Travels Between the Two Devices
The mechanism rests on public-key cryptography, a 1970s idea that lets two parties exchange secrets over an open network without ever meeting in person. Each user’s device generates two keys: a public key, which is shared openly, and a private key, which never leaves the device. Anything encrypted with the public key can only be decrypted with the matching private key.
When Alice sends a message to Bob, her app fetches Bob’s public key from the messaging service’s directory, encrypts the message on her device using that key, and sends the ciphertext through the service’s servers — which see only an encrypted bundle and routing metadata. Bob’s app decrypts the ciphertext locally with his private key.
Modern E2EE protocols add layers on top of this base mechanism. Ratcheting algorithms change keys with every message, so compromising one key doesn’t expose the entire conversation. Ephemeral session keys provide forward secrecy — past traffic stays encrypted even if a private key is later stolen. Post-compromise security mechanisms re-establish secure communication after a key compromise, rather than leaving the conversation permanently broken.
What E2EE Hides — and What It Leaves Visible
E2EE is narrow. It protects message content. It does not protect metadata — the information about messages that has to be visible to the network for delivery to work at all.
- Message bodies and text content
- Photos and file attachments
- Voice and video call audio
- Group chat conversations
- Disappearing-message contents
- Who you contacted and when
- Frequency and patterns of contact
- IP address and device information
- File sizes and call durations
- Your contact list (depending on app)
For most threat models — an eavesdropper on the network, a hostile employee at the messaging service, a server-side breach — E2EE is sufficient. For threat models involving sustained targeted surveillance, it’s one layer in a larger architecture that also has to address metadata exposure, device security, and the integrity of the directory that publishes public keys. Intelligence-agency reporting since the 2013 Snowden disclosures showed that metadata alone is enough to map social graphs, identify journalistic sources, and surface the structure of organizations.
The Three Protocols Behind Almost All E2EE Traffic
PGP (Pretty Good Privacy), introduced by Phil Zimmermann in 1991, was the first widely deployed end-to-end encryption system. It works for email and files, but it’s famously cumbersome: keys are managed manually, there’s no forward secrecy by default, and the user experience has aged poorly. PGP today is mostly used by journalists, security researchers, and a handful of compliance contexts.
The Signal Protocol is what runs in the background of most modern messaging. Developed by Open Whisper Systems and now maintained by the Signal Foundation, it introduced asynchronous E2EE — two devices don’t need to be online simultaneously to start a conversation — and forward secrecy at the per-message level. WhatsApp adopted the protocol in 2016, and Google Messages, Facebook Messenger, and several smaller messengers have since shipped Signal Protocol implementations or close derivatives.
MLS (Messaging Layer Security) is the newcomer. Published as RFC 9420 in July 2023 and accompanied by an architecture document, RFC 9750, in April 2025, MLS is the first formally standardized E2EE protocol with academic security proofs and a permissively licensed reference implementation. Its main contribution is efficient group encryption — where the Signal Protocol scales poorly past a few dozen group members, MLS handles thousands. Cisco, RingCentral, and parts of Google’s messaging stack have shipped MLS in production.
How Mainstream Apps Actually Implement E2EE
The defaults matter more than the features. An app that supports E2EE only in a specially named mode is not protecting most of its users, because almost nobody flips the toggle. An app that ships E2EE on by default for all conversations is.
Cloud backups complicate the picture. iMessage between Apple devices is end-to-end encrypted in transit — but if a recipient has iCloud Backup enabled with the standard protection setting, a copy of the conversation gets uploaded to Apple’s servers in a form Apple holds the keys to. Apple’s Advanced Data Protection (ADP), introduced with iOS 16.2 in December 2022, extends E2EE to most iCloud categories, raising the count of end-to-end encrypted data types from 14 to 25 — but only for users who opt in. Apple removed ADP for UK customers on February 21, 2025, after the UK government issued a Technical Capability Notice demanding backdoor access. UK users now have access to fewer end-to-end encrypted iCloud categories than users in any other major market.
Why Governments Are Trying to Break It
Pressure on E2EE has come from two directions in roughly the same window.
The UK’s Online Safety Act, in force since October 2023, gives the communications regulator Ofcom the power to issue Technology Notices requiring messaging providers to deploy “accredited technology” to detect terrorism content and child sexual abuse material — including in encrypted services. Signal stated publicly it would leave the UK market if compelled. As of May 2026, no detection technology has been accredited and no notices have been issued, which has effectively made the provision dormant rather than dead.
The EU’s Child Sexual Abuse Regulation (CSAR), nicknamed Chat Control, would have required messaging platforms to scan all private communications, including E2EE messages, via client-side scanning before encryption. The first version of the proposal — Chat Control 1.0 — was rejected in a Council vote on March 26, 2026, by a single vote. Negotiations continue, with the existing interim regulation extended through 2028.
Both efforts share the same technical idea: client-side scanning, where the app inspects content on your device before encryption. Cryptographers have been nearly unanimous that client-side scanning fundamentally breaks the E2EE security model, because the infrastructure to scan for X can later be repurposed to scan for Y by policy change rather than software change. The argument cuts both ways depending on what one thinks should be scanned, which is exactly why regulators keep returning to it.
The One-Line Test Worth Memorizing
There is a one-line test for whether an app is genuinely end-to-end encrypted: can the company running the app read your messages? Not do they. Not would they. Can they, technically.
If yes — even theoretically, even with a court order, even for a single feature like cloud backup — it isn’t end-to-end encryption in the strict sense. If no, it is. Everything else is marketing copy.
