What the data revealed.

While researching the app, we noticed traffic that did not match what the product appeared to do. Following it, we found the app enumerating devices on the local network, transmitting the observed data, and updating the map in real time.

The unsettling part was not only that device information was being collected. The laptop itself had become a sensor inside the network-a useful position from which to discover systems that were never interacting with the app directly.

The moment it made sense: the traffic was not serving the app's visible function. It was using the machine as a vantage point into the local network.

We were tracing a popular mobile client to understand its session model when a heartbeat request flushed a batch that had nothing to do with the visible feature set. Alongside the session envelope: gyroscope readings, accelerometer deltas, ambient light, screen brightness, and a flag for whether the phone was face-up or face-down on a surface.

None of it was needed to render a video, refresh a feed, or serve an ad. It was joined to the session and shipped to the same endpoint as the analytics blob, at the same cadence, on every network the device touched. The client was not just reporting what the user did. It was reporting how the phone lived in the room.

The moment it made sense: the payload was not a stream of events. It was a stream of the device itself.

Watching the login flow, we saw no payload carrying typed characters. What did leave the device on every focus/blur was a compact numeric series - inter-key intervals in milliseconds, key hold times, backspace bursts, and pause distributions.

Replayed across sessions, that series lined up with a specific person more reliably than any nickname change, logout, or reinstall could clear. The signal belonged to the human, not the install. A profile that survives everything a user is normally offered to reset.

The moment it made sense: removing the text did not remove the person.

A field in the request header held the current battery level and thermal band. Harmless in isolation, and easy to justify as "diagnostics." Then we replayed a day of traffic across accounts and noticed the shape.

Two accounts, on the same physical device, on the same hours, produced the exact same drain slope and the same thermal step at the same wall-clock moment. The server never needed a device ID that a user could reset. The physics of the battery was the device ID.

The moment it made sense: the identifier was not a value the client chose to send. It was the shape of a value that could not be faked.

The uploads were small - under a kilobyte - and timed to changes in the room's audio environment rather than to any user action. Decoded, they were compact spectral hashes: inaudible fingerprints of ambient sound, not speech.

Cross-referenced with other devices reporting similar hashes at the same moment, the picture became clear. This wasn't surveillance of what was being said. It was surveillance of co-presence - which other devices, running which content, were currently in earshot of each other.

The moment it made sense: the microphone was not being used to record. It was being used to triangulate.

Two apps, published by different vendors, both shipped the same third-party SDK. On launch, each broadcast a small UDP announcement on the local Wi-Fi. Any other device on the same network running the same SDK answered with a rotating identifier.

The correlation never touched a backend. It was built quietly, between phones, in the seconds after each app opened - and only reported later, in aggregate, so no single upload looked like a fingerprint on its own.

The moment it made sense: the correlation was not on the backend. It was on the router.