End-to-end encryption: what it protects and what it never did

What follows is the working version of end-to-end encryption: the decisions in the order you actually meet them, with the reasoning attached.

The guarantee is specific

End-to-end encryption means the service carrying your messages cannot read them, because the keys exist only on the participating devices. It does not protect a message once it has arrived on a device somebody else controls or can access. Nor does it protect against somebody adding a device to your account, which is why verification codes exist.

The guarantee is about the middle of the journey, and most real compromises happen at the ends.

Metadata is usually in the clear

Who you messaged, when, how often, from where and for how long is generally visible to the service even when content is not. That pattern information is extremely revealing, and intelligence practitioners have said so publicly and repeatedly. Some services minimise metadata deliberately, which is a meaningful differentiator and rarely advertised prominently.

Under load, group membership, profile photographs, presence indicators and typing notifications are metadata as well, and they are frequently the components from which a social graph is assembled.

Backups are the common gap

A conversation encrypted in transit and stored in an unencrypted cloud backup is readable by whoever can access the backup. Several messaging services offer encrypted backups as an option that is off by default.

Checking that setting is the single highest-value action for most users of encrypted messengers. Your own settings only reach half of it, because a conversation you protect carefully still sits in the archive of everyone you sent it to, configured however they left it.

Verification exists and nobody does it

Comparing safety numbers or QR codes confirms you are encrypting to the person you think you are, rather than to an interposed key. Without verification, the protection depends on trusting the service's key distribution.

Under load, notifications that a contact's key has changed are the practical version of this and are worth not dismissing. Those notifications also fire for entirely ordinary events such as a reinstalled app or a new phone, so a warning is a reason to ask the person by some other route rather than evidence that anything happened.

Legal and political pressure is constant

Proposals to require client-side scanning or exceptional access appear regularly in several jurisdictions. Cryptographers have consistently argued that access mechanisms cannot be limited to authorised parties once they exist.

Mechanically, this is an active policy question rather than a settled one, and the outcome will change what these guarantees mean. Where the same company writes the client software, the guarantee finally rests on that software continuing to behave as described, which no amount of protocol design lets an outsider verify.

Firmware updates change this behaviour more often than hardware does.

Forward secrecy is the property people mean and rarely name

Modern messaging protocols advance their keys continuously, so compromising a device today does not unlock the messages it exchanged last year. This is what stops an encrypted archive captured now from being opened later with a key obtained later, and it is a stronger guarantee than encryption on its own.

The short version: the cost is that old messages genuinely cannot be reconstructed, which is what people meet when they set up a new phone and find their history has not come with them. A service that restores full history seamlessly onto a new device is doing something else with the keys, and which of the two properties you are getting is worth establishing before relying on either.

The takeaway

The content is protected. Who you talked to, and your backup, usually are not.

Understanding the failure mode tells you more than the feature list does.