Chat Control and encrypted messaging — what a scanner on your device would actually change
The European Union has spent four years trying to write a law that finds illegal material inside conversations nobody can read. The proposal is COM/2022/209 final, known to almost everyone as Chat Control. This page explains what it would do technically, states plainly what no messenger can promise about it, and sets out what OSHI does differently — an assistant that runs on your own device, no phone number, and messaging that keeps working when the network does not.
What is actually proposed
Chat Control does not ask anyone to break encryption. It asks providers to detect known and new illegal material, and grooming, in the services they operate — including services whose messages are end-to-end encrypted. The only place where a message exists in a readable form is the device that wrote it and the device that reads it. So a detection order lands there, before encryption, which is why the technique is called client-side scanning.
That is the whole of it. The cipher survives every draft of the text. What changes is that your phone acquires a component whose job is to look at what you typed, compare it against a list you did not choose, and report a match to someone else.
The objection is not political, it is structural
In 2021 fifteen cryptographers and security researchers published Bugs in our Pockets: The Risks of Client-Side Scanning. Their argument is not that scanning is wrong. It is that a scanner is a general-purpose surveillance capability installed on every device, and that the list it matches against is the part nobody can audit. Change the list and the same code finds something else.
The European Data Protection Board and the European Data Protection Supervisor reached a comparable conclusion in their joint opinion on the proposal. Apple announced on-device CSAM detection for iCloud Photos in 2021 and withdrew it, having built it.
What no messenger can honestly promise
Two orders, two answers. A detection order served on a provider finds nothing here: no plaintext on our servers, no account, no phone number, and an assistant that never transmits. A scanner mandated inside the operating system is defeated by no application, this one included — and any product that tells you otherwise is selling you something.
We would rather say that than imply a guarantee we cannot keep. The honest question is narrower and more useful: how much readable material exists on your device in the first place, and how much of it leaves for somebody else's computer? That part is a design decision, and it is where OSHI differs.
The assistant runs on your device
This is the one that matters most, and it is the one most easily checked. Every messenger adding AI features has to solve the same problem: a model that summarises your unread messages has to read your unread messages. The usual answer is to send the plaintext to a server. That creates exactly the readable copy a detection order would ask for — voluntarily, before any law requires it.
OSHI's assistant runs locally, through llama.cpp, on the phone itself. There is no call to a remote AI service anywhere in the iOS or the Android source: not OpenAI, not Anthropic, not Google, not anyone. Nothing is sent, so there is nothing to retain, subpoena or leak.
The price is real and we state it: the on-device model is several gigabytes, it costs battery, and it is materially weaker than a hosted model. We think that is the right trade for a messenger. You may not, and you can leave the assistant switched off.
The map is offline too
Location is the other place where a private app quietly becomes a client of somebody else's infrastructure. OSHI ships its own map: tiles are read from a local cache on the device first, and there is an offline-only mode that never reaches the network at all. When it does fetch a missing tile, it fetches from our own tile server, not from Google or Apple — and caches it so the next time is local.
A map you can read in a blackout, without telling a third party where you are looking, is a different object from a map that needs a network and an account.
It works when the network does not
A filtered network and a scanned device are different problems, and OSHI was built for the first one long before the second became a draft regulation. Messages relay phone to phone over Bluetooth Low Energy and Wi-Fi Direct — no internet, no cellular service, no operator — across up to five hops, with store-and-forward for the phone that was not in range at the time.
For distance beyond a room, OSHI pairs with a LoRa node and reaches kilometres. What OSHI puts on the LoRa air is encrypted end to end before it reaches the radio: someone with the right hardware can capture the frame — the default Meshtastic channel key is public — but cannot read what is inside it. Capturable, not decipherable.
There is no account to compel
OSHI asks for no phone number, no email and no account. Your identity is a keypair generated on the device and never uploaded. There is no registry that maps you to a number, no directory that lets a stranger reach you because they know it, and nothing for a legal request to produce that we do not have.
| Design decision | What it means under a scanning mandate |
|---|---|
| Assistant runs on the device | No plaintext copy is created on anyone else's computer, so there is none to hand over |
| No phone number, no account | No registry to compel, no directory to enumerate |
| Mesh over Bluetooth and Wi-Fi | A message that never reaches a network cannot be intercepted on one |
| LoRa payload encrypted before the radio | The air frame is capturable on a public channel and unreadable |
| Map read from a local cache | No third-party location provider learns where you looked |
| Cryptographic core published (MIT) | A scanner could not be added silently to the published files |
| Scanner mandated in the OS | Not defeated by any messenger, including this one |
Frequently asked questions
Can any messenger stop Chat Control?
There are two different orders here, and they need two different answers. Against a detection order served on a provider, OSHI has nothing to hand over: no plaintext on our servers, no account, no phone number, and an assistant that never sends anything anywhere. Where another messenger would have to deploy a detector, we do not hold the material it would run on. Against a scanner built into the operating system itself, no application protects you — including this one. Any product that claims otherwise is selling you something.
Does OSHI send my messages to an AI in the cloud?
No. OSHI's assistant runs on the device through llama.cpp. There is no call to a remote AI service anywhere in the iOS or Android source. The price is honest: the on-device model is several gigabytes and materially weaker than a hosted one.
Does OSHI work if the network is cut or filtered?
Yes. Messages relay phone to phone over Bluetooth Low Energy and Wi-Fi Direct with no internet and no cellular service, and over a paired LoRa node for kilometres of range. What OSHI puts on the LoRa air is encrypted before it reaches the radio: a frame can be captured on the public default Meshtastic channel, but not read.
Does OSHI need a phone number?
No. No phone number, no email, no account. Your identity is a keypair generated on the device, so there is no registry to subpoena and no directory that lets a stranger reach you from your number.
Is the encryption code published?
The cryptographic and mesh core is published under the MIT licence on GitHub, and the desktop client is published in full. The rest of the mobile app is not open source, and we say so rather than claiming more.
Read the long version
We wrote this up at length, with every source fetched and quoted, in Scanning the endpoint you promised not to touch — part of The Messenger Security Review, where findings that apply to OSHI itself are published alongside everyone else's.
Try it
Free and open source at the core. No phone number, no account, no email.