In an emergency session of the European Parliament on July 9, 2026 right before the summer recess, Chat Control 1.0 was approved. The motion restored the authorization of Big Tech companies, including Discord, Google, Meta, Microsoft, and Snap, to voluntarily scan & moderate non-E2EE messages on their platform using dragnet surveillance tools – which would normally be in violation of European privacy laws.
Version 1.0 of Chat Control concerns the messaging features of social apps and hosted online services which do not use E2EE by default, including Facebook Messenger and Instagram chat, or cloud services such as Gmail, Outlook, Google Drive, and Microsoft OneDrive. Interestingly, Chat Control 1.0 explicitly excludes E2E encrypted apps, such as WhatsApp or Signal, from its scope.
This doesn’t mean however, that one can be assured of their privacy when using WhatsApp, even though it does implement E2EE. Government authorities have defeated WhatsApp’s message encryption by simply downloading the unencrypted cloud backups of users’ WhatsApp chats from their iCloud or Google Drive, where they are stored by default. Also, Chat Control 1.0 is simply paving the way for Chat Control 2.0, a much more invasive proposal for client-side content scanning, which will affect encrypted messaging apps equally as much as regular social apps.
For a long time, law enforcement & intelligence agencies constantly complained to lawmakers about E2EE messaging apps being a “blind spot” that hindered their information-gathering activities. In order to investigate a user, they needed to seize and compromise the endpoint device using exploits from tools such as Cellebrite or Graykey.
This required physical access to the device, which was much more difficult than simply intercepting a message over the air. Also, properly patched Android and iOS devices with a modern secure enclave (e.g. Pixel Titan processor or iOS Secure Enclave) were not usually vulnerable to the regular exploits in such digital forensics software, which mainly relied on already known flaws on outdated devices, or brute force attacks. The secure enclave makes PIN or password-guessing attacks impractical by enforcing an exponential backoff timeout – making it take decades or centuries to even guess a secure 6-digit PIN code. Zero-day exploits, such as those in the Pegasus spyware by the infamous NSO Group were also not a scalable option for everyday investigations. Once a zero-day exploit had been used once “in the wild”, it would become “burnt” and useless as soon as Apple or Google could patch their operating systems. For this reason, they were only used to monitor high value targets; in many cases, extra-judicially by autocratic or authoritarian regimes to break into the communications of legitimate opposition activists or investigative journalists.
With Chat Control 2.0, the threat model completely changes. If passed, it would enforce client-side content scanning at the OS level. It would force proprietary operating system code on Windows, MacOS, iOS, and Google Play Services on Android to use content hashing and AI computer vision to scan messages for “prohibited” content before they are even transmitted over the network. In order to sell it to the public, proponents of Chat Control 2.0 are using the red herring of child protection, which is simply a slippery slope to broader censorship and invasion of privacy. For instance, the content hashes against CSAM content are currently maintained by a centralized clearinghouse, the National Center for Missing and Exploited Children (NCMEC) in the US. Any message or file scanned by Google, Meta, or Microsoft on their platforms, which matches the content hashes provided by the NCMEC, is currently automatically reported to the NCMEC for follow-up by law enforcement. This might seem like a worthy use case, until one considers that the exact same technology can be used by governments to flag and report so-called “misinformation”, or simply subversive speech, before it even leaves your device.
Furthermore, AI vision models aiming to identify harmful content have already proven to be prone to false positives. Discord was slapping its users with irreversible bans for uploading any innocuous image which had a grid-like structure, because its AI moderation model had falsely identified such images as abuse content. Considering the enormous number of messages sent everyday, even a tiny percentage of false positives will overwhelm legitimate law enforcement activity. We would not want public authorities to follow the example of Microsoft or Meta, who had outsourced content moderation to unvetted, overseas contractors. This would place actual children at even greater risk than if the system had simply not existed at all.
In light of the server-side scanning of Chat Control 1.0 which is already active, and the client-side scanning proposals of Chat Control 2.0, decentralization & federation of chat infrastructure, in addition to more secure client devices (e.g. Linux desktops and GrapheneOS), are among the most powerful tools we have for avoiding dystopian mass surveillance. This is regardless of what happens in legislatures worldwide. The remainder of this article provides a detailed overview of Matrix’s unique security model, and how the RemoteRails Appliance incorporating a Matrix homeserver hardens this model even further.
Matrix provides an interoperable protocol for end-to-end encrypted chat, with Matrix IDs (similar to email addresses) in the format of @username:example.com, where username can be anything available in the namespace of your particular homeserver, and example.com is the address of the homeserver where your account resides. Like email servers, homeservers can be hosted by anyone with the sufficient technical know-how on their own hardware. In the Matrix network, a homeserver authenticates the account, enumerates the list of rooms, and stores chats strictly with zero-knowledge to even the Matrix server administrator. This means that no matter which homeserver you sign up with, only you and the people you are talking with can decrypt the contents of your chats (including media & attachments) even though they are stored and seamlessly synced across devices through the homeserver. When you sign up for Matrix ID, you are required to safely store a recovery key (preferably offline), similar to the seed of a crypto wallet.
Since decryption happens strictly on the client side, only you have the ability to recover your chats when you log on through a new device. Matrix actually builds on the Signal protocol, with its own Olm-Megolm ratchet (a session key) for encryption, ensuring that keys are automatically rotated (every 100 messages or 7 days) and maintaining Perfect Forward Secrecy. This means that even if an adversary were to intercept the ciphertext of your Matrix communications, they would not be able to decrypt your previous communications, even if they somehow managed to crack your long-term key (not mathematically possible with current computational power).
Government bodies themselves, including the Swedish government, French public service, the German military, and NATO are using their own implementations of the open source and independently reviewed Matrix protocol to safeguard their communications internally and with their citizens. In fact, Tuwunel, the high-performance Matrix homeserver built into the RemoteRails Appliance, is actively sponsored by the Swiss government and deployed at national scale to serve Swiss citizens through the Swiss Post ePost service.
The cross-device syncing without being dependent on a single device which could be lost or stolen, while preserving true end-to-end encryption, makes Matrix and its open source Element X client head and shoulders above the usability of WhatsApp or Signal.
WhatsApp, Threema, or Signal can only be logged in on one primary mobile device at a time, with additional devices being “linked devices” that require the primary device to be powered on regularly to continue syncing messages with the centralized server. The “linked device” model is a security weakness, considering that law enforcement regularly exploits PCs with Signal Desktop installed, in order to surreptitiously siphon a user’s Signal messages without their knowledge.
The Rust-based Matrix homeserver implemented in the privacy-focused RemoteRails Appliance has a clear session list so that outdated or unrecognized sessions can be immediately revoked by the user. Combined with our bespoke integration with Defguard VPN and OIDC SSO, the attack surface of the Matrix homeserver hosted on the RemoteRails Appliance is extremely narrow. In order to even use Element Web, Desktop, or Element X mobile clients to sign in to a Matrix ID, one must first be connected to the enterprise VPN based on WireGuard.
Another benefit of hosting a Matrix homeserver for your own family, team, or organization is that it minimizes metadata leakage compared to using public homeservers such as Matrix.org, or especially commercial chat services like WhatsApp that proactively map out your social graph through “contact uploading.”
If your instance is defederated (on the RemoteRails Appliance, this is the default), no external Matrix server on the Internet can know which internal users you are talking to – ensuring zero metadata leakage. A defederated Matrix instance can essentially be used as a self-hosted, VPN-isolated substitute for Slack or Microsoft Teams. Should you choose to optionally enable federation to talk with users and join rooms on other homeservers, this data is minimized to a need-to-know basis to route the chats and Element calls. On the RemoteRails implementation of Matrix, voice & video calls are signaled and routed through a private LiveKit & Coturn instance, which uses DTLS encryption and STUN/TURN holepunching, to ensure calls are protected to the same standard as Matrix chats while being able to traverse strict corporate firewalls.
Furthermore, unlike its mass-market counterparts, no phone number is needed to create a Matrix ID, which is particularly important in most countries with real-name registration laws even for prepaid SIM cards. This makes it way harder to tie a Matrix ID back to one’s real life identity than with WhatsApp or Signal, provided that the Matrix ID was created through a public Wi-Fi connection or VPN.
We recommend that anyone interested in a truly encrypted chat app, which provides a much stronger security model than Signal or Telegram, register for a free Matrix.org account at Element Web, through Element Desktop, or the Element X mobile client. Regardless of which client you use to initially register for your Matrix ID, you will be able to sign in across all your devices through cross-signed device verification – so long as you save your recovery key in a safe place. Like a free Gmail account, this account is sufficient for most personal use cases, such as talking to family and friends who have a Matrix account on any homeserver (does not necessarily need to be Matrix.org). Through federation, you can even open an encrypted chat with the RemoteRails team at our Matrix ID @remoterails:privacyte.ch (privacyte.ch is a private homeserver hosted with our appliance) to confidentially discuss our products & services, such as the RemoteRails Appliance.
For business or particularly sensitive use cases, we highly recommend hosting your own Matrix homeserver using a product such as the RemoteRails Appliance. Compared to other private messaging apps like Signal, you are able to audit the open source code running on both the server and client side, ensuring there are no hidden backdoors.
Although Signal is generally considered by civil society & journalistic organizations to be trustworthy, their reliance on opaque server-side code, such as an Intel SGX-based solution for contact discovery to mask their users’ social graphs from Foundation employees, is a weakness – particularly when compared to a fully open source solution such as Element / Matrix. Even though the code for Signal’s server infrastructure is transparently published in public repositories, there is no way to ascertain that this code is actually running on Signal’s AWS-hosted server clusters at any given time.
From a functionality perspective, self-hosting a Matrix homeserver using the RemoteRails Appliance allows you to issue personalized Matrix IDs to your users at your own domain (@username:yourdomain.com) authenticated by your own OIDC SSO, rather than a generic Matrix.org handle. It also ensures that even Olm-Megolm encrypted ciphertext and WebRTC packets flow through your own hardware – rather than that of an external server operator. You are able to set your own policies for backing up data locally or to off-site storage, and are not at the mercy of the uptime of Matrix.org. Besides a Matrix homeserver, the RemoteRails Appliance provides a complete office workspace in a box unified by SSO behind a private VPN, as a secure alternative to cloud office suites such as Microsoft 365 or Google Workspace – without a subscription-based pricing model that scales to the number of users.
Finally, as a privately hosted service for internal users, you entirely avoid the privacy-invading requirements of the UK Online Safety Act and EU Digital Services Act, which impose onerous ID verification requirements on public servers – and require each user to make a micro-transaction or hand over their ID to a third-party verification service to register. We also provide bespoke consulting for advanced Matrix architectural patterns, where users joining LiveKit calls span multiple continents, or custom chat retention (client-to-server encryption) is required for legal and compliance reasons.