Can Client-Side Scanning Coexist with End-to-End Encryption?

The Online Safety Act 2023 contains a power over encrypted messaging that was never resolved during the bill's passage, just deferred. It waits on a technology nobody has accredited, and possibly nobody can build.

Under section 121, Ofcom can serve a "technology notice" on a regulated service. The notice requires it to "use accredited technology" to identify and take down terrorism content or CSEA (child sexual exploitation and abuse) content, including on private messaging.

The government's line throughout, repeated by Lord Parkinson in the Lords, was that this would only ever apply once suitable technology was "technically feasible" without undermining the security of the service. Nobody in government claimed the technology existed at the time.

Three years on, it still doesn't, officially:

• Ofcom's December 2024 Statement on Illegal Harms says no technology has been accredited.
• Ofcom is due to advise the Secretary of State on minimum standards of accuracy around April 2026.
• Only after that would an accreditation process even start.

So the interesting question isn't "will the UK ban encryption". It hasn't, and section 121 doesn't say that. The narrower, more useful question: what would a system have to do to clear the bar the Act sets, and does anything like that bar exist as an engineering target rather than a political one?

The statute is mostly process waiting for one answer

Section 121 gives two routes. A provider can be told to use accredited technology outright. Or, more commonly for anything novel, it can be told to use "best endeavours to develop or source technology" that meets standards the Secretary of State will publish.

Around that sit several gates:

• Before any notice is issued, section 122 requires Ofcom to commission a report from an independent "skilled person".
• The whole thing is gated by a "necessary and proportionate" test.
• Accreditation itself is defined in section 125. It turns on the technology meeting minimum standards of accuracy that the Secretary of State sets by regulation, not standards Ofcom or the provider gets to define for itself.

That's a lot of institutional plumbing in front of a single technical question. Can you build something that reliably flags CSAM:

• without also being a general-purpose content inspector;
• without an unacceptable false positive rate at scale;
• without requiring the provider to hold the plaintext of everyone's messages to do it?

Everything downstream of that question, the skilled person's report, the ministerial standards, the accreditation regime, is process built to wait for an answer that may not arrive in the form the Act assumes.

The best-case candidate: Apple's NeuralHash

Apple's NeuralHash is the only client-side CSAM detection scheme engineered to production quality and documented in public. It was announced in August 2021 and shelved in December 2022 after sustained technical criticism.

It's worth walking through because it's the honest best-case example of what "privacy-preserving" client-side scanning currently looks like.

How a perceptual hash differs from a cryptographic one

NeuralHash is a perceptual hash. A neural network reduces an image to a fixed-length fingerprint designed to survive resizing, recompression and minor edits. A cryptographic hash such as SHA-256 is the opposite: it changes completely if a single pixel does.

Apple's design worked like this:

1. Run the hash on-device, before upload.
2. Compare it against a blinded database of known CSAM hashes supplied by child safety organisations.
3. Use private set intersection plus threshold secret sharing, so Apple doesn't learn about every photo a user takes. Each photo produced a "safety voucher" that only became decryptable once a threshold number of vouchers (originally 30) matched entries in the database.

Below the threshold, Apple learned nothing at all, in principle. That's a genuinely clever piece of applied cryptography for the narrow problem of "don't reveal individual non-matches". It does not touch the two problems that actually killed the scheme.

Where perceptual hashing breaks

It isn't adversarially robust

Within days of researchers reverse-engineering NeuralHash out of iOS, independent groups had produced hash collisions. They found two visually distinct images sharing a hash, and pairs of images that looked identical to a human but hashed differently.

A perceptual hash has to tolerate small, benign transformations. That's exactly the property an attacker exploits to build either:

• evasions: perturb real CSAM until it doesn't match; or
• collisions: craft an innocuous image that matches a known-bad hash, to frame someone or pollute a moderation queue.

This isn't a bug that got patched. It's close to intrinsic to what a perceptual hash is for.

The arithmetic of scale is brutal

Even a near-perfect classifier struggles. Say a hash-matching system has a false positive rate of one in ten million, which would be an excellent result for this kind of classifier.

A messaging service handling a billion images a day still generates on the order of a hundred false flags daily. Each is a real photo from someone's phone that a human reviewer, at the service provider, at a third party, or at the National Crime Agency, now has to look at, out of context, to clear.

Push the threshold down to reduce false positives and you push false negatives up. That's the entire point of the exercise failing quietly instead.

Neither of these is a private set intersection problem. They're properties of the underlying classifier, and no amount of cryptographic wrapping around "who learns about a match" changes what counts as a match in the first place.

Even a perfect classifier moves the trust boundary

A group of prominent cryptographers, including Ross Anderson, Whitfield Diffie, Susan Landau and Bruce Schneier, laid out this objection in "Bugs in Our Pockets: The Risks of Client-Side Scanning" (2021). Scanning content on the device, before it's encrypted (or symmetrically, after it's decrypted on the receiving end), moves the trust boundary that end-to-end encryption exists to protect.

E2EE's actual security property isn't "the network operator can't read your messages". It's "nobody but the endpoints can". Client-side scanning inserts a third party's classifier, and by extension a third party's database and threshold, at the endpoint itself.

Whether the resulting report leaves the device via an encrypted channel or a plaintext one is beside the point. The endpoint has become an inspection point the user doesn't control, running code they can't audit, against a database whose contents they will never see.

Quick detour: GCHQ's ghost protocol hit the same wall

The same objection sank an earlier, differently shaped UK proposal. GCHQ's 2018 "ghost protocol" suggested silently adding a law enforcement participant to an encrypted group chat or call, rather than scanning content at all.

An open letter in 2019 from Apple, Google, Microsoft, WhatsApp and a long list of security researchers made essentially the same point. A mechanism that lets a third party into the conversation, however narrowly scoped on paper, is a structural change to the security model, not a policy toggle you flip only for the good guys.

Once the mechanism exists, its scope is a matter of who gets to configure it. That's a much softer target than the cryptography.

It isn't just a British argument

The EU has been running a parallel and considerably more advanced version over its proposed CSAM Regulation, informally "chat control". It has stalled repeatedly in Council over near-identical objections from its own legal service and data protection supervisors about detection orders applying to encrypted services.

It's a useful reminder that this isn't a specifically British disagreement about a specifically British statute. It's the same unresolved tension surfacing wherever a legislature tries to write "scan, but only in the ways we approve of" into law.

Nothing public clears all three bars in section 121

Taking the Act at face value, "technically feasible" accredited technology would need to:

1. hold up under the Secretary of State's minimum standards of accuracy;
2. survive a skilled person's independent report;
3. do all that without becoming the kind of general-purpose inspection point the cryptographers above object to.

Nothing publicly documented does all three. Perceptual hashing gets partway on accuracy for known, static CSAM at enormous scale. It fails outright against adversarial content, novel material, or de-anonymised metadata about who gets flagged.

It also fails the second objection categorically, because the entire design is "put a classifier on the device".

Ofcom's own timeline, no accreditation regime before 2026 at the earliest, reads less like regulatory caution and more like an honest acknowledgement. The statute is waiting on an invention that may not be a coherent engineering target at all.

"Technically feasible" is carrying a lot of weight in that sentence. The weight isn't "hasn't been built yet". It's "may not be buildable as specified", which is a different and much harder problem for a regulator to sit in front of indefinitely.