[TRANSLATED ARTICLE]

EU chat control comes – through the back door of voluntariness

The EU states have agreed on a common position on chat control. Data protection advocates warn against massive surveillance. What is in store for us?

After lengthy negotiations, the EU states have agreed on a common position on so-called chat control. Like from one Minutes of negotiations of the Council working group As can be seen, Internet services will in future be allowed to voluntarily search their users' communications for information about crimes, but will not be obliged to do so.

The Danish Council Presidency wants to get the draft law through the Council "as quickly as possible", "so that the trilogue negotiations can begin promptly", the minutes say. Feedback from states should be limited to "absolute red lines".

Consensus achieved

The majority of States supported the compromise proposal. At least 15 spoke in favor, including Germany and France. Germany "welcomed both the deletion of the mandatory measures and the permanent anchoring of voluntary measures", said the protocol.

However, other countries were disappointed. Spain in particular "continued to see mandatory measures as necessary, unfortunately a comprehensive agreement on this was not possible". Hungary also "seen voluntariness as the sole concept as too little".

Spain, Hungary and Bulgaria proposed "an obligation for providers to detect, at least in open areas". The Danish Presidency "described the proposal as ambitious, but did not take it up to avoid further discussion.

The organization Netzpolitik.org, which has been reporting critically on chat control for years, sees the plans as a fundamental threat to democracy. "From the beginning, a lobby network intertwined with the security apparatus pushed chat control", writes the organization. “It was never really about the children, otherwise it would get to the root of abuse and violence instead of monitoring people without any initial suspicion.”

Netzpolitik.org argues that "encrypted communication is a thorn in the side of the security apparatus". Authorities have been trying to combat private and encrypted communication in various ways for years.

A number of scholars criticize the compromise proposal, calling voluntary chat control inappropriate. "Their benefits have not been proven, while the potential for harm and abuse is enormous", one said open letter.

According to critics, the planned technology, so-called client-side scanning, would create a backdoor on all users' devices. Netzpolitik.org warns that this represents a "frontal attack on end-to-end encryption, which is vital in the digital world".

The problem with such backdoors is that "not only the supposedly 'good guys' can use them, but also resourceful criminals or unwell-disposed other states", argues the organization.

Signal considers withdrawing from the EU

Journalists' associations are also alarmed by the plans. The DJV rejects chat control as a form of mass surveillance without cause and sees source protection threatened, for which encrypted communication is essential. The infrastructure created in this way can be used for political control "in just a few simple steps", said the DJV in a statement Opinion.

The Messenger service Signal Already announced that it would withdraw from the EU if necessary. Signal President Meredith Whittaker told the dpa: “Unfortunately, if we were given the choice of either undermining the integrity of our encryption or leaving Europe, we would make the decision to leave the market.”

Next steps in the legislative process

The Permanent Representatives of the EU states are due to meet next week on the subject, followed in December by the Ministers of Justice and Home Affairs, these two bodies are due to approve the bill as the Council's official position.

The trilogue then begins, in which the Commission, Parliament and Council must reach a compromise from their three draft laws. Parliament had described the original plans as mass surveillance and called for only unencrypted suspect content to be scanned.

The EU Commission had originally proposed requiring Internet services to search their users' content for information about crimes without cause and to send it to authorities if suspected.

Die EU-Chatkontrolle kommt – durch die Hintertür der Freiwilligkeit

Die EU-Staaten haben sich auf eine gemeinsame Position zur Chatkontrolle geeinigt. Datenschützer warnen vor massiver Überwachung. Was blüht uns?

^{Marcel Kunzmann (heise online)}

Notable changes in version 90:

• add support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold with either the stock OS or near future GrapheneOS releases
• add back check for Auditee support for remote verification
• update Android target API level to 36 (Android 16)
• switch transition for QR scanning activity to handle target API level 36 predictive back more smoothly
• properly distinguish unknown vs. invalid values for extended GrapheneOS security information covering auto-reboot, etc.
• fix displaying lowest possible auto-reboot timer supported at a low-level in the OS
• remove unused support for new pairings without StrongBox (secure element keystore as opposed to a less secure Trusted Execution Environment keystore)
• add support for new key attestation root certificate launching in February 2026
• add new protocol version 7 with a new DEFLATE dictionary adding the new attestation root and dropping the non-StrongBox sample
• raise minimum app version for Auditee to 87 which was released over a year ago
• add new far future Let's Encrypt roots to TLS key pinning configuration
• drop obsolete workaround for old Android versions on 6th gen Pixels not declaring attest key support
• drop unsupported legacy devices without Android 13 or later from supported device list
• enable hardware memory tagging for use outside of GrapheneOS in the narrow cases where it's available for apps opting into it (Android 16 Advanced Protection Mode on hardware with support for MTE)
• update ZXing barcode scanning library to 3.5.4
• update CameraX (AndroidX Camera) library to 1.5.1
• update Bouncy Castle library to 1.82
• update Guava library to 33.5.0
• update Material Components library to 1.13.0
• update AndroidX Core library to 1.17.0
• update AndroidX AppCompat library to 1.7.1
• update Gradle to 9.2.1
• update NDK to 29.0.14206865
• update Android Gradle plugin to 8.13.1
• update Kotlin to 2.2.21
• update Android build tools to 36.1.0

A full list of changes from the previous release (version 89) is available through the Git commit log between the releases.

The Auditor app uses hardware security features on supported devices to validate the integrity of the operating system from another Android device. It will verify that the device is running the stock operating system with the bootloader locked and that no tampering with the operating system has occurred. It will also detect downgrades to a previous version.

It cannot be bypassed by modifying or tampering with the operating system (OS) because it receives signed device information from the device's Hardware Security Module (HSM) including the verified boot state, operating system variant and operating system version. The verification is much more meaningful after the initial pairing as the app primarily relies on Trust On First Use via pinning. It also verifies the identity of the device after the initial verification. Trust is chained through the verified OS to the app to bootstrap software checks with results displayed in a separate section.

This app is available through the Play Store with the app.attestation.auditor.play app id. Play Store releases go through review and it usually takes around 1 to 3 days before the Play Store pushes out the update to users. Play Store releases use Play Signing, so we use a separate app id from the releases we publish ourselves to avoid conflicts and to distinguish between them. Each release is initially pushed out through the Beta channel followed by the Stable channel.

Releases of the app signed by GrapheneOS with the app.attestation.auditor app id are published in the GrapheneOS App Store which provides fully automatic updates. Each release is initially pushed out through the Alpha channel, followed by the Beta channel and then finally the Stable channel. These releases are also bundled as part of GrapheneOS and published on GitHub.

Releases · GrapheneOS/AppStore

Contribute to GrapheneOS/AppStore development by creating an account on GitHub.

^GitHub

Changes in version 165:

• disable DeviceDoctor subsystem to avoid failing to notify users about certain Play services crashes from it killing the process after handling uncaught exceptions itself

A full list of changes from the previous release (version 164) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Comparing config-164...config-165 · GrapheneOS/platform_packages_apps_GmsCompat

Contribute to GrapheneOS/platform_packages_apps_GmsCompat development by creating an account on GitHub.

^GitHub

Changes in version 164:

• add stub for BluetoothLeBroadcastAssistant::getConnectedDevices()
• update Android Gradle plugin to 8.13.1

A full list of changes from the previous release (version 163) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Comparing config-163...config-164 · GrapheneOS/platform_packages_apps_GmsCompat

Contribute to GrapheneOS/platform_packages_apps_GmsCompat development by creating an account on GitHub.

^GitHub

We host our own authoritative DNS servers to provide DNS resolution for our services. Authoritative DNS are the servers queried by DNS resolvers run by your ISP, VPN or an explicitly user chosen one such as Cloudflare or Quad9 DNS. We now have our own AS and IP space for this.

You can see information about our AS and IP space here:

bgp.tools/as/40806

We received a free ASN, IPv6 /40 and IPv4 /24 from ARIN. We use one IPv6 /48 for our ns1 anycast DNS network and one for our anycast ns2 network. We're using the IPv4 /24 for ns2 and need another.

Our ns1 network currently has 10 locations: New York City, Miami, Los Angeles, Seattle, London, Frankfurt, Singapore, Mumbai, Tokyo and Sydney. We're considering moving London to Amsterdam. We plan to add a South American location and perhaps Warsaw. ns2 isn't as scaled out yet.

Our ns2 network currently has New York City, Miami, Las Vegas and Bern.

Here's latency to ns1:

ping6.ping.pe/ns1.grapheneos.o…
ping.pe/ns1.grapheneos.org

Here's latency to ns2:

ping6.ping.pe/ns2.grapheneos.o…
ping.pe/ns2.grapheneos.org

We plan to add more locations to ns2 via another provider.

When we begin a reboot of a server, the change propagates across all internet backbone routers within a few seconds. This provides high availability for server downtime too. We have 2 networks so routing/transit issues or a malfunctioning server don't break using our services.

For ns1, there's a mix of different upstream transit providers. We've done traffic engineering with BGP communities configuration to get traffic routed to the right places. We prioritize Arelion and NTT since nearly all locations have both and we can configure their routing well.

We make the routes announced by our servers deprioritized when propagated into other continents for Arelion, Cogent and NTT. We deprioritize transit ruining global routing (GTT, Lumen) and block some peering (RETN, Bharti). We deprioritize Cogent since only 3 locations have it.

Our authoritative DNS server setup is largely in a public Git repository:

github.com/GrapheneOS/ns1.grap…

Here's our BGP communities setup ns1 New York City as an example:

github.com/GrapheneOS/ns1.grap…

Here's ns1 Miami with different handling for South America:

github.com/GrapheneOS/ns1.grap…

We have two main groups of servers around the world:

1) website and OS network services

github.com/GrapheneOS/ns1.grap…
github.com/GrapheneOS/ns1.grap…

2) update mirrors, which are currently 3x sponsored dedicated servers with 10Gbps

github.com/GrapheneOS/ns1.grap…

We'll have more of both soon.

We're in the process of our website and OS network services away from OVH due to the threats from French law enforcement. We're going to add nodes in South America, India, Japan and Australia as part of this. We also have 5 non-static-content servers in Canada to move off OVH.

The servers with more than static content are our discussion forum and attestation service for our users along with our email, Matrix and Mastodon servers for our project. These will move to colocated servers in Toronto long term but short term we'll just switch providers for it.

We're going to be moving the production second release of GrapheneOS based on Android 16 QPR1 to our Stable channel in the near future. Most significant confirmed regression is a crash in a new clock customization UI. It's solid and we don't seem to need a 3rd release first.

We're actively working on finishing support for the Pixel 10, Pixel 10 Pro, Pixel 10 Pro XL and Pixel 10 Pro Fold. It will likely be ready within a few weeks but we can't provide any specific timeline. It depends on which issues come up and how quickly we can get those resolved.