Reverse Engineering von Typeless zeigt gravierende Datenschutzrisiken: So wird auch klar, wie viele Daten eine gute Spracheingabe wirklich frisst

【Hinweis】Nach einer Reverse-Engineering-Analyse der Sprachinput-App „Typeless“ wurden recht schwerwiegende Datenschutzrisiken festgestellt. Ich teile das hiermit.

■ Fazit vorab

Typeless behauptet „On-device history“ und „Zero data retention“, aber tatsächlich werden sämtliche Audiodaten zur Verarbeitung an AWS-Server (USA, Ohio) gesendet. Lokal existiert überhaupt kein Spracherkennungsmodell.

Wenn es nur das wäre, wäre es lediglich ein gewöhnlicher „Cloud-STT-Service“. Das Problem ist, dass der Umfang der gesammelten Nicht-Audio-Daten sehr groß ist.

■ Welche Analysen wurden durchgeführt

Unter macOS wurden an Typeless v0.9.3 eine Binäranalyse, eine Analyse der Netzwerkkommunikation, eine lokale DB-Analyse sowie eine String-Analyse nativer Libraries durchgeführt.

■ Bestätigte Fakten

  1. Audioverarbeitung zu 100% in der Cloud
    In der App gibt es kein STT-Modell wie Whisper. Das Audio wird nach der Komprimierung zu Opus in Echtzeit über WebSocket (wss://api.typeless.com/ws/rt_voice_flow) an einen AWS-us-east-2-Server gesendet.

http://api.typeless.comhttp://prod-typeless-lb-565501648.us-east-2.elb.amazonaws.com

In der offiziellen Datenschutzrichtlinie steht ebenfalls „processed in real time on our cloud servers“, daher ist es nicht vollständig erfunden, aber die Marketingaussage „On-device“ beschränkt sich nur auf „Verlauf wird lokal gespeichert“ und ist sehr leicht irreführend.

  1. Neben Audio werden auch umfangreiche Daten gesammelt
    Über die lokale SQLite-Datenbank und die Analyse nativer Libraries wurde bestätigt, dass folgende Daten gesammelt werden:

・ Vollständige URL der gerade besuchten Website (auch Gmail, Google Docs usw. werden protokolliert)
・ Name der aktuell fokussierten App, Fenstertitel
・ Text auf dem Bildschirm (über eine per Bedienungshilfen-API rekursiv sammelnde Funktion collectVisibleTexts)
・ Lesen/Schreiben der Zwischenablage (kann TransientType von Passwort-Managern verarbeiten)
・ Systemweites Mithören von Tastatureingaben über CGEventTap
・ Browser-DOM-Elementinformationen (unterstützt Safari, Chrome, Edge, Firefox, Brave)
・ Vom Nutzer bearbeitete Textinhalte (TrackEditTextService → sendTrackResultToServer)

  1. Lokale DB speichert personenbezogene Daten im Klartext
    In typeless.db werden Spracherkennungs-Ergebnistext, Browser-URLs und App-Informationen im Klartext gespeichert. Obwohl „Zero data retention“ behauptet wird, bleibt lokal alles erhalten. Audiodateien (.ogg) werden ebenfalls nicht gelöscht, sondern bleiben zurück.

  2. Überzogene Berechtigungsanforderungen
    Als Sprachinput-Tool verlangt es neben dem Mikrofon auch Bildschirmaufzeichnung, Kamera, Bluetooth und Bedienungshilfen-Berechtigungen und hat zudem eine eingebaute Screenshot-Funktion.

  3. Transparenz des Unternehmens nahezu gleich null
    ・ In AGB und Datenschutzrichtlinie ist kein Rechtsträger (juristische Person) angegeben
    ・ Als Standort steht nur „County of San Francisco, California“ (Gerichtsstand in den AGB)
    ・ WHOIS ist verborgen (GoDaddy + Cloudflare)
    ・ Keine Informationen zu Sicherheits-Audits wie SOC2, ISO27001 usw.
    ・ Kontaktmöglichkeit nur hello@typeless.com

■ Technische Nachweise (reproduzierbar)

Mit den folgenden Befehlen kann man das selbst verifizieren:

# Netzwerk-Kommunikationsziel
nslookup http://api.typeless.com

# API-URL in app.asar
strings /Applications/Typeless.app/Contents/Resources/app.asar | grep "http://api.typeless.com"

# WebSocket-Kommunikationsprotokoll
strings /Applications/Typeless.app/Contents/Resources/app.asar | grep "rt_voice_flow"

# Native Library für Keyboard-Listening
strings /Applications/Typeless.app/Contents/Resources/lib/keyboard-helper/build/libKeyboardHelper.dylib | grep -i "key pressed"

# Sammeln von Bildschirmtext
strings /Applications/Typeless.app/Contents/Resources/lib/context-helper/build/libContextHelper.dylib | grep -i "collectVisibleTexts"

# Inhalt der lokalen DB
sqlite3 ~/Library/Application\ Support/Typeless/typeless.db ".schema history"

■ Wo liegt das Problem

CGEventTap (Keyboard-Listening) + Bedienungshilfen-API (Sammeln von Bildschirmtext) + Zwischenablagezugriff. Diese Kombination hat technisch die gleiche Fähigkeit wie ein Keylogger.

Und du gibst diese Berechtigungen einem Dienst, dessen Betreiberstruktur unklar ist.

Um die Genauigkeit der Spracheingabe zu verbessern, ist das Erfassen von Kontext (Infos zur aktuellen App/Eingabefeld) an sich ein sinnvolles Design. Wenn diese Daten jedoch in die Cloud gesendet werden, sind Vertrauenswürdigkeit des Betreibers und Sicherheitsstruktur entscheidend. Ob man einem Unternehmen vertraut, das nicht einmal seinen Rechtsträger offenlegt, muss jeder selbst beurteilen.

■ Alternativen

Es gibt Sprachinput-Tools, die vollständig lokal laufen:

・ Whisper.cpp / MLX Whisper (Open Source, vollständig lokal, kostenlos)
・ macOS-eigene Spracheingabe (auf Apple Silicon erfolgt Verarbeitung on-device)
・ Superwhisper (basiert auf Whisper, für Mac – muss aber weiterhin selbst verifiziert werden)

■ Zusammenfassung

・ Typeless’ Spracherkennung wird zu 100% in der Cloud verarbeitet (kein lokales Modell)
・ Neben Audio besteht die technische Grundlage zum Sammeln von Bildschirmtext, URLs und Tastatureingaben
・ Betreiber ist intransparent (Rechtsträger und Standort nicht offengelegt)
・ Keine Nachweise zu Sicherheits-Audits

Wer es nutzt, sollte nach Kenntnis der Risiken selbst entscheiden. Mindestens wird empfohlen, die Netzwerkkommunikation mit Tools wie Little Snitch zu überwachen.

Das erinnert die betreffenden Entwickler auch daran, in welche Richtung sie sich anstrengen sollten.

Wer die Zwischenablage-Historie nutzt, ist einfach besser dran als jemand, der sie nicht nutzt.