device activity tracker

Abstract

A phone number can reveal whether a device is active, in standby or offline (and more). This PoC demonstrates how delivery receipts + RTT timing leak sensitive device-activity patterns. (WhatsApp / Signal)

The Problem

Messaging apps like WhatsApp and Signal leak device state through delivery receipts. A recipient's phone acknowledges message delivery at different speeds depending on whether the device is actively used, in standby, or offline. This repo turns that timing side-channel into a working surveillance tool, demonstrating that a phone number alone is enough to track someone's activity patterns.

What This Does

device-activity-tracker implements the "Careless Whisper" research: it sends probe messages and measures Round-Trip Time (RTT) to classify a device as Online, Standby, or Offline. The project ships as a full-stack app with a React/Tailwind frontend (client/) and a Node/TypeScript backend (src/).

Two probe methods exist—sendReactionProbe and a second method in src/tracker.ts—both measuring how fast the recipient's device acknowledges delivery. The backend maintains per-device RTT history, computes medians and thresholds, and streams state changes to the web dashboard via WebSocket.

How It Is Wired

Execution starts at src/index.ts (CLI) or src/server.ts (web backend). src/server.ts:119 calls checkSignalConnection, which chains through checkSignalApiAvailable, getSignalAccounts, and startSignalLinking—the only path that makes an outbound network call. The server then hands off to the tracking engine.

The core logic lives in src/tracker.ts (24 functions) and src/signal-tracker.ts (25 functions). The signal tracker is the hub: 3 files import it, and its constructor and setDebugMode are called from multiple entry points. The internal call graph shows sendProbe -> sendReactionProbe, addMeasurementForDevice -> determineDeviceState, and sendUpdate -> calculateGlobalMedian as the critical path. markDeviceOffline triggers sendUpdate, which routes through calculateGlobalMedian—so a single offline event cascades through the entire state machine.

The frontend (client/src/App.tsx) is the second hub with 4 modules importing it, but it sits inside a circular dependency with Login.tsx and Dashboard.tsx. That cycle costs you: changing shared state or props in any of those three files risks runtime import errors, and the graph shows App at instability 0.33—meaning it's both depended-upon and dependent, the hardest kind of module to refactor.

The wiring for the CLI path (src/index.ts) has not been fully mapped—the analysis shows connectToWhatsApp and askForTarget as entry points, but their downstream effects aren't traced beyond shouldSuppressOutput handling console output.

How To Use It

git clone https://github.com/moses-y/device-activity-tracker
cd device-activity-tracker
cp .env.example .env
docker compose up --build

Frontend: http://localhost:3000, backend: http://localhost:3001. Scan the WhatsApp QR code, enter a target phone number, and watch the dashboard update with live RTT measurements and state classifications. For CLI-only tracking: npm start.

Real-World Use

A security researcher auditing WhatsApp's privacy posture runs this against a test account to quantify the RTT gap between active and standby states. The dashboard's per-contact cards (client/src/components/ContactCard.tsx) show live state, RTT, and threshold—enough to build a daily activity timeline from the addMeasurementForDevice history.

Code Health & Issues

Static analysis found 12 issues (9 high, 3 medium) across 4 categories:

High – Deep nesting (7 instances): client/src/App.tsx, Login.tsx, src/tracker.ts hit indentation depth 8. Flatten with guard clauses.
High – Import cycles (3 instances): App.tsx, Login.tsx, Dashboard.tsx form a circular dependency. Extract shared types to break it.
High – Duplicated code (19 repeated 6-line blocks across 4 files): extract shared helpers.
Medium – High branching density in src/index.ts: 50 branch points over 143 lines.

SDLC gaps: no CI pipeline, no lockfile committed (non-reproducible builds), wildcard CORS in src/server.ts, unpinned Docker base image, no Dependabot config, and a postinstall script in package.json that warrants review.

The Bottom Line

This is a functional proof-of-concept that demonstrates a real privacy vulnerability with working code, not a slide deck. The architecture is sound for a PoC, but the circular imports, deep nesting, and missing CI make it fragile to extend. Use it for security research and education—not production surveillance.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

42 files

TypeScript8
TSX6
JSON5
Markdown2
JavaScript2
CSS2

ReactTailwindDocker

Module dependencies

The 10 most depended-upon modules of 16, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_client_src_App["App"] n1_client_src_components_Login["Login"] n2_src_tracker["tracker"] n3_ent_src_components_Dashboard["Dashboard"] n4_t_src_components_ContactCard["ContactCard"] n5_client_src_reportWebVitals["reportWebVitals"] n6_src_signal_tracker["signal-tracker"] n7_client_src_index["index"] n8_src_server["server"] n9_client_src_App_test["App.test"] n9_client_src_App_test --> n0_client_src_App n0_client_src_App --> n1_client_src_components_Login n0_client_src_App --> n3_ent_src_components_Dashboard n3_ent_src_components_Dashboard --> n0_client_src_App n3_ent_src_components_Dashboard --> n4_t_src_components_ContactCard n3_ent_src_components_Dashboard --> n1_client_src_components_Login n1_client_src_components_Login --> n0_client_src_App n7_client_src_index --> n0_client_src_App n7_client_src_index --> n5_client_src_reportWebVitals n8_src_server --> n2_src_tracker n8_src_server --> n6_src_signal_tracker classDef cyc stroke:#ef4444,stroke-width:2px; class n0_client_src_App,n1_client_src_components_Login,n3_ent_src_components_Dashboard cyc;

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowDependencies declared without a lockfile - non-reproducible builds client/package.json

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high4

medium4

low1

Commit a lockfile beside the manifesthigh

client/package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

16 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Add a build gate for the deployable artifacts herehigh3 occurrences

Dockerfile

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Replace the wildcard CORS origin with an explicit allow listhigh

src/server.ts

origin: "*"

Any page on the internet can call the API with the browser's cookies attached, so a logged-in visitor to an unrelated site performs authenticated requests without knowing, and the wildcard combined with credentials is the exact configuration browsers refuse for that reason.

Fix: List the origins the API actually serves, and never pair a wildcard with credentials.

Enable Dependabot or Renovatemedium

2 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium

Dockerfile

node:20-alpine

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Add a non-root USER to the imagemedium

Dockerfile

CMD or ENTRYPOINT with no USER directive

A process running as root in the container is root against every mounted volume, and it turns any container escape or writable-mount mistake from a contained problem into a host one.

Fix: Create an unprivileged user, chown what it needs, and end the Dockerfile with USER.

Review the install lifecycle script and disable scripts in CImedium

package.json

postinstall

Install scripts are the execution vector for every npm compromise from event-stream onward, and a postinstall that fetches a binary makes the build depend on a URL nobody reviews.

Fix: Move the work into an explicit build step, or set ignore-scripts in CI and run it by name.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.