The Online Safety Act's Encryption Clash: What 'Technically Feasible' Client-Side Scanning Would Actually Require
Buried in the Online Safety Act 2023 is a power that never quite got resolved during the bill's passage, just deferred. Under section 121, Ofcom can serve a "technology notice" on a regulated service requiring 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, and Ofcom is due to advise the Secretary of State on minimum standards of accuracy around April 2026, after which an accreditation process would even start.
So the interesting question isn't "will the UK ban encryption" (it hasn't, and section 121 doesn't say that). It's narrower and more useful: what would a system have to do to clear the bar the Act actually sets, and does anything resembling that bar exist as an engineering target rather than a political one?
What the statute actually asks for
Section 121 gives two routes. A provider can be told to use accredited technology outright, or, more commonly for anything novel, to use "best endeavours to develop or source technology" that meets standards the Secretary of State will publish. Before any notice is issued, section 122 requires Ofcom to commission a report from an independent "skilled person," and the whole thing is gated by a "necessary and proportionate" test. Accreditation itself is defined in section 125, and 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 sitting 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, and 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 technology on offer: perceptual hashing
The only client-side CSAM detection scheme that's been engineered to production quality and documented in public is Apple's NeuralHash system, 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.
NeuralHash is a perceptual hash: a neural network reduces an image to a fixed-length fingerprint designed to survive resizing, recompression and minor edits, unlike a cryptographic hash such as SHA-256, which changes completely if a single pixel does. Apple's design ran this hash on-device, before upload, and compared it against a blinded database of known CSAM hashes supplied by child safety organisations. To avoid Apple learning about every photo a user takes, the scheme used private set intersection combined with threshold secret sharing: 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
First, perceptual hashes are not adversarially robust. Within days of researchers reverse-engineering NeuralHash out of iOS, independent groups had produced hash collisions: 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, which is 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.
Second, the arithmetic of scale is brutal even with a near-perfect classifier. 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 one 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, which is 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.
The argument that isn't about accuracy at all
Even a hypothetical perfect classifier runs into the objection that a group of prominent cryptographers, including Ross Anderson, Whitfield Diffie, Susan Landau and Bruce Schneier, laid out 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 a third party's 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 been turned into an inspection point that the user doesn't control, running code they can't audit, against a database whose contents they will never see.
That's also the objection that sank an earlier, differently-shaped UK proposal: GCHQ's 2018 "ghost protocol," which suggested silently adding a law enforcement participant to an encrypted group chat or call rather than scanning content at all. An open letter from Apple, Google, Microsoft, WhatsApp and a long list of security researchers in 2019 made essentially the same point about it: 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, and that's a much softer target than the cryptography.
The EU has been running a parallel and considerably more advanced version of this argument over its proposed CSAM Regulation, informally "chat control," which 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.
What would actually satisfy section 121
Taking the Act at face value, "technically feasible" accredited technology would need to hold up under the Secretary of State's minimum standards of accuracy, survive a skilled person's independent report, and do all that without becoming the kind of general-purpose inspection point the cryptographers above are objecting to. Nothing publicly documented does all three. Perceptual hashing gets partway on accuracy for known, static CSAM at enormous scale, and 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 that 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, and it's worth noticing that the weight it's carrying 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.