We can't hide a scanner in code you can read.
Client-side scanning inspects content on your own device — before it is encrypted, or after it is decrypted. It is often presented as a way to "protect children without breaking encryption". That framing is misleading. Client-side scanning does not break end-to-end encryption mathematically; it bypasses it. The encryption keeps working. The inspection simply happens at the one place where your message still exists in plaintext: your device.
How it is supposed to work
- A perceptual hash — a fingerprint designed to survive resizing, cropping and re-encoding — is computed on your device for each image or file.
- That fingerprint is compared against a database of hashes of known illegal material, shipped to the device.
- Matches are flagged and reported — before the content is ever encrypted and sent.
What the research actually shows
Client-side scanning has been examined closely by the cryptographic community, using Apple's proposed NeuralHash system as the reference case. The findings are consistent, and they cut both ways:
- It can be evaded by the people it targets.Peer-reviewed work on NeuralHash showed the hash computation is not robust against gradient- or transformation-based image manipulation: small changes defeat detection while leaving the image unchanged to a human eye.
- It can be weaponised against people it does not target.The same line of research — and later black-box collision attacks against both NeuralHash and Microsoft PhotoDNA — showed an attacker can perturb an ordinary image until its fingerprint matches a flagged one. An innocuous picture can be crafted to trip the alarm on someone else's device.
- The list is unauditable by construction.The device compares against hashes, not images. Nobody outside the operator can verify what a given hash corresponds to. A system built to match one category of content will match whatever the list says it matches.
Apple proposed exactly this — NeuralHash, scanning iCloud Photos uploads on the device — and, after consultation, decided not to proceed. It never shipped.
Why it is a backdoor
A backdoor is not defined by intent. It is defined by capability: a mechanism through which someone other than the participants can read the content. Client-side scanning is precisely that mechanism, installed at the only point where reading is still possible. Once the hook exists, what it scans for is a policy setting, not an engineering one — and policy changes.
An end-to-end encrypted service with a scanner on the device is not an end-to-end encrypted service. It is a surveillance service with an encrypted transport.
Why uOS will not ship one
- There is no binary to hide it in.uOS is a web operating system: the client is delivered to your browser and executed there. The code that runs is the code you can open in your browser's developer tools. A scanner could not be added quietly — it would sit in the code you can read, on every single load.
- It would breach the boundary the whole system is built on.Every app in uOS inherits one post-quantum, end-to-end encrypted boundary. A device-side scanner is a hole in that boundary for every app at once — not just for messages.
- We will not implement it, and we will contest any order to.Any mechanism that inspects content before encryption is a backdoor regardless of its stated purpose. Where an order requires one, we will seek judicial review before any compliance.
Where this connects to Chat Control
In its most contested form, CSAR ("Chat Control 2.0") would require even end-to-end encrypted services to detect known material — which, for an encrypted service, can only mean scanning on the device. That is why the client-side scanning debate and the Chat Control debate are the same debate. Our position on the regulation follows directly from the technical facts on this page.