What End-to-End Encryption Actually Protects, and What It Leaks

Before we start

This piece assumes you already know what end-to-end encryption is and roughly how it works. If you want the foundation first, the plain-English E2EE explainer covers the core mechanics. What follows is the layer underneath: the parts the headline guarantee doesn't reach.

The envelope model: exactly what E2EE seals

The standard analogy is an envelope, and it holds up well if you're precise about what the envelope actually contains. When you send a message over a properly implemented E2EE channel, the plaintext is encrypted on your device before it leaves, transmitted as ciphertext, and decrypted only on the recipient's device. The server in the middle, whether that's Meta's infrastructure or Apple's, handles a sealed package it cannot read. That much is real.

But the envelope is narrower than most people assume. It contains exactly one thing: the message payload. Everything written on the outside of the envelope, the addressing, the postmark, the size and weight, remains visible to the postal service. In messaging terms, that means the provider can see who you contacted, when, how often, from what kind of device, and from which IP address or approximate location. The content is sealed. The context is not.

There's also a subtler boundary at each end. The encryption starts and stops at the application layer on each device. If the device itself is compromised, a screen-reader exploit, a malicious app with accessibility permissions, or straightforward physical access, the plaintext is exposed before encryption or after decryption. E2EE is a channel property, not a device-security property. Those are different problems.

Practical takeaway: Treat E2EE as a guarantee about the transit path, not about the endpoints. Device security and app permissions deserve the same attention as the encryption itself.

Metadata: what the provider still sees, and why it matters

Metadata is the word that gets waved away in privacy marketing, usually with a line like "we can't read your messages." That's true and also somewhat beside the point.

Consider what a provider can observe without touching message content: the social graph (who talks to whom), communication frequency, message timing, session duration, whether you're in a group and who else is in it, device identifiers, and IP addresses that can be resolved to approximate geography. WhatsApp's privacy policy, for instance, explicitly lists the categories of information it collects, and the list is long. It includes "how you interact with others" and "the time, frequency and duration of your activities."

Why does this matter in practice? Because metadata can be analytically powerful in ways that content isn't. A 2014 paper by researchers at Stanford, studying phone metadata, found that call records alone were sufficient to infer sensitive personal attributes including medical conditions and financial circumstances. Messaging metadata is structurally similar. The EFF documented this argument clearly in the context of surveillance disclosures, and it hasn't become less relevant since.

For UK readers, this has a specific regulatory dimension. Under UK GDPR, metadata about communications is personal data where it can be linked to an identifiable individual, which it almost always can. The ICO's guidance on data protection doesn't carve out an exemption for metadata just because the associated content is encrypted. Providers processing this data are subject to the same lawful basis requirements as any other personal data processor.

Signal is the outlier worth naming here. Its architecture is specifically designed to minimise server-side metadata retention. The Signal Foundation has published a technical overview of its Sealed Sender feature, which obscures sender identity even from Signal's own servers in most cases, and its private contact discovery mechanism avoids uploading your full contact list in plaintext. These are deliberate architectural choices, not marketing claims, and they're documented at the protocol level.

The mechanics of how metadata collection works at scale, and how it feeds into broader data profiles, overlap considerably with how companies track you online. The underlying incentive structures are similar even when the product category is different.

Practical takeaway: Read the privacy policy of any messaging app you rely on for sensitive communication. Look specifically for what metadata categories are collected, how long they're retained, and under what circumstances they're shared with third parties or law enforcement.

Backups: the quiet hole in most encrypted messaging

This is the one that catches technically literate people out more than any other. You're using an E2EE messaging app. You enable cloud backup because losing your message history would be inconvenient. You've just handed a copy of your messages to a cloud provider under that provider's encryption keys, not yours.

WhatsApp is the clearest example. Until 2021, WhatsApp backups to Google Drive or iCloud were not end-to-end encrypted at all. They were stored under Google's or Apple's keys, meaning those providers could read them and could produce them in response to a legal request. WhatsApp introduced end-to-end encrypted backups as an opt-in feature in 2021, documented in their official support documentation. It is not on by default. If you haven't explicitly enabled it and set a password or 64-digit key, your backup is not E2EE.

iMessage has a similar dynamic. Messages are E2EE in transit. But if you use iCloud Backup, and most iPhone users do, your messages are included in that backup. Apple holds the encryption keys for standard iCloud Backup. Apple's own platform security guide acknowledges this: iCloud Backup is encrypted, but Apple has the key. Advanced Data Protection, introduced in late 2022, extends end-to-end encryption to iCloud Backup including messages, but again it's opt-in and requires explicit setup. Apple's support page on Advanced Data Protection describes what's covered.

Signal doesn't offer cloud backup at all for message history by default. Local encrypted backups on Android are possible. On iOS, the design choice is simply not to back up message content to iCloud. This is a deliberate trade-off: you accept the risk of losing your history if you lose your device, in exchange for not having that history exist anywhere outside your device. Whether that's the right trade-off depends on your threat model, but it's a coherent one.

The practical implication is that law enforcement requests targeting cloud providers, rather than the messaging app itself, have historically been a more productive avenue than attacking the encryption directly. This isn't speculation: it's reflected in the transparency reports that providers like Apple and Google publish, which show the volume of legal requests they receive and respond to.

Practical takeaway: Check your backup settings now. For WhatsApp, go to Settings, Chats, Chat Backup, and look for the end-to-end encrypted backup option. For iPhone, check whether Advanced Data Protection is enabled in your Apple ID settings. Understand what you're trading before you decide.

Key exchange and verification: what safety numbers actually prove

E2EE depends on your device obtaining the correct public key for your recipient. If an attacker, or the service provider itself, can substitute a different key during that exchange, they can position themselves in the middle of an apparently encrypted conversation. This is the man-in-the-middle problem, and it's why key verification exists.

Signal calls its verification mechanism Safety Numbers. When you and a contact both open the Safety Numbers screen and compare the code, either visually or by scanning each other's QR codes, you're confirming that both clients have the same key material and that no substitution has occurred. If the numbers match, the channel is verified. If they don't, something is wrong. Signal's documentation on Safety Numbers explains how they're derived and what they guarantee.

What Safety Numbers don't prove is that the person holding the other device is who you think they are. Key verification confirms the cryptographic channel. It doesn't verify identity in any broader sense. If someone has physical access to your contact's phone, or your contact has shared their account with another person, verified Safety Numbers tell you nothing useful about that situation.

WhatsApp has an equivalent: Security Codes, which serve the same function. WhatsApp also introduced a Key Transparency system, described in their engineering blog post from 2023. Key Transparency is an auditable log of key material, designed to make it detectable if WhatsApp were to silently substitute keys for a targeted user. It's a meaningful architectural addition, though independent audit of the implementation is still relatively limited compared to Signal's longer public track record.

iMessage doesn't expose a comparable manual verification mechanism to users. Apple's approach relies on its Identity Directory Service, and Apple's platform security documentation describes how keys are managed, but the user-facing tools for out-of-band verification are less developed than Signal's. This is a genuine gap, not a fatal flaw, but it means iMessage users are trusting Apple's infrastructure more than Signal users are trusting Signal's.

Practical takeaway: For conversations where the identity of your correspondent matters, use Safety Numbers or their equivalent. Do the comparison out-of-band, ideally in person or via a separate verified channel. It takes thirty seconds and it's the only way to confirm you're not talking to a substituted key.

Multi-device: how adding a device changes the trust model

Most people use messaging on more than one device. A phone and a laptop, or a tablet as well. The moment a second device enters the picture, the encryption architecture has to answer a question it doesn't face in the single-device case: how does a new device get access to the key material needed to decrypt existing and future messages?

Different apps answer this differently, and the answers matter.

Signal's linked devices model, used for Signal Desktop and iPad, means each linked device gets its own identity key. Messages are encrypted separately for each registered device. When you link a new device, Signal doesn't transfer your existing message history to it. You get a clean slate on the new device, and future messages are delivered to all linked devices. This limits the blast radius of a compromised device: it gets future messages but not historical ones.

WhatsApp's multi-device implementation, which became generally available in 2021, uses a similar approach. Each device has its own identity key, and the app encrypts messages for each device individually. WhatsApp's technical white paper on multi-device, available via their security documentation, describes this architecture. The practical implication is that adding a device to a WhatsApp account increases the number of keys that need to be trusted. If someone adds a device to your account without your knowledge, that device receives your messages.

This is where account security intersects with encryption security. A strong, unique password on your account and two-factor authentication aren't separate concerns from E2EE. They're part of the same threat model. The NCSC's guidance on account security is directly relevant here. If an attacker can add a device to your account by compromising your account credentials, the encryption of the channel doesn't help you.

iMessage handles multi-device through iCloud, which means Apple's infrastructure mediates key distribution across your devices. This works smoothly from a user experience perspective, but it means Apple's servers are involved in ensuring the right keys reach the right devices. It's a different trust assumption than Signal's architecture, though not necessarily a worse one depending on your threat model.

Practical takeaway: Periodically audit the linked devices on your messaging accounts. Both Signal and WhatsApp show you which devices are linked in their settings. Remove anything you don't recognise. Enable registration lock or equivalent two-factor authentication to prevent unauthorised device linking.

Comparing the big four: WhatsApp, Signal, iMessage, Telegram

These comparisons are grounded in documented behaviour and published protocol information. Where the record is thin or contested, that's noted rather than papered over.

A few points that the table compresses.

Telegram deserves particular attention because its marketing frequently uses the word "encrypted" in ways that obscure a critical distinction. Regular Telegram chats, including all group chats, are not end-to-end encrypted. They're stored on Telegram's servers and encrypted under Telegram's keys. Telegram can read them, and has access to them for legal requests. Only Secret Chats, a separately initiated one-to-one conversation type, use E2EE. This is documented in Telegram's own MTProto documentation and is not a contested claim.

MTProto 2.0 has attracted academic scrutiny. A 2022 analysis by researchers at ETH Zurich identified several theoretical weaknesses in the protocol, though the researchers noted these didn't represent immediate practical attacks. Telegram disputed some characterisations. The exchange is in the public record and worth reading if you're evaluating Telegram for sensitive use. The Signal Protocol, by contrast, has a longer track record of independent cryptographic review and is used as the basis for WhatsApp's implementation precisely because of that track record.

WhatsApp's position is complicated by its ownership. The Signal Protocol implementation is technically sound, and this has been noted by independent researchers. But WhatsApp's privacy policy reflects Meta's data practices, and the metadata collection is extensive. The encryption protects content. It doesn't change what WhatsApp knows about your communication patterns.

Practical takeaway: If you use Telegram for anything sensitive, confirm you're in a Secret Chat, not a regular chat. The interface doesn't make this obvious. For most people's threat models, the practical differences between Signal and WhatsApp come down to metadata and backup defaults rather than the underlying encryption.

Threat modelling: who E2EE defeats, and who it doesn't

E2EE is a strong and well-understood protection against a specific set of adversaries. Being clear about which ones matters more than either dismissing it or over-relying on it.

E2EE reliably defeats passive interception of traffic in transit. An attacker who can observe network traffic between you and the server sees ciphertext. This includes your ISP, anyone on the same network, and most forms of mass surveillance that operate at the network layer. This is a genuinely significant protection and the reason E2EE adoption matters at a societal level.

E2EE also defeats the messaging provider as a content adversary, assuming the implementation is correct and the backup situation is managed. Signal's architecture is specifically designed so that Signal cannot read your messages even under legal compulsion. Signal's responses to legal requests, documented in their legal process transparency page, reflect this: they can provide very little because they hold very little.

E2EE does not defeat a compromised endpoint. If your device has malware, if someone has physical access, or if a vulnerability in the app itself is exploited, the encryption of the channel is irrelevant. The plaintext exists on the device, and that's where it's exposed. The NCSC has published guidance on mobile device security that addresses this layer separately from communications security.

E2EE does not defeat a sophisticated state-level adversary who can compel the provider, compromise infrastructure, or exploit zero-day vulnerabilities in the app or operating system. For the vast majority of UK readers, this is not a realistic threat model. For journalists, activists, or anyone whose adversary has state-level resources, the conversation becomes significantly more complex and goes well beyond choice of messaging app.

E2EE does not defeat social engineering. If your correspondent is coerced, compromised, or simply shares your messages, the encryption provided no protection against that outcome. The channel was sealed. The endpoint wasn't.

Finally, E2EE does not defeat legal compulsion directed at your correspondent rather than at the provider. If the person you're messaging is subject to a device seizure or a disclosure order, your messages may be exposed regardless of the encryption used in transit.

The honest summary is that E2EE is exactly what it says: encryption between endpoints. It's a strong, well-implemented protection for a real and common threat, which is interception of communications in transit by parties other than the intended recipients. It's not a complete communications security solution, and treating it as one leads to miscalibrated risk decisions.

Practical takeaway: Write down, briefly, who you're actually worried about when you think about messaging security. An ISP? A platform? A government? A specific person? The answer changes which controls matter. E2EE addresses some of those concerns directly. Device security, operational security, and careful choice of correspondent address the others.