Articles / Privacy

878 words

  • encryption
  • metadata
  • investigatory-powers-act
  • uk-law
  • privacy
  • end-to-end-encryption

Why a Warrant Can Reach Your Metadata but Not Your Message Content

A legal order is a request to hand over what exists, and for an end-to-end encrypted service the message text does not exist on the server in any readable form. What does exist is a tidy pile of routing data. That asymmetry is an engineering fact first and a legal one second.

People often describe this as "the law can't read your messages". That is slightly off. The law can demand plenty; the provider simply has nothing readable to give. The distinction matters, because it tells you where the real boundary sits.

What the server actually holds

Picture the server's database row for one delivered message in a typical E2EE messenger. It looks something like this:

type StoredMessage struct {
	ID         string    // server-assigned
	SenderID   string    // account or device identifier
	RecipientID string   // who it is for
	ReceivedAt time.Time // when the server saw it
	Size       int       // length of the blob
	Ciphertext []byte    // opaque to the server
}

Everything except Ciphertext is plain data the server needs in order to do its job. It has to know where to deliver the blob, so it knows the recipient. It has to queue it, so it knows the time and size. The server needs the envelope, never the letter.

Add what the network layer shows: the IP address of each connection, the client version, push notification tokens, and when a device last came online. None of that is message content, and all of it is useful to an investigator.

Why the ciphertext stays shut

The decryption keys are generated on the endpoints and never sent to the server. Each device holds a private key; the server sees only public keys, which it hands out so that senders can encrypt. A provider cannot decrypt what it has no key for, and no court order changes the arithmetic.

Compare that with transport encryption only (TLS between you and the server). There the server decrypts on arrival, stores plaintext, and re-encrypts for delivery. The data is protected on the wire but fully readable by the operator, so an order for content has something to bite on.

  • Transport encryption only: provider holds plaintext, can be compelled to disclose it.
  • End-to-end encryption: provider holds ciphertext, cannot produce plaintext.
  • End-to-end encryption with an unencrypted cloud backup: the backup may hold plaintext, so the protection is only as good as the weakest copy.

Quick detour: why size and timing leak so much

Hang on, if the content is hidden, why is the size worth mentioning? Because a ciphertext's length tracks the plaintext's length closely. A tiny message is probably "ok" or a reaction; a large one is probably an image or voice note.

Combine that with timing and you can often infer a conversation's shape: who spoke, in what rhythm, and whether it went quiet before something happened. Some systems pad messages to hide length, but timing and the sender/recipient pairing are much harder to conceal. I went through one real attempt at this in the post on Signal's sealed sender.

Where the law sits

In the UK, the Investigatory Powers Act 2016 treats these categories differently. Interception of content is dealt with under Part 2 (interception warrants), while communications data, the "who, when, where and how" rather than the "what", is obtained under a separate regime in Part 3, with retention obligations in Part 4. Broadly, the threshold and authorisation process is lighter for communications data than for content. That is the statute's design, and you can read it on legislation.gov.uk.

Interception law also does not magically conjure plaintext. A warrant can require an operator to give assistance, but what an operator can practically do depends on what it holds. The Act has technical capability notices (section 253) that can include obligations about removing electronic protection applied by or on behalf of the operator. The key phrase is "applied by or on behalf of that operator". If the operator never held the keys, there is nothing of its own to remove.

How far such a notice could be stretched, for instance to require a provider to change its design, is contested and I would treat it as an open question rather than settled. Whether a particular notice or warrant would apply to a particular service depends on the facts, and this is general information, not legal advice.

The routes that remain

None of this makes content permanently out of reach. It just moves the target.

  • The endpoint. Messages are plaintext on your phone. Targeted equipment interference (Part 5 of the IPA) or a seized, unlocked device bypasses the encryption entirely.
  • The other party. Your recipient holds the same messages and can be asked, or compelled, to produce them.
  • Backups and sync. Cloud copies without end-to-end protection are readable by whoever holds the backup key.
  • Key disclosure. Separate powers can require a person to supply a password or key, which I covered in an earlier post on RIPA.

So the useful mental model is a split. Metadata is held by the provider in the clear and is reachable through the provider. Content is held by the endpoints in the clear and is reachable through the endpoints. A warrant aimed at the middle gets the envelopes.

If you run your own chat server, this is your design checklist: log less metadata than you think you need, pad where you can, and remember that the server you control is exactly the party an order would be served on.

← All articles