device-activity-tracker: ein PoC, um zu erkennen, ob ein Telefon aktiv, im Ruhezustand oder offline ist, über WhatsApp und Signal

Ein Proof of Concept (PoC), der in TypeScript den akademischen „Careless Whisper”-Angriff (Gegenhuber et al., RAID 2025, Best Paper) implementiert: Er misst die Umlaufzeit (RTT) der Zustellbestätigungen von WhatsApp und Signal, um allein anhand einer Telefonnummer abzuleiten, wann ein Gerät genutzt wird, im Ruhezustand ist oder offline ist. Stand 1. September 2026 hat das Projekt 5.107 Sterne.

Was device-activity-tracker ist

device-activity-tracker ist ein quelloffenes (MIT) Tool, das die Forschung des Papers „Careless Whisper: Exploiting Silent Delivery Receipts to Monitor Users on Mobile Instant Messengers” von Gabriel K. Gegenhuber, Maximilian Günther, Markus Maier, Aljosha Judmayer, Florian Holzbauer, Philipp É. Frenzel und Johanna Ullrich (Universität Wien und SBA Research) implementiert. Das README selbst rahmt es mit einem Hinweis: „Proof-of-concept for educational and security research purposes only. Demonstrates privacy vulnerabilities in WhatsApp and Signal.”

Es ist weder ein Messaging-Dienst noch eine kommerzielle App — es ist ein Sicherheits-PoC, der eine reale Datenschutzschwachstelle demonstriert. Es sendet Probes (Sondierungsnachrichten) an eine Zielnummer und misst den RTT (die Zeit zwischen dem Senden des Probes und dem CLIENT ACK der Plattform), um den Zustand des Geräts zu klassifizieren:

🟢 Online — RTT unter dem Schwellenwert: Das Gerät wird aktiv genutzt.
🟡 Standby — RTT über dem Schwellenwert: Das Gerät ist im Ruhezustand/gesperrt.
🔴 Offline — kein CLIENT ACK empfangen: Das Gerät ist getrennt oder nicht erreichbar.

Laut README kann es zudem Aktivitätsmuster über die Zeit ableiten und, weniger zuverlässig, mögliche Netzwerkwechsel (mobile Daten gegenüber Wi-Fi). Das Projekt unterstützt WhatsApp und Signal, mit einer Weboberfläche (React) und einem CLI-Modus (nur WhatsApp).

Der Ursprung: ein PoC auf Basis eines mit dem RAID-2025-Preis ausgezeichneten Papers

Das Repository wurde am 7. Dezember 2025 von Gommzy erstellt (GitHub-Konto gommzystudio, 2020 erstellt, 196 Follower, 27 öffentliche Repositorys, ohne Firmen- oder Bio-Angabe im Profil), der letzte Push stammt vom 31. Dezember 2025. Der Standard-Branch ist master.

Die Autorität des Projekts kommt nicht von einem Unternehmen, sondern vom akademischen Paper, das es implementiert. Laut der arXiv-Seite (2411.11194, v1 am 17. November 2024 und v4 am 31. Oktober 2025) wurde die Arbeit auf dem 28. International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2025) vorgestellt und war „Distinguished with the Best Paper Award” (mit dem Best-Paper-Award ausgezeichnet). Die Zusammenfassung des Papers argumentiert, dass Instant-Messaging-Apps (über 3 Milliarden Nutzer) es durch speziell gestaltete Nachrichten erlauben, Delivery Receipts auszulösen, um jeden Nutzer ohne dessen Wissen oder Zustimmung zu „pingen”; bei hoher Frequenz kann ein Angreifer so private Informationen wie den Online-/Aktivitätsstatus (Bildschirm an/aus) extrahieren, die Anzahl aktiver Geräte und deren Betriebssystem ableiten und Angriffe zur Ressourcenerschöpfung (Akku oder Daten) starten, ohne dass auf dem Ziel eine Benachrichtigung entsteht.

Das relevante narrative Detail ist die Spannung zwischen dem Tool und den Apps: Der Hacker-News-Thread über das Paper selbst (20 Punkte, 4 Kommentare) zeigt die Reaktion darauf, dass „die Stiftung” (Signal Foundation) nicht auf den Befund reagiert hatte (siehe „Community-Resonanz”). Dieser PoC ist die ausführbare Übersetzung dieser Forschung.

Philosophie und Prinzipien

Die verifizierbaren Ideen, die sich durch README, CONTRIBUTING.md und die LICENSE ziehen:

Eine reale Schwachstelle demonstrieren, kein Produkt bauen. Das README und die Lizenz (MIT mit zusätzlichen Disclaimern) betonen, dass das Ziel „educational and security research purposes only” ist, und warnen, dass „this tool demonstrates real security vulnerabilities that affect millions of users”.
Auf peer-reviewter Arbeit aufbauen. Statt eines erfundenen Angriffs basiert die Implementierung auf einem Paper mit Best Paper Award (RAID 2025), was die Methode in verifizierbarer, zitierfähiger Literatur verankert (das README enthält die BibTeX-Zitation).
Passive, stille Messung. Der Mechanismus stützt sich auf Delivery Receipts, die der Empfänger nie bemerkt („silent delivery receipts”); der Wert der Demo liegt darin, einen Side-Channel (RTT) zu extrahieren, der keine Benachrichtigung auf dem Zielgerät hinterlässt.
Transparenz über Abhilfemaßnahmen und ethische Grenzen. Das README widmet einen Abschnitt „How to Protect Yourself”, stellt klar, dass das Deaktivieren von Lesebestätigungen nicht gegen diesen konkreten Angriff schützt, und dass die Schwachstelle Stand Dezember 2025 in WhatsApp und Signal weiterhin ausnutzbar war; zudem wird darum gebeten, Personen nicht ohne Zustimmung zu verfolgen („this may violate privacy laws”).

Wie es funktioniert

Der im README, in src/, package.json und docker-compose.yml dokumentierte technische Ablauf:

Authentifizierung: Bei WhatsApp wird ein QR-Code mit der App gescannt (über die Bibliothek @whiskeysockets/baileys); bei Signal wird der Dienst signal-cli-rest-api im json-rpc-Modus genutzt, verbunden über WebSocket, um die Receipts zu empfangen.
Senden von Probes: Der Tracker sendet Sonden an die Zielnummer. Zwei Methoden:
- Delete (Standard): sendet eine „delete”-Anfrage für eine nicht existierende Nachrichten-ID.
- Reaction: sendet ein Reaktions-Emoji an eine nicht existierende Nachrichten-ID.
- Bei Signal sind die Methoden reaction und message (laut src/signal-tracker.ts).
RTT-Messung: Die Zeit zwischen dem Senden des Probes und dem Empfang des CLIENT ACK (Status 3) wird als RTT gemessen.
Klassifizierung nach dynamischem Schwellenwert: Ein Schwellenwert wird als 90 % des RTT-Medians berechnet; Werte darunter deuten auf aktive Nutzung hin, darüber auf Ruhezustand. Messungen werden in einer Historie gespeichert, und der Median wird kontinuierlich aktualisiert, um sich an unterschiedliche Netzwerkbedingungen anzupassen.
Schnittstelle: Die Web-Oberfläche (React + Tailwind + Recharts) zeigt Echtzeitmessungen, Zustands- und Musteruntersuchung, mit einem Dropdown zum Wechseln der Probe-Methode; der CLI-Modus (nur WhatsApp) gibt ein Panel mit JID, Status, RTT, Durchschnitt (3), Median und Schwellenwert aus.

Verifizierter Stack laut package.json: Backend in TypeScript 5 + Express 5 + socket.io + pino (Logging) + ws; WhatsApp über @whiskeysockets/baileys (^7.0.0-rc.9); Signal über den Dienst bbernhard/signal-cli-rest-api; Frontend in React 18 mit Tailwind CSS; verpackt mit Docker Compose (drei Dienste: backend, client und signal-api). Von der API gemeldete Sprachen: TypeScript (105.143 Bytes), HTML (1.721), Dockerfile (1.529), CSS (1.043) und JavaScript (246).

Projektstruktur (laut README):

device-activity-tracker/
├── src/
│   ├── tracker.ts         # WhatsApp-RTT-Logik
│   ├── signal-tracker.ts  # Signal-RTT-Logik
│   ├── server.ts          # API-Server (beide Plattformen)
│   └── index.ts           # CLI-Oberfläche
├── client/                # React-Weboberfläche
└── package.json

Offizieller und halboffizieller Status

Kein Marktplatz-Eintrag oder Produkt: Es ist ein selbst gehosteter PoC ohne veröffentlichtes Paket in einem Register (package.json erklärt private: true, es gibt also keine npm-/PyPI-/crates.io-/Docker-Hub-Version des Projekts selbst).
Sein „Gütesiegel” ist akademisch, nicht kommerziell: Die Glaubwürdigkeit kommt vom zugrunde liegenden Paper — einer Arbeit mit Best Paper Award bei RAID 2025 —, die diese Implementierung ausführt. In der Praxis macht das dieses Repository zu einer Community-Referenz für den „Careless Whisper”-Angriff, auch wenn es keinen Beleg dafür gibt, dass WhatsApp oder Signal es offiziell anerkennen oder ein Anbieter es „zertifiziert”.
Keine formale Bezeichnung durch die Plattformen: Das README erklärt, dass die Schwachstelle Stand Dezember 2025 „remains exploitable in WhatsApp and Signal”; es gibt in den konsultierten Quellen keine Spur eines öffentlichen Patches oder einer offiziellen Erklärung der Unternehmen.
Ethischer/halboffizieller Rahmen: Die MIT-Lizenz fügt Disclaimer hinzu, die die Autoren von Missbrauch freistellen, verantwortungsvolle Offenlegung von Schwachstellen empfehlen und von nicht autorisierter Spionage abraten. Das ist kein Status, prägt aber, wie das Projekt gelesen werden sollte.

Das Ökosystem

Ökosystem-Abhängigkeiten, auf denen es aufbaut

Repository	Sterne (GitHub-API, 1. Sep 2026)	Funktion
`WhiskeySockets/Baileys`	10.950 (3.347 Forks)	„Socket-based TS/JavaScript API for WhatsApp Web”; die Grundlage, über die der PoC ohne die offizielle App mit WhatsApp spricht.
`bbernhard/signal-cli-rest-api`	2.821	„Dockerized Signal Messenger REST API”; der Dienst, den der PoC nutzt, um Sonden an Signal zu senden und Receipts zu empfangen.

Unabhängige Nachbildungen des „Careless Whisper”-Angriffs

Eine GitHub-Repository-Suche ergab mehrere fremde PoCs, die denselben Angriff nachbilden (die nächsten echten „Konkurrenten”). Sternezahlen wie in diesem Durchlauf abgerufen:

Repository	Sterne	Verifizierbarer Unterschied
`ctrlsam/careless-whisper-python`	17	„Monitoring users via Silent Delivery Receipts Exploit (WhatsApp and Signal)” in Python.
`Ti-03/Careless-Whisper`	14	„real-time surveillance tool leverages WhatsApp RTT” — Fokus auf Echtzeitüberwachung.
`190-785/WhatsApp-Careless-Whisper`	6	„Go-based RTT probe tool for WhatsApp, replicating the Careless Whisper”.
`milouk/whatsapp-tracker`	6	„Whatsapp side-channel attack and monitoring tool based on the Careless [Whisper]”.
`xalaetrx/Whatsapp-Tracker`	4	„research POC for WhatsApp OS fingerprinting and presence monitoring” — fügt OS-Fingerprinting hinzu.
`moltrus/careless-whisper`	0	„PoC to track any WhatsApp phone number based on delivery receipts + [RTT]”.
`Ionete-Andrei/careless-whisper-survey`	0	„A technical survey of the Careless Whisper attack (Gegenhuber et al.)” — eine technische Übersicht, kein PoC.
`tr4m0ryp/wa-activity-collector`	0	„WhatsApp RTT side-channel tracker (Careless Whisper / RAID 2025)” mit Logging.

Forks des Repositorys selbst

Die API listete insgesamt 699 Forks, die meisten ohne Sterne. Die wenigen mit registrierten Sternen: guberm/device-activity-tracker (8), mwakidenis/device-activity-tracker (5), imanbarati/device-activity-tracker (1), HiS515HAM/device-activity-tracker (1) und mikebodojr/device-activity-tracker (1). Es wurde keine nicht-englische Übersetzung unter den Forks festgestellt; in der Issue-Historie erscheint jedoch ein PR (#48, „Translation pipeline for internationalization of the repo”, geschlossen), der versuchte, Internationalisierung hinzuzufügen.

Andere Projekte des Autors

Das Konto gommzystudio hat 27 öffentliche Repositorys, aber keines davon steht direkt mit Messaging-Sicherheit in Verbindung (hervorzuheben sind AldiTalk-True-Unlimited mit 55 Sternen und BambuStudio mit 2). Der Autor ist demnach ein Generalist unter den Entwicklern; dieser PoC ist mit Abstand sein sichtbarstes Projekt.

Diese Zahlen stammen von der GitHub-API und aus Repository-Suchen während dieser Recherche; sie sind kein Audit der Qualität, des Supports oder der Kompatibilität jedes Derivats.

Repo-Kennzahlen

Messung: 1. September 2026, GitHub-API.

Kennzahl	Wert
Sterne	5.107
Forks	699
Abonnenten	64
Offene Issues laut API	33
Hauptsprache	TypeScript
Lizenz	MIT (mit zusätzlichen Disclaimern)
Erstellt	7. Dezember 2025
Letzter Push	31. Dezember 2025
Letzte Metadaten-Aktualisierung	1. September 2026
Releases	Keine veröffentlicht (leerer Endpunkt)
Repo-Größe	374 KB

Top-Contributor laut API, nach Anzahl der Beiträge: gommzystudio (37), robcerda (2) und mehrere mit 1 (AjayAntoIsDev, verynewusername, JathinYadav, onem0). Die Aktivität ist stark auf den Autor konzentriert.

API-Vorbehalte: open_issues_count (33) schließt offene Pull Requests ein, sollte also nicht als reiner Issue-Zähler gelesen werden. Das Feld watchers_count der allgemeinen Antwort spiegelt die Sternezahl wider (5.107); daher wird subscribers_count (64) separat als echte Abonnenten angegeben. Es wurden keine Releases veröffentlicht, die Version wird also im Code verwaltet (1.0.0 in package.json) und nicht über Tags.

Wie man beiträgt

CONTRIBUTING.md dokumentiert einen Standardablauf:

Das Repository forken und klonen.
Einen Branch erstellen: git checkout -b feature/my-change.
Abhängigkeiten installieren: npm install (und cd client && npm install && cd ..).
Die Änderungen vornehmen.
Einen Pull Request mit kurzer Beschreibung und Begründung eröffnen.

Dokumentierte Richtlinien: PRs klein und fokussiert halten, TypeScript bevorzugen und dem bestehenden Stil folgen, keine Authentifizierungs-/Sitzungsdaten oder Geheimnisse committen, und die ethischen/rechtlichen Hinweise des READMEs respektieren (nur Forschung und Bildung). Es wurde kein spezifisches Test-/Evaluierungs-Framework gefunden; die Issue-Historie zeigt Community-PRs, die diesem Ablauf folgen (zum Beispiel #88 „fix: WhatsApp QR code not loading in web UI”, #66/#61 „Fix Recharts Tooltip labelFormatter TypeScript error”, #49 „feat: Implement Smart Adaptive Prediction using K-Means”, #53 „Refactor/separate frontend from backend”, #56 „Add api port env var”).

Community-Resonanz

Das Repository hat wenig Zugkraft auf Hacker News für sich genommen, aber das Paper, das es implementiert, erzeugte durchaus Debatte. Verifizierbare Einreichungen:

Zum Paper (arXiv 2411.11194):

46085197 „Exploiting silent delivery receipts to monitor users on instant messengers” — 20 Punkte, 4 Kommentare (29. November 2025). Konkrete Kommentare:
- rzl: „This has been making the rounds in privacy-focused forums and whatnot and still no comment from the foundation. That doesn’t inspire a lot of confidence in the Signal Foundation. If nothing else, I would expect that sending delivery receipts to invalid messages be considered a bug to fix…”
- Stefan-H (Antwort auf rzl): „An attacker with a privileged position on the network allowing them to eavesdrop (but not decrypt) traffic could use a bug like this to identify the device on the network associated with a phone number in Signal. Given nation state level adversaries, that seems like a significant privacy issue to me”.
- 8cvor6j844qw_d6 verlinkte eine verwandte Lektüre über FBI-Taktiken (Press Herald).
Weitere Einreichungen des Papers mit wenig Zugkraft: 46034272 (5 Punkte, 0 Kommentare), 46466372 (3 Punkte, 0 Kommentare).

Zum Repository selbst (alle mit 0 Kommentaren):

46220607 „Device Activity Tracker: WhatsApp Activity Tracker via RTT Analysis” — 1 Punkt (10. Dezember 2025).
46422304 „Exploiting Silent Delivery Receipts to Monitor Users on WhatsApp/Signal” — 1 Punkt (29. Dezember 2025).
46443724 „Exploiting Silent Delivery Receipts to Monitor Users on Instant Messengers” — 3 Punkte (31. Dezember 2025).

Wiederkehrende Issues (GitHub): Der Issue-Thread zeigt eine konkrete, messbare Beschwerde, die sich wiederholt:

Der WhatsApp-QR erscheint nicht, der von Signal jedoch schon: #52 „Signal QR code is working, but WhatsApp’s doesn’t”, #74 „Follow up (WA not working)” („signal works and i successfully connected… but qr code for whatsup doesn’t show up… In CLI version it just says qr:undefined”), #67 „QR code is not generating anymore for whatsapp since last 4 hours” und #64 „Verification Failed”.
Build-Fehler beim Client: #68 „Client Build Failed both through docker and npm” mit dem Fehler TS2322: Type '(t: number) => string' is not assignable… (ein Typisierungsproblem des Recharts-Tooltips, ebenfalls behandelt in #69 und den PRs #66/#61).
Signal-QR nicht sichtbar: #54 „Signal QR Code Not Showing On port 3000” (der Nutzer kopiert .env.sample nach .env, startet docker compose up -d/--build, ruft localhost:3000 auf, aber der Signal-QR wird nicht angezeigt und localhost:8080 liefert 404).
Mehrere Issues ohne nützlichen Inhalt (z. B. #79 „Fff”, #62 und #60 mit nur Telefonnummern) und einige mit klarem Spam-/Rauschcharakter (PR #85 „Rename README.md to 0812-9328-1098”, PR #79/#87/#86 „Create SECURITY.md”).

Video (YouTube-Suche, 1. September 2026): Es wurden Titel gefunden, die klar mit dem Thema verbunden sind; sie werden ohne Aufrufe-/Kanalzahlen aufgeführt, da diese nicht zuverlässig erfasst werden konnten: „Explorando Vulnerabilidades de Privacidade no WhatsApp: Device Activity Tracker na prática” (Portugiesisch, explizit über dieses Repo) und „Track Anyone On WhatsApp | WhatsApp Tracker | Real Time Tracing” (generischer Titel, nicht bestätigt als zu genau diesem Repo gehörend). Der Rest der Suchergebnisse waren kommerzielle „WhatsApp-Tracking”-Apps ohne Bezug zu diesem Projekt.

Es wurden keine verifizierbaren Belege auf Reddit gefunden (die Seite lieferte nicht parsbaren Inhalt), auf X/Twitter (blockiert) oder Product Hunt; daher werden keine Kennzahlen von diesen Plattformen behauptet.

device-activity-tracker im Vergleich zu anderen Vorschlägen

Projekt	Sterne (GitHub-API, 1. Sep 2026)	Verifizierbarer Unterschied
`ctrlsam/careless-whisper-python` (17)	Nachbildung desselben Angriffs.	In Python geschrieben; dieser PoC ist TypeScript mit React-Web-UI + CLI und unterstützt Signal nativ.
`Ti-03/Careless-Whisper` (14)	Ein weiterer PoC desselben Angriffs.	Als „Echtzeit-Überwachungstool” gerahmt; anderer Stack, keine Web-Schicht wie diese hier.
`190-785/WhatsApp-Careless-Whisper` (6)	RTT-Probe für WhatsApp.	In Go geschrieben und auf WhatsApp beschränkt; dieses unterstützt auch Signal.
`milouk/whatsapp-tracker` (6)	„Side-channel attack and monitoring tool based on Careless Whisper”.	WhatsApp-fokussiert; anderer Stack.
`xalaetrx/Whatsapp-Tracker` (4)	PoC für OS-Fingerprinting und Präsenz.	Fügt OS-Fingerprinting als explizites Ziel hinzu; das README dieses Repos erwähnt es nur als mögliche Ableitung.
`Ionete-Andrei/careless-whisper-survey` (0)	Kein PoC.	Es ist eine technische Übersicht des Angriffs; nützlich als Hintergrundreferenz, nicht als Tool.

Der nützlichste Vergleich betrifft nicht die Popularität: Dieses Repo sticht hervor, weil es beide Plattformen (WhatsApp und Signal) in einer einzigen Web-App + CLI über die beiden ausgereiften Abhängigkeiten des Ökosystems kombiniert (Baileys und signal-cli-rest-api). Fremde PoCs beschränken sich meist auf WhatsApp oder eine einzelne Sprache. Sein praktischer Nachteil ist die operative Unreife (die Issues zum WhatsApp-QR und zum Client-Build wiederholen sich) und das Fehlen formaler Releases/Versionierung.

Schnellstart-Anleitung

Hinweis: Das README und die Lizenz erklären dies strikt für Forschung und Bildung. Es zur Verfolgung von Personen ohne Zustimmung zu nutzen, kann Datenschutz-, Abhör- und Computerbetrugsgesetze verletzen.

Installation und erster Start

Voraussetzungen: Node.js 20+, npm und ein WhatsApp-Konto (und für Signal der Dienst signal-cli-rest-api, bereits in docker-compose.yml enthalten).

git clone https://github.com/gommzystudio/device-activity-tracker.git
cd device-activity-tracker
npm install
cd client && npm install && cd ..

Docker-Option (vom README empfohlen):

cp .env.example .env
docker compose up --build

Nach dem Start ist die App verfügbar unter:

Frontend: http://localhost:3000 (oder dem konfigurierten CLIENT_PORT).
Backend: http://localhost:3001 (oder BACKEND_PORT).

Zum Stoppen: docker compose down.

Manuelles Setup (ohne Docker):

# Terminal 1: Backend
npm run start:server
# Terminal 2: Frontend
npm run start:client

http://localhost:3000 öffnen, den QR-Code mit WhatsApp scannen und dann die zu verfolgende Nummer eingeben (z. B. 491701234567).

CLI (nur WhatsApp):

npm start

Den Anweisungen folgen, um sich zu authentifizieren und die Zielnummer einzugeben. Das Ergebnis wird im Terminal als Panel mit JID, Status, RTT, Durchschnitt (3), Median und Schwellenwert ausgegeben (das README zeigt ein Beispiel mit Status „Standby” und RTT 1104 ms).

Gängige Workflows

Den Status einer Nummer im Web verfolgen: App starten → WhatsApp-QR scannen → Zielnummer eingeben → die Oberfläche zeigt in Echtzeit RTT, Status (🟢/🟡/🔴) und das Aktivitätsmuster; das Ergebnis wird live in der UI angezeigt (React + Recharts).
Die Probe-Methode wechseln: In der Weboberfläche das Dropdown im Kontrollpanel nutzen, um zwischen Delete (Standard) und Reaction zu wechseln; im CLI-Modus wird standardmäßig „delete” verwendet.
Über Signal verfolgen: Bei Nutzung von Docker läuft der Dienst signal-api (bbernhard/signal-cli-rest-api) bereits; im Web wird Signal ausgewählt und dessen QR gescannt. Die verfügbaren Probe-Methoden für Signal sind reaction und message.
Vom Terminal aus verfolgen (WhatsApp): npm start → authentifizieren → Nummer eingeben → das Statuspanel in der Konsole beobachten.

Wesentliche Konfiguration

Laut .env.example und README, was ein neuer Nutzer zuerst anfasst:

BACKEND_PORT (Standard 3001) — Port des Backend-Servers.
CLIENT_PORT (Standard 3000) — Port der Weboberfläche.
SIGNAL_API_URL (Standard http://localhost:8080) — URL des Signal-API-Dienstes, erforderlich für Signal-Tracking.
BACKEND_URL (Standard http://localhost:3001) — URL des Backends, das das Frontend konsumiert.
NODE_ENV (Standard production) — Laufzeitumgebung von Node.

Häufige Fallstricke und Lösungen

Laut README, Issues und Community-Threads:

Verbindet sich nicht mit WhatsApp: Die im README dokumentierte Lösung ist, den Ordner auth_info_baileys/ zu löschen und den QR erneut zu scannen. (Hinweis: Das Volume in docker-compose.yml wird als baileys_auth:/app/baileys_auth_info gemountet, mit leicht abweichender Benennung; es lohnt sich, den tatsächlichen Container-Pfad zu prüfen, falls der Zustand über Neustarts hinweg bestehen bleibt.)
WhatsApp-QR erscheint nicht, Signal-QR schon (Issues #52, #67, #74, #64): Das ist der am häufigsten gemeldete Fehler. Das README löst es nicht direkt; es gibt offene Korrektur-PRs (z. B. #88 „fix: WhatsApp QR code not loading in web UI”). In der Praxis sind ein Update auf den neuesten Branch und das Neu-Erzeugen des Auth-Zustands die üblichen Schritte.
Build-Fehler beim Client (TS2322 beim Recharts-Tooltip) (#68, #69, PR #66/#61): Der Fehler Type '(t: number) => string' is not assignable… blockiert npm run build sowohl über Docker als auch npm. Er wurde in PRs zur Typisierung von labelFormatter behoben; falls er auftritt, diese Korrektur anwenden oder eine bereits korrigierte Client-Version nutzen.
Signal-QR nicht sichtbar und localhost:8080 mit 404 (#54): deutet darauf hin, dass der signal-api-Dienst nicht bereit ist oder den erwarteten Endpunkt nicht bereitstellt; prüfen, ob der signal-api-Container gestartet ist und SIGNAL_API_URL auf den richtigen Port zeigt.
Das Deaktivieren von Lesebestätigungen schützt NICHT: Das README stellt klar, dass diese Abhilfemaßnahme bei normalen Nachrichten greift, aber nicht gegen diesen konkreten Angriff; die vorgeschlagene wirksamere Abhilfe ist, „Block unknown account messages” in WhatsApp zu aktivieren (Einstellungen → Datenschutz → Erweitert), wobei WhatsApp nicht veröffentlicht, was es unter „high volume” versteht, sodass die Sonden vor Erreichen des Ratenlimits nicht vollständig verhindert werden.
Nicht offensichtliches Schwellenwertverhalten: Die Klassifizierung hängt vom gleitenden Median ab; bei instabilen Netzwerken wird der Schwellenwert kontinuierlich neu berechnet, sodass ein „Standby” nicht zwangsläufig bedeutet, dass das Gerät ausgeschaltet ist, sondern nur, dass der RTT 90 % des Medians überschritten hat.

Integrationen und Migration

Mit Baileys (WhatsApp Web): Der PoC stützt sich auf @whiskeysockets/baileys für die gesamte WhatsApp-Kommunikation; jede Integration mit WhatsApp Web über Baileys nutzt dasselbe Sitzungsmuster (QR + lokaler Zustand).
Mit signal-cli-rest-api (Signal): Das Signal-Tracking erfordert diesen Dienst (Modus json-rpc, WebSocket); es ist eine externe Abhängigkeit, die als separater Container läuft.
Mit Docker Compose: Die drei Dienste (backend, client, signal-api) werden zusammen orchestriert; das Backend speichert den WhatsApp-Authentifizierungszustand im Volume baileys_auth.
Migration zwischen PoCs desselben Angriffs: Da alle (ctrlsam/careless-whisper-python, 190-785/WhatsApp-Careless-Whisper, Ti-03/Careless-Whisper usw.) dasselbe Prinzip implementieren (Receipt-RTT), bedeutet „Migrieren” einen Wechsel von Sprache/Stack (TypeScript → Python/Go) und Abhängigkeit (Baileys für WhatsApp); die medianbasierte Schwellenwertlogik ist dem Ansatz des Papers gemeinsam. Es gibt keinen dokumentierten Konverter zwischen ihnen.

Anwendungsfälle und wem dieses Repository helfen kann

Sicherheits- und Datenschutzforscher, die eine lauffähige Implementierung des „Careless Whisper”-Papers benötigen: Der PoC übersetzt die RAID-2025-Arbeit in testbereiten Code (mit der BibTeX-Zitation des Papers), nützlich, um den Angriff in einer kontrollierten, einvernehmlichen Umgebung zu reproduzieren, zu validieren oder zu erweitern.
Teams, die die Side-Channel-Oberfläche ihrer Messaging-Abläufe prüfen oder prüfen möchten: Indem gezeigt wird, wie ein Delivery-Receipt-RTT Präsenz/Aktivität offenbart, dient es als Referenz, um zu verstehen, welche Metadaten (Status, Netzwerk, Nutzungshäufigkeit) in Messaging-Apps durchsickern können.
Sicherheitspädagogen und -kommunikatoren: Der explizite Disclaimer „research and educational purposes only”, der Abschnitt „How to Protect Yourself” und die drei Zustände (online/standby/offline) machen es als Lehrmaterial geeignet, um Datenschutzschwachstellen anhand eines konkreten Falls zu erklären.
Nutzer, die verstehen wollen, wie sie sich schützen können: Das README dokumentiert konkrete Abhilfemaßnahmen (Aktivieren von „Block unknown account messages” in WhatsApp; das Verständnis, dass das Deaktivieren von Lesebestätigungen nicht ausreicht), sodass eine Person das Tool nutzen kann, um die eigene Exposition zu prüfen und dann Abwehrmaßnahmen anzuwenden.
Entwickler, die mit Baileys oder signal-cli-rest-api arbeiten: Die Web-App + CLI + Docker Compose zeigt ein praktisches Muster, um beide Abhängigkeiten (WhatsApp-Sitzung per QR über Baileys und Signal-Receipts per WebSocket) in einem einzigen Express-+-socket.io-Backend zu kombinieren.

Ressourcen

Repository: https://github.com/gommzystudio/device-activity-tracker
Akademisches Paper (Quelle): Careless Whisper, arXiv:2411.11194 — RAID 2025, Best Paper Award
Kernabhängigkeiten: WhiskeySockets/Baileys (WhatsApp Web) · bbernhard/signal-cli-rest-api (Signal)
Community / Diskussion: GitHub Issues (https://github.com/gommzystudio/device-activity-tracker/issues) und GitHub Discussions (https://github.com/gommzystudio/device-activity-tracker/discussions)
Hacker-News-Threads (Repo): 46220607 (1 Pkt) · 46422304 (1 Pkt) · 46443724 (3 Pkt)
Hacker-News-Thread (Paper, 20 Pkt, 4 Kmt): 46085197
Unabhängige Nachbildungen: ctrlsam/careless-whisper-python (17★) · Ti-03/Careless-Whisper (14★) · 190-785/WhatsApp-Careless-Whisper (6★) · milouk/whatsapp-tracker (6★) · xalaetrx/Whatsapp-Tracker (4★)
Video: „Explorando Vulnerabilidades de Privacidade no WhatsApp: Device Activity Tracker na prática” (Portugiesisch, über dieses Repo) und „Track Anyone On WhatsApp | WhatsApp Tracker | Real Time Tracing” (Titel gefunden per YouTube-Suche am 1. September 2026; keine Aufrufe-/Kanalzahlen erfasst)
Paketregister: Das Projekt wird in keinem Register veröffentlicht (private: true in package.json); die Abhängigkeiten selbst sind verfügbar (Baileys auf npm, signal-cli-rest-api als Docker-Image)
Star History (im README eingebettet): https://www.star-history.com/#gommzystudio/device-activity-tracker&type=date&legend=top-left

Methodischer Hinweis: Dieser Artikel stützt sich auf das README, CONTRIBUTING.md, LICENSE, package.json, .env.example und docker-compose.yml des Repositorys, die arXiv-Paper-Seite (2411.11194), die GitHub-API (Repository, Contributors, Forks, Repository-Suche), die Profile der Abhängigkeiten und die am 1. September 2026 konsultierten Hacker-News-Threads. Zahlen ändern sich mit der Zeit. Quellen auf Reddit, X/Twitter und Product Hunt sowie YouTube-Aufrufe-/Kanalzahlen konnten während dieser Recherche nicht verifiziert werden; diese Plattformen werden ausdrücklich nicht behauptet. Das Projekt erklärt sich ausschließlich für Forschungs- und Bildungszwecke.