Articles / Privacy Law

  • uk-law
  • investigatory-powers-act
  • interception
  • self-hosting
  • matrix
  • encryption

Would an Interception Warrant Reach Your Self-Hosted Chat Server?

The Investigatory Powers Act 2016 has no size threshold. If you run a Matrix, XMPP or Mattermost server for a few friends from a cupboard in the UK, the statutory definitions are wide enough that you may well count as a "telecommunications operator". Whether anyone would ever serve you with a warrant is a separate question, and a far less alarming one.

This is general information, not legal advice. I'll try to keep apart what the Act says, what I think it means, and what is guesswork.

Are you a telecommunications operator?

Section 261 of the Act defines the term. In outline, it covers anyone who offers or provides a telecommunications service to people in the UK, or who controls or provides a telecommunication system that is in the UK or controlled from the UK. That is legislation, and you can read it on legislation.gov.uk.

A "telecommunication system" is any system for facilitating the transmission of communications by electrical or electromagnetic means. A chat server relaying messages between users fits that wording comfortably. A "telecommunications service" is, broadly, providing access to such a system and its facilities.

So the honest reading is: nothing in the definition excludes a small private server. That is my interpretation of the text, not a court decision. I'm not aware of any ruling that settles where a hobby service sits, so treat anyone who tells you confidently either way with suspicion.

What a warrant would actually ask for

A targeted interception warrant is the relevant type. The Secretary of State issues it, and a Judicial Commissioner has to approve it (the "double lock"). It must be necessary and proportionate for a permitted purpose, such as national security or preventing serious crime.

Once a warrant is served on an operator, the Act puts a duty on that operator to take the steps required to give it effect. Those duties are limited to what is reasonably practicable. For a chat server, that realistically means:

  • copying messages for a named account as they pass through, or
  • handing over messages already stored on the server, which the Act treats as still within the scope of interception, and
  • supplying the related communications data: who talked to whom, when, from which IP address.

Unauthorised disclosure of the warrant's existence is itself an offence. If you were ever served, you could not post about it, and the usual advice is to talk to a solicitor who knows this area before you talk to anyone else.

Quick detour: why your own server isn't an offence to run

Hang on, if interception is a crime, how are you not committing it every time your server reads a message to route it? Because the offence in section 3 is about interception without lawful authority, and the Act carves out the person who has the right to control the operation of a private system, or who has consent.

For a public service with outside users, that carve-out is less comfortable than it first looks. Which is another reason to be clear in your terms with your users about what you can and cannot see.

What the server holds decides what you can hand over

A warrant can only require you to produce what you can reasonably produce. The practical picture depends on how you configured things:

  • Unencrypted rooms or plain XMPP: the server sees message bodies. A warrant could get you to disclose them.
  • End-to-end encrypted rooms: the server stores ciphertext, and the keys live on users' devices. You can hand over ciphertext, which is of little use to anyone.
  • Metadata in either case: room membership, timestamps, account names, device lists and IP addresses in your web server logs. This is often what is wanted, and E2EE does nothing for it.

That last point matters. If you want to be able to say truthfully that you hold very little, log less. Short retention on access logs, no message-level debug logging left on, and a database that does not keep deleted events forever all shrink what exists to be demanded.

Can they force you to break the encryption?

A warrant alone does not oblige you to remove encryption you did not apply. Section 253 technical capability notices are the separate tool for requiring an operator to maintain capabilities, including removing electronic protection the operator applied. They go through a different approval process and are aimed at large providers.

For a self-hosted E2EE server, the server does not hold the keys, so there is nothing for you to remove. Writing code to weaken the clients is a different and much larger demand, and it would run into the "reasonably practicable" limits quickly. I would not expect that against a hobbyist, but the Act does not rule it out on size alone.

Compelled key disclosure under RIPA Part 3 is another route, aimed at a person who holds a key. It would only matter if you actually held one.

The stored-data routes sit alongside

Interception is not the only power. Authorities can also seek communications data from an operator under Part 3 of the Act, and a retention notice under Part 4 can require an operator to keep certain data. Equipment interference warrants under Part 5 target devices rather than operators. None of these need your server to be "in transit" at the time.

What I'd do about it

  1. Enable E2EE by default for rooms, so your server holds ciphertext.
  2. Trim logs and database retention to what you need to run the service.
  3. Write down what the server stores, so you can answer a lawful request quickly and accurately.
  4. Do not promise users that you "cannot be compelled". You can promise what you hold, which is a smaller and truer claim.

Realistically, the chance of a warrant landing on a friends-and-family server is tiny. The useful exercise is that the same steps make the server leak less to everyone else too.