In February 2025 Apple withdrew Advanced Data Protection, its end-to-end encrypted iCloud option, for users in the United Kingdom.
Apple didn't explain why in any detail, and the reason it couldn't is the interesting part.
What is established¶
Being careful here, because this case gets reported heavily and accurately rather less often. What's solid:
- ADP was withdrawn for UK users in February 2025. That's observable.
- The Investigatory Powers Act allows the Home Office to issue a technical capability notice, and a recipient can be prohibited from disclosing that one exists. The power is in the statute.
- Apple has gone to the Investigatory Powers Tribunal (The Register), and the government's position is neither to confirm nor deny that an order was issued.
What's not established: whether a notice exists at all. The Home Office doesn't confirm or deny orders under the Act. Reporting that states flatly that one was issued is going beyond the record, however likely it may be.
The engineering content¶
Strip the politics out and you're left with a concrete technical claim, and it's the same one from the 1990s: that exceptional access can be added to an end-to-end encrypted system without weakening it for everyone.
The argument against isn't ideological. The access mechanism is itself an asset (a key, a key-escrow service, a client-side scanning hook) and assets get compromised. You aren't adding a door for one party. You're adding a door, and then making a separate claim about who can open it that rests on operational security rather than on mathematics. Every hotel that ever fitted a master key will tell you how that goes.
The second technical point is subtler and matters more for anyone building: end-to-end encryption is a property of a system rather than a feature of a product. Client-side scanning before encryption doesn't break the cryptography at all. It makes the cryptography irrelevant, which is why "the encryption is untouched" manages to be true and beside the point at once.
The chokepoint is who gets to mandate the code on the device.
Scanning on the device before encryption needs three things: code running on every handset, a list of what to look for and someone with the authority to update that list. Two companies ship the operating systems on which essentially all of the world's phones run. They already push code to those devices weekly, without asking, and the update mechanism is the most thoroughly engineered compulsion surface ever built. Nobody has to break encryption if they can instead ask Apple and Google to add a check in front of it.
What makes this different from the 1990s fight is that the chokepoint has moved from the algorithm to the device, and the device is not yours. In 1995 the argument was about export controls on a mathematical technique, which was unwinnable because maths does not have a factory. Today's argument is about a build pipeline with two owners, and that is an entirely winnable fight for a government. That is why this version is quieter. You do not need a public debate about key escrow when you can have a private conversation about a feature flag.
The second-order effect is worse. A scanning list is a general-purpose mechanism with one stated purpose. The infrastructure built to detect one category of material detects whatever is on the list. The list is not public, and the set of governments who will want their own entries on it is not small. Every operator who builds the capability has then to maintain a position on which states may use it. That is a political judgement a company is poorly placed to make and cannot decline to make once the code exists.
Where is the open version? Running, and holding up better than you might expect. Signal has said it will leave a jurisdiction rather than comply, which is the only credible answer a centralised service can give. The structurally stronger answer is to hold no key and run no registry, so there is nothing to hand over and no server to serve. That is buildable today on commodity hardware.
Here at AxisOps this is a design rule rather than an opinion. Customer data is encrypted under the customer's own keys, in vaults we do not hold the keys to, so we cannot read it even where we run the storage. The most reliable way to resist a demand for data is to be unable to satisfy it, and every key we do hold is a liability we are keeping warm for somebody else.
Because this is a design constraint rather than a news story.
If you build anything that holds other people's data in a jurisdiction with this kind of power, then "what could we be compelled to do, and could we comply even if we wanted to?" is an architecture question with real answers. An operator holding no key cannot be compelled to produce one. That's design, not defiance.
The flip side, and the thing worth being cheerful about: the same shift that makes device-side compulsion effective also makes end-to-end encryption ordinary. Messaging that nobody in the middle can read is now the default for billions of people, which was a cypherpunk aspiration within living memory. The fight is over the edges because the centre was won.
The prediction¶
The pattern across three decades is that these powers are sought, resisted, partially granted and never repealed. The statute outlasts the news cycle. Build on the assumption that the legal surface available to a future government is the one written down now, not the one currently being used.