Realtime-Attack-Map
SURICATA / LIVE FEED

Kommt die Chatkontrolle jetzt über das Systemupdate?

Was das September-Update wirklich kann, was nicht - und warum Signal besser dasteht.

Kommt die Chatkontrolle jetzt über das Systemupdate?

Google verteilt mit dem September-Drop 2026 eine Betrugserkennung, die erstmals über die eigenen Apps hinausreicht und Chat-Benachrichtigungen fremder Messenger auswertet. Der Verdacht, hier werde die Chatkontrolle durch die Hintertür eingeführt, liegt nahe, greift technisch aber daneben - und trifft trotzdem einen wunden Punkt. Entscheidend ist die Frage, an welcher Stelle der Klartext einer verschlüsselten Nachricht das Sandbox-Gefängnis der App verlässt.

Inhaltsverzeichnis

    Was im September-Update tatsächlich ausgerollt wurde

    Im Changelog des September 2026 Pixel Drops steht ein unscheinbarer Punkt: „Betrugserkennung für Messaging-Apps - jetzt in mehr Ländern und Sprachen verfügbar." Dahinter stecken drei unterschiedliche Mechanismen, die gern vermischt werden.

    Der älteste läuft innerhalb von Google Messages und prüft SMS, MMS und RCS. Das ist unspektakulär, denn SMS sind ohnehin unverschlüsselt, und RCS-Nachrichten liegen in der App im Klartext vor. Diese Funktion wurde Anfang 2025 zunächst für englischsprachige Länder eingeführt.

    Der zweite Mechanismus ist die Notification Scam Detection. Sie markiert eingehende Chat-Benachrichtigungen mit einem Warnhinweis, bevor die Nachricht geöffnet wird. Bisher war sie auf die USA beschränkt, jetzt kommt sie laut den Verfügbarkeitsangaben zum Drop nach Australien, Kanada, Frankreich, Deutschland, Indien, Japan, Mexiko, Singapur und Großbritannien, neu unterstützt werden unter anderem Deutsch, Französisch, Spanisch, Portugiesisch, Arabisch und Japanisch. Vorausgesetzt wird ein Pixel 6 oder neuer.

    Der dritte Mechanismus ist neu und sitzt in der Tastatur. Gboard blendet in der Vorschlagsleiste einen Warnchip ein, sobald auf eine als verdächtig eingestufte Nachricht geantwortet wird, laut 9to5Google ausdrücklich „wherever you chat". Diese Variante läuft zunächst nur in den USA.

    Überraschend kommt das nicht. Bereits im September 2025 fanden sich in der Android System Intelligence für die Pixel-10-Reihe Einstellungen und eine App-Liste für genau diese Erweiterung, in der neben WhatsApp, Instagram und Line auch Signal auftauchte.

    Warum das Sandbox-Argument ins Leere läuft

    Die gängige Beruhigung lautet: Android isoliert Apps, also kann kein Systemdienst in eine Ende-zu-Ende-verschlüsselte App hineinsehen. Das stimmt, beantwortet aber die falsche Frage. Niemand muss in die Datenbank von Signal einbrechen, wenn die App den entschlüsselten Text freiwillig nach draußen reicht.

    Ein Vergleich aus dem Alltag: Ein Brief im Tresor ist sicher. Wird sein Inhalt aber auf eine Postkarte geschrieben und an die Wohnungstür geheftet, damit die Bewohner ihn im Vorbeigehen lesen können, nützt der beste Tresor nichts mehr. Die Benachrichtigung ist diese Postkarte.

    Der Weg über die Benachrichtigung

    Technisch läuft das über eine seit API-Level 18 dokumentierte Schnittstelle. Der NotificationListenerService liefert einer berechtigten App jede Benachrichtigung inklusive ihres Inhalts aus. Benötigt wird dafür die Berechtigung BIND_NOTIFICATION_LISTENER_SERVICE, die auf Nutzerseite unter „Benachrichtigungszugriff" verwaltet wird. Für eine vorinstallierte Systemkomponente wie die Android System Intelligence ist dieser Weg trivial.

    Der Ablauf ist damit klar umrissen:

    1. Signal empfängt ein verschlüsseltes Paket und entschlüsselt es im eigenen Prozess.
    2. Signal baut daraus eine Benachrichtigung mit Absendername und Nachrichtentext.
    3. Diese Benachrichtigung wird dem System übergeben und verlässt damit die Sandbox.
    4. Der registrierte Listener erhält den Klartext und übergibt ihn an ein lokales Modell.

    Die Verschlüsselung wird an keiner Stelle gebrochen. Sie endet schlicht dort, wo sie definitionsgemäß enden muss, nämlich am Endpunkt. Die Kontrolle darüber, was danach mit dem Klartext geschieht, liegt nicht mehr bei der Krypto, sondern bei der Plattform.

    Der Weg über die Tastatur

    Noch weiter reicht der Gboard-Ansatz. Eine Software-Tastatur ist eine Input Method Engine und sieht konstruktionsbedingt jeden Tastendruck, dazu den Kontext des Eingabefelds und damit auch die App, in der getippt wird. Eine Warnung „beim Antworten auf eine verdächtige Nachricht" setzt voraus, dass der Bezug zwischen Eingabe und vorangegangener Konversation hergestellt wird.

    Damit greift der zweite Mechanismus auf der Senderseite, während der erste auf der Empfängerseite ansetzt. Zusammen decken beide den kompletten Klartext einer Unterhaltung ab, ohne jemals einen einzigen Schlüssel zu benötigen. Der Ansatz ist damit älter als jede Client-Side-Scanning-Debatte und braucht keine kryptografische Hintertür.

    Was technisch nicht möglich ist

    Ebenso wichtig ist die Gegenseite, sonst entsteht ein falsches Bedrohungsbild.

    Nicht möglich ist der Zugriff auf die verschlüsselte Nachrichtendatenbank einer App. Das Verzeichnis unter /data/data/org.thoughtcrime.securesms/ bleibt anderen Prozessen verschlossen, solange der Bootloader gesperrt und kein Root aktiv ist. Ebenso wenig können Nachrichten gelesen werden, für die keine Benachrichtigung erzeugt wurde, etwa in stummgeschalteten Chats oder bei unterdrückter Vorschau. Archivierte Verläufe bleiben unsichtbar, ausgewertet wird immer nur der aktuell durchlaufende Text.

    Und, das ist der zentrale Punkt: Es gibt keine belastbaren Hinweise darauf, dass Treffer das Gerät verlassen. Google beschreibt die Verarbeitung als vollständig lokal in Echtzeit. Nachprüfen lässt sich das für Außenstehende nicht, weil weder die Android System Intelligence noch Gboard quelloffen sind. Wer also von Vertrauen spricht, meint hier tatsächlich Vertrauen und nicht Verifikation.

    Warum Signal besser dasteht als WhatsApp

    Beide Messenger nutzen dasselbe Signal-Protokoll, trotzdem ist die Angriffsfläche unterschiedlich groß. Der Unterschied liegt nicht in der Kryptografie, sondern in allem, was darum herum gebaut wurde.

    Eigenschaft Signal WhatsApp
    Quelloffener Client ja, prüfbar nein
    Benachrichtigung ohne Inhalt eigene Option, drei Stufen nur über Android-Systemeinstellung
    Bildschirmschutz gegen Screenshots und Übersichtsvorschau integriert nicht vorhanden
    Incognito-Flag für die Tastatur wird gesetzt wird nicht gesetzt
    Inhalt bei Meldung eines Kontakts keine Nachrichteninhalte bis zu fünf Nachrichten an den Betreiber
    Cloud-Backup keines vorgesehen Google Drive, E2EE optional
    Betrieb ohne Google Play Services möglich, per WebSocket nicht praktikabel

    Zwei Zeilen verdienen eine Erläuterung. Erstens die Meldefunktion: WhatsApp räumt in den eigenen Erläuterungen zur Ende-zu-Ende-Verschlüsselung begrenzte Ausnahmen ein, und bei einer Meldung werden bis zu fünf jüngste Nachrichten samt Metadaten an den Betreiber übertragen. Aus Sicht des Systems ist das ein legitimer Kanal für Klartext, der jederzeit vorhanden ist. Signals Spam-Meldung überträgt dagegen ein kryptografisches Token ohne Inhalt.

    Zweitens der Push-Pfad. Signal lässt sich vollständig ohne Google Play Services betreiben und hält dann eine eigene WebSocket-Verbindung. Wer diesen Weg konsequent geht, nutzt den gehärteten Fork Molly, der zusätzlich eine verschlüsselte lokale Datenbank und einen Sperrmechanismus im Ruhezustand mitbringt. Bei WhatsApp existiert diese Option nicht.

    Der Rest des Vergleichs sind Härtungsmöglichkeiten, die Signal anbietet und WhatsApp nicht. Genau diese entscheiden darüber, ob die Postkarte an der Tür hängt oder eben nicht. Eine ausführlichere Gegenüberstellung beider Messenger findet sich im Beitrag Signal vs. WhatsApp.

    Die Indizien, die den Verdacht nähren

    Dass viele Leser bei dieser Meldung zusammenzucken, ist nachvollziehbar. Fünf Beobachtungen tragen dazu bei.

    Erstens ist die Funktion standardmäßig aktiv und wurde über ein Feature-Update verteilt, nicht über eine Einrichtungsabfrage. Zweitens reicht sie erstmals über Googles eigene Apps hinaus in fremde, verschlüsselte Anwendungen. Drittens war die App-Liste im Teardown fest verdrahtet, die Auswahl der überwachten Messenger trifft also Google, nicht der Nutzer. Viertens läuft die Erkennung auf einem Sprachmodell, dessen Klassifikationsziele sich durch ein Modell-Update ändern lassen, ohne dass sich an der Architektur etwas ändert. Und fünftens fällt der Rollout nach Deutschland ausgerechnet in eine Phase, in der auf EU-Ebene über die CSA-Verordnung verhandelt wird.

    Der letzte Punkt ist Zufall der Kalender, der vierte ist es nicht. Was hier entsteht, ist eine erprobte, geräteweite Inhaltsanalyse über App-Grenzen hinweg. Bisher galt das Fehlen genau dieser Infrastruktur als praktisches Gegenargument gegen Client-Side Scanning. Dieses Argument ist ab sofort verbraucht.

    Was die Chatkontrolle davon unterscheidet

    Trotzdem ist die Antwort auf die Titelfrage ein Nein. Vier Merkmale trennen beides sauber.

    Angeordnet wird die Betrugserkennung vom Hersteller, nicht vom Gesetzgeber, und sie ist abschaltbar. Erkannt werden sollen Social-Engineering-Muster, nicht Missbrauchsmaterial. Das Ergebnis ist eine Warnung an den Nutzer, keine Meldung an eine Behörde. Und ein Treffer löst keinen Upload aus.

    Zum Stand der eigentlichen Regulierung: Der Rat hat im November 2025 eine Position ohne verpflichtende Aufdeckungsanordnungen beschlossen, seither läuft der Trilog über die dauerhafte Verordnung, und die befristete Übergangsregelung für freiwilliges Scannen unverschlüsselter Inhalte wurde im Juli 2026 bis 2028 verlängert. Eine gesetzliche Pflicht zum Scannen verschlüsselter Nachrichten besteht damit nicht.

    Der Unterschied zwischen beidem liegt also im Zweck und im Meldeweg, nicht in der Technik. Ein Klassifikator, der den Enkeltrick erkennt, unterscheidet sich architektonisch nicht von einem, der etwas anderes sucht. Ausgetauscht werden müssten das Modell und das Ziel des Alarms.

    Konkrete Härtung des Geräts

    Die Maßnahmen bauen aufeinander auf und sind nach Wirkung sortiert.

    Benachrichtigungsinhalte unterdrücken. In Signal unter Einstellungen, Benachrichtigungen, Anzeigen die Option „Weder Name noch Nachricht" wählen. Damit enthält die Benachrichtigung keinen auswertbaren Text mehr, und der Listener erhält nichts als eine leere Hülle. Das ist die wirksamste Einzelmaßnahme und kostet nur einen zusätzlichen Blick in die App.

    Scam Detection deaktivieren. Der Schalter liegt unter Einstellungen, Sicherheit und Datenschutz, Mehr Sicherheit und Datenschutz, Scam Detection. Auf Geräten mit angepassten Oberflächen kann der Pfad abweichen.

    Gboard ersetzen. Eine Tastatur ohne Netzwerkberechtigung schließt den zweiten Kanal vollständig. Bewährt hat sich HeliBoard, das ohne Internetzugriff auskommt. Signals Bildschirmschutz sollte parallel aktiv bleiben, er unterdrückt Screenshots und die Vorschau in der App-Übersicht.

    Messenger wechseln oder härten. Wer bei Signal bleibt, gewinnt mit Molly zusätzliche Absicherung. Wer die Plattform selbst aus der Gleichung nehmen will, landet bei GrapheneOS: Dort ist die Android System Intelligence nicht vorhanden, auch nicht über Sandboxed Google Play, und Gboard wird nicht mitgeliefert. Die hier beschriebenen Mechanismen existieren auf einem solchen Gerät schlicht nicht.

    Prüfen, was auf dem Gerät aktiv ist

    Statt sich auf Menüpfade zu verlassen, lässt sich der Zustand per ADB direkt auslesen. Die Einrichtung des drahtlosen Zugriffs ist im Beitrag zu den ADB-WiFi-Kommandos beschrieben.

    #!/usr/bin/env bash
    # Scam-Detection-Status auf einem Android-Gerät prüfen - M. Meister
    
    echo "== Registrierte Notification Listener =="
    # Liefert alle Komponenten, die Benachrichtigungsinhalte im Klartext erhalten
    adb shell settings get secure enabled_notification_listeners | tr ':' '\n'
    
    echo
    echo "== Relevante Systempakete =="
    # com.google.android.as      = Android System Intelligence (On-Device-Modelle)
    # com.google.android.as.oss  = Private Compute Services (Modell-Updates)
    # ...inputmethod.latin       = Gboard
    for pkg in com.google.android.as com.google.android.as.oss \
               com.google.android.inputmethod.latin; do
        if adb shell pm list packages | grep -q "$pkg"; then
            state=$(adb shell dumpsys package "$pkg" | grep -m1 -i "enabled=" || echo "unbekannt")
            printf '%-45s vorhanden (%s)\n' "$pkg" "$state"
        else
            printf '%-45s nicht vorhanden\n' "$pkg"
        fi
    done
    
    echo
    echo "== Aktive Eingabemethode =="
    adb shell settings get secure default_input_method
    

    Auf einem Pixel mit Stock-Android taucht in der ersten Liste eine Komponente aus dem Paket com.google.android.as auf. Auf einem GrapheneOS-Gerät bleibt die Ausgabe bei allen drei Paketen leer. Wer die Systemintelligenz vollständig stilllegen will, kann sie mit adb shell pm disable-user --user 0 com.google.android.as deaktivieren, verliert damit allerdings auch Funktionen wie Now Playing, Smart Reply und Teile der Live-Untertitel. Ein Test auf einem Zweitgerät ist vorher empfehlenswert.

    Fazit

    Die neue Betrugserkennung liest keine verschlüsselten Datenbanken aus, sondern greift den Klartext dort ab, wo Messenger ihn ohnehin an das System übergeben, nämlich in der Benachrichtigung und in der Tastatur. Rechtlich hat das mit der Chatkontrolle nichts zu tun, architektonisch entsteht damit aber genau die geräteweite Inhaltsanalyse, deren Fehlen bislang als stärkstes Gegenargument gegen Client-Side Scanning galt. Wer Benachrichtigungsinhalte unterdrückt, die Tastatur austauscht und im Zweifel ein Betriebssystem ohne Android System Intelligence nutzt, entzieht beiden Wegen die Grundlage.