Tag: end-to-end encryption uk

  • The Technical Reality of the UK Online Safety Act’s Proactive Detection Requirements: What Platforms Are Actually Building to Scan Your Messages

    The Technical Reality of the UK Online Safety Act’s Proactive Detection Requirements: What Platforms Are Actually Building to Scan Your Messages

    The Online Safety Act finally got its teeth. Ofcom’s codes of practice are in force, and platforms operating in the UK are now staring down a legal obligation to detect child sexual abuse material (CSAM) and terrorism content. The political framing is simple. The technical reality is anything but. I’ve spent time reading through Ofcom’s published guidance, the responses from cryptographers, and the actual patent filings from a couple of the major players, and what’s emerging is a genuinely uncomfortable collision between surveillance engineering and the mathematics that makes private communication possible.

    Dark hacker at laptop with terminal code related to Online Safety Act message scanning UK technical analysis
    Photo by Sora Shimazaki on Pexels

    What Ofcom is actually asking platforms to do

    The Act doesn’t mandate a specific technology. What it does is require platforms to use “accredited technology” to identify illegal content, including CSAM, where technically feasible. Ofcom’s published illegal content judgements set the benchmark for what counts as compliance. The phrase “where technically feasible” is doing enormous work in that sentence, and everyone knows it. It’s the legislative equivalent of “sort it out somehow”.

    The two dominant technical approaches being evaluated are client-side scanning (CSS) and server-side hash-matching. They sound similar. They’re not. Server-side hash-matching is what platforms like Facebook Messenger (in its non-encrypted mode) have run for years: you check a file’s hash against a database of known illegal hashes maintained by the Internet Watch Foundation (IWF) or the National Center for Missing and Exploited Children. Easy, non-invasive on E2EE, already deployed. The problem is it only catches known, unmodified content. Crop the image by one pixel, the hash changes. Attackers have known this for a decade.

    Client-side scanning: how the tech actually works

    CSS is the bit that’s causing genuine alarm amongst cryptographers. The idea: before a message or image is encrypted on your device, a local classifier runs on it. If it flags a match against a database of illegal content hashes or a neural classifier trained to recognise CSAM, it can either block the send or generate an alert that gets passed server-side alongside enough decrypted metadata to allow a human review. The encryption still happens. But the scanning happened before it did. This is the crux of the Online Safety Act message scanning UK technical debate.

    Apple’s now-abandoned CSAM detection system (which it pulled in 2023 under pressure) used perceptual hashing via a system called NeuralHash. Rather than a cryptographic hash, NeuralHash generates a fingerprint that’s robust to minor image modifications, so slightly cropped or recompressed versions of known illegal images still match. The hashes were compared locally against an encrypted set derived from NCMEC’s database, using a threshold system: only if enough hashes matched did the system escalate. The cryptographic implementation used a technique called private set intersection so that Apple itself couldn’t see which specific hashes triggered a match.

    Why the cryptographic community is furious

    Researchers at MIT, the University of Cambridge, and Johns Hopkins published a detailed takedown of CSS proposals back in 2021, and nothing has fundamentally changed. The core problem is what I’d call the trusted-client paradox. End-to-end encryption’s security model rests on the premise that only the communicating parties hold the keys. CSS breaks that model not by attacking the encryption directly, but by placing an agent inside the trusted endpoint that answers to a third party. Your phone becomes a surveillance node you don’t control.

    There’s also the classifier reliability problem. Neural perceptual hash classifiers trained on CSAM databases have documented false positive rates. The IWF’s own hash list isn’t static; it changes. What happens when a legal image gets added to the blocklist in error? You get wrongly flagged, your account gets reviewed, and you have essentially no recourse because the detection system is opaque by design. That’s not a theoretical risk. Similar hash-matching systems have already caught legal content. And then there’s the mission creep concern: a scanning system built for CSAM is architecturally identical to one built for political speech. The same infrastructure can be repointed.

    Signal and WhatsApp have both been explicit: if compelled to implement CSS, they’d exit the UK market. Signal’s president Meredith Whittaker called it a “fantasy” that scanning could be made safe. Threema has said the same. The platforms that remain silent on this are the ones you should probably be more worried about.

    What the implementation timeline actually looks like

    Ofcom’s milestones have slipped, but not by as much as some hoped. Category 1 and 2B platforms (the big ones, basically) had to complete their illegal content risk assessments by March 2025. Proactive technology requirements for CSAM detection are expected to be formally enforceable through 2026 and into 2027, with the Ofcom technology notice mechanism being the stick. A technology notice can compel a specific platform to use a specific technology. That’s the legal weapon. No platform has received one yet, but the threat is real.

    The platforms most at risk are the smaller, privacy-focused ones that can’t afford to fight a legal battle or build a compliant system from scratch. Large operators like Meta have the engineering resource to implement something, even if what they implement is deliberately ineffective. Smaller operators just fold. I’d argue that’s actually the most likely outcome for most of the UK’s niche encrypted messaging landscape: quiet withdrawal or quiet non-compliance, with enforcement focused on the visible large platforms.

    The encrypted messaging architecture problem

    The fundamental tension is this: you cannot have both mathematically robust E2EE and server-side visibility into message content. These are mutually exclusive properties. The Online Safety Act message scanning UK technical debate isn’t really a policy disagreement, it’s a dispute about whether a mathematical impossibility can be legislated away. It can’t. What you can do is implement something that looks like scanning without breaking E2EE in a catastrophic or obvious way, and CSS is that thing. It’s a political solution dressed up as a cryptographic one.

    Some researchers are proposing alternatives. Homomorphic encryption-based approaches could theoretically allow a server to compute on encrypted data without seeing it, but the computational overhead is currently too heavy for real-time message scanning at scale. Zero-knowledge proof systems are another avenue, where a user could prove to a server that a message doesn’t match a banned hash without revealing the message. These are interesting. They’re also years away from practical deployment.

    The IWF continues to operate its hash-matching services and actively works with platforms on a voluntary basis. Their PhotoDNA integration predates the Act. What changes with the Act is that voluntary becomes compelled, and the scope expands beyond known-hash CSAM into AI-generated content and real-time video, where the technical problem is significantly harder.

    If you’re running a security operation or pentesting communications infrastructure, understanding this landscape matters. The architecture decisions platforms make under legal pressure create new attack surfaces. A mandatory CSS system that can generate decryption-adjacent alerts is a target. A perceptual hash database is a target. And as we’ve covered before when looking at the GOV.UK Notify API stack, the moment you build a system that can generate official-looking alerts or intercept communications at scale, you’ve created something that adversaries will probe. The legal mandate doesn’t make the resulting infrastructure safe. It just makes it mandatory.

    There’s also a parallel worth drawing to other UK surveillance infrastructure. The same legislative logic that built the national ANPR network into a mass-retention system now applies to message content. The technology gets built for a narrow purpose and then the retention and access rules drift over time. That pattern is consistent enough to be a reasonable prediction, and it’s one the civil liberties community has been making loudly since the Act’s second reading. The difference here is that ANPR doesn’t break the physics of road travel. CSS does break the mathematics of encryption. That’s the distinction that matters.

    My read: the UK ends up with a patchwork. Large platforms implement something, probably a combination of server-side hash-matching for known CSAM and some form of restricted CSS for high-risk categories. Privacy-first platforms either leave or go underground. The cryptographic community remains furious and publishes increasingly detailed breakdowns of why the whole thing is security theatre. Ofcom issues a technology notice to one visible non-compliant platform as an example. And the actual bad actors, as they always do, adapt faster than the regulation can track them.