Chat Control is really two separate threats stacked on top of each other: the voluntary scanning regime that just got extended, and CSAR, the mandatory scanning regime still being negotiated and commonly called Chat Control 2.0. We covered the vote itself in our last post. This one is more useful: exactly why CypherBay is already immune to the first, what would actually have to change for the second to reach it, and what you can add on top for the one thing no chat app can fix for you by itself.
Why Chat Control 1.0 already fails against CypherBay
The current exemption works by letting platforms voluntarily scan content they can already read. Meta and Google can do this because their servers hold your messages and photos in plaintext, or hold a key that can decrypt them on demand.
CypherBay never has that option. Every message and file is encrypted in your browser with AES-256-GCM before it ever leaves your device, and the encryption key is derived from your password locally, it never touches the server. What reaches us is ciphertext: unreadable, unstructured bytes. There is no algorithm that can scan content for patterns it never receives in readable form. Chat Control 1.0 is built to regulate what providers do with data they can read. We simply never have that data, so the regulation has nothing to act on.
What self-hosting shields you from under Chat Control 2.0
CSAR is a different problem, because its harshest drafts do not ask providers to scan data they already have, they would force scanning before encryption ever happens, directly on the device. That is a real threat to any hosted, commercial encrypted service, ours included, if it is ever passed in that form.
This is where self-hosting changes the equation. EU platform regulation, CSAR included, is written to govern commercial communication service providers: companies operating messaging infrastructure at scale for the public. If you download CypherBay and run it on your own webspace, for yourself and the people you personally invite, you are not operating a commercial communication service. You are running a private, single-purpose piece of infrastructure that never advertises, never onboards the public, and never appears on anyone's radar as a platform to regulate. Nobody is going to send an inspector to force a private individual's personal PHP server to install a client-side scanning hook. The legal machinery being built simply is not aimed at that scale, and realistically cannot be.
There is a second, quieter protection in being fully web-based instead of a native app: there is no App Store or Play Store listing at all. Governments have leaned on Apple and Google before to pressure or threaten to remove messaging apps that refuse to add backdoors, a scenario Signal has publicly warned about. A page that runs entirely in the browser cannot be pulled from a store, because it was never in one.
What else protects you, beyond scanning
- No accounts, no identity. No phone number, no email, nothing to subpoena from a third party. Just a self-chosen alias and a cryptographic session ID. Even a full server seizure gives an investigator ciphertext and aliases, not real identities.
- Ephemeral by design. Sessions self-destruct after an hour of inactivity. There is no permanent chat history sitting on disk, waiting for a raid or a data breach to expose it later.
- Zero friction for the other side. Nobody you talk to needs to install anything, register anything, or understand cryptography. A link and a password shared through a separate channel is the entire setup.
What CypherBay still cannot protect you from
We would rather tell you this plainly than let you assume more than the tool actually delivers.
The server sees the IP address of everyone who connects, ours included if you use the public instance. And if you use cypherbay.net instead of hosting it yourself, you are trusting whoever operates that server not to quietly serve you a tampered version of the client-side code. Encryption running in your browser is only as trustworthy as the code the server sent you that day. A compromised or legally coerced server could serve malicious JavaScript that captures your password before encryption ever runs, and you would have no way to see it happening. Self-hosting removes that trust requirement entirely, because you control the server that serves the code.
Closing the IP gap: Tor Browser, or a no-logs VPN
For the strongest option, use Tor Browser. Onion routing means no single party, not us, not your ISP, ever sees both who you are and what you connected to. It is slower, and some networks throttle or block it, which is the honest tradeoff.
When Tor is not practical, a VPN is a reasonable middle ground for hiding your IP from the server operator and your network. We use, and recommend, Mullvad VPN:
- No email, name, or payment details required to use it. You get a randomly generated account number, and you can pay with cash sent by mail or with Monero.
- Independently audited no-logs policy, repeated across multiple third-party audits.
- Fully open source apps on every platform, so the client's behavior is not something you have to take on faith.
- One flat price for everyone, no tiered plans designed to upsell you.
- WireGuard-based and fast enough that you will not be tempted to switch it off.
- Has previously confirmed that when authorities came asking, there was nothing to hand over, because they never log connection data to begin with.
This is not sponsored. We are not paid, and there is no referral code or affiliate link anywhere in this post. We recommend Mullvad because its entire design philosophy, minimize what you know about your users so there is nothing to hand over even if compelled, is the same principle CypherBay is built on, and because we actually use it ourselves. ProtonVPN and IVPN are other audited, no-logs options worth a look if Mullvad does not fit your needs.
The operating system underneath matters too
Client-side scanning, if CSAR ever forces it, would not run inside CypherBay. It would run in your operating system, or in the layer between your OS and the app: the same layer that already quietly scans your photos today. Stock Android backs up to Google Photos by default, and Google has run CSAM scanning against that library for years. iOS does the equivalent through iCloud Photos. This is not new, and it is not CSAR, but it shows exactly where scanning actually gets bolted on: not the chat app you're worried about, the platform underneath it that you never chose to audit.
Two changes here do more for your baseline privacy than almost anything else on this list:
- On mobile, use GrapheneOS. It is a hardened, de-googled Android fork with no Google services, telemetry, or bloatware baked in. If you need specific Google-dependent apps, its sandboxed Google Play runs them as a normal, permission-limited app with zero system-level access, instead of the privileged position Play Services normally holds. It ships with a hardened memory allocator and dozens of exploit-mitigation features on top of stock Android, not just app removal. Most day-to-day apps work fine; a handful of banking apps and Google Pay do not, by design, since those specifically check for the privileged access GrapheneOS refuses to grant.
- On desktop, use Linux instead of Windows or macOS. You are not fighting a single scanning feature, you are removing the always-on telemetry, cloud photo sync, and account-linked backup layers that Windows and macOS ship with by default. Fedora is a reasonable, low-friction default: it runs SELinux enforcing out of the box and defaults to Wayland, which isolates applications from each other far better than the old X11 display server most people still associate with Linux. If you occasionally need a session that leaves no trace at all, boot Tails from a USB stick: it forces all traffic through Tor and forgets everything the moment you shut it down. If you handle genuinely sensitive material as a matter of routine, Qubes OS compartmentalizes everything into isolated virtual machines, so a compromise in one part of your digital life cannot casually reach into another.
- Turn on full-disk encryption, on whatever you end up running. LUKS on Linux, or the equivalent on any OS you use. It is one setting during installation, and it is the difference between a stolen or seized device being a locked box versus an open book.
None of this is exotic anymore. GrapheneOS installs like any other Android image, Fedora installs like any other desktop OS, and the friction is smaller than most people assume before actually trying it.
None of this is legal armor. It is engineering: remove the data, remove the identity, remove the single point of trust, and there is nothing left for a scanning mandate to act on. Self-hosted, over Tor or a trustworthy VPN, is the closest thing to a complete answer that exists today. We will keep building toward making that setup as easy as the public instance already is.