What Is 'Sensor Data'? The Telemetry Behind Bot Detection

When you load a page protected by a modern anti-bot system, a small program starts running before you’ve done anything at all. Its job is to take a reading — of your device, your browser, and, over the next few seconds, your behavior — package that reading up, and send it to a server that decides whether you’re a person or a program. In the anti-bot world, that package has a name: sensor data.

The term is borrowed, aptly. A physical sensor turns something about the world into a number. A detection script does the same to your session: it turns hundreds of small facts about your environment and behavior into a structured payload, usually encoded or obfuscated, that a server-side model scores. Understanding what’s in that payload — and what it costs — is the key to understanding both how detection works and why it’s ethically fraught.

Sensor data is not one signal — it’s a census

The mistake people make is imagining a single “bot score.” What’s actually collected is closer to a census of your session, and it falls into three broad categories.

Environment attributes — the fingerprint. These are the static-ish facts about your device and software: browser and version, operating system, screen dimensions, installed fonts, language and timezone, hardware concurrency, audio-stack quirks, and graphics capabilities. Individually, most of these are unremarkable. Collectively, they’re startlingly identifying — the specific combination of attributes on your device is often unique or nearly so, which is the entire principle behind device fingerprinting.

Behavioral signals — the reading over time. The fingerprint describes a moment; behavior describes a duration. How the pointer moves, the rhythm and corrections of typing, scroll velocity against reading time, the small delays of actually perceiving and deciding. This is the signal least tied to any spoofable attribute, because plausible human noise has a structure that’s easy to underestimate.

Coherence and integrity — do the facts agree, and was the reading honest. The subtlest and often most valuable part. Any single attribute can be faked; the hard part is making all of them agree the way they naturally do on a real device — an iPhone that also reports a desktop graphics card is caught not by any one value but by the seam between values. Alongside this sits integrity checking: did the collection script itself run untampered, or did something try to feed it fabricated readings?

The GPU: three different tricks, often confused

Nowhere is the power — and the invasiveness — of sensor data clearer than in what a browser can learn from your graphics hardware. Three distinct techniques get lumped together here, and telling them apart matters.

1. WebGL / canvas fingerprinting. Ask the browser to render the same text or 3D scene on any two machines and the output pixels differ subtly — a consequence of different GPUs, drivers, and rendering stacks. Hash that output and you get a stable identifier. The browser will also readily report GPU vendor and renderer strings outright. This is mature, widely deployed, and the backbone of graphics-based fingerprinting.

2. GPU timing fingerprinting (DrawnApart). A 2022 research technique that goes deeper: instead of the rendered image, it measures the timing behavior of individual execution units inside the GPU using WebGL. The result can distinguish two devices with byte-for-byte identical hardware and software, because it’s reading manufacturing-level physical variation. Its purpose is to make a fingerprint more stable and harder to shake.

3. GPU shader-cache persistence (ShaderGhost). Different in kind from the first two. Rather than identifying your device, this writes an identifier into the GPU’s compiled-shader cache and reads it back later — a value that can survive clearing cookies, wiping the browser profile, and moving between sites. It’s not a fingerprint; it’s a supercookie hidden in a place most privacy tools never think to clear. “Clear your cookies — it’s still watching,” as its proof-of-concept puts it.

What unites all three is the property that makes graphics signals so prized: they derive from the hardware, so they persist where other identifiers don’t — across IP changes, VPNs, cookie clears, and incognito windows. That durability is precisely why they’re powerful for detection. It’s also precisely why they’re a privacy problem.

The tension no honest defender can dodge

Here is the part that separates a thoughtful practitioner from a careless one. The exact same durable signal that lets a defender catch a bot farm rotating through thousands of proxy IPs is the signal that lets anyone track a real person across those same IP changes — including the privacy-conscious user who cleared their cookies, switched networks, or opened a private window specifically to not be followed.

Device fingerprinting is dual-use by nature. Pointed at automation, it’s a defense. Pointed at people, it’s surveillance. And the sensor-data payload doesn’t inherently know which it’s doing — the same GPU fingerprint serves both. A defender who collects this data is holding a genuine capability to de-anonymize their own legitimate users, and pretending otherwise is how well-intentioned anti-abuse work quietly becomes a tracking apparatus.

This isn’t an argument against fingerprinting. It’s an argument for handling it like what it is: a powerful and invasive instrument that demands purpose, restraint, and honesty.

What a defender should actually take from this

Sensor data is the richest input in client-side detection, and it comes with the strongest caveats. Four of them matter most:

• It’s collected on the client, so never trust it blindly. Every value in the payload originates on a machine the adversary may control, which means every value is, in principle, forgeable. Sensor data is evidence to weigh and corroborate, not truth to accept. The coherence and integrity checks are often worth more than any single attribute.
• Durability cuts both ways — treat it as sensitive. A signal that survives IP changes and cookie clears is, by definition, one that can track a person who is trying not to be tracked. Collect it with a clear purpose, minimize what you keep, retain it only as long as the security need actually lasts, and be honest with users about it. “We can” is not “we should.”
• Protect the reading itself. If the integrity of the collection script can be compromised — fed fabricated values, or lifted and replayed — the whole payload becomes untrustworthy. The security of the sensor is as important as the signals it gathers.
• Corroborate against what’s hard to forge. The most robust verdicts don’t rest on the client’s self-report. They anchor client-side sensor data against server-side truths — velocity, history, behavior over time — that an attacker can’t simply assemble.

Sensor data is, in the end, a mirror the web holds up to your device without asking. For the people building detection, the job is to read that mirror carefully enough to catch the machines — and to remember, every time, that most of the faces in it are human.

---

Further reading

• DrawnApart: A Device Identification Technique based on Remote GPU Fingerprinting — the original research (arXiv 2201.09956).
• AmIUnique’s explainer on DrawnApart — an accessible walkthrough of the GPU-timing technique.
• BrowserLeaks — hands-on demonstrations of what your browser reveals, including WebGL.
• ShaderGhost (shaderghost.gg) — proof-of-concept for GPU shader-cache persistence.

This article is a defensive and privacy-focused overview of client-side telemetry. It describes what these signals are and why they matter, not how to forge or defeat any specific system.