How motion sensors leak a stable per-device fingerprint via calibration noise, why iOS gates it behind a prompt, and why Chrome on Android still doesn't.
Canvas and WebGL fingerprinting read how your device renders. Sensor fingerprinting reads something different: how your device's physical hardware moves — or rather, how it reports movement it never actually made. Every accelerometer, gyroscope, and magnetometer ships from the factory with tiny, permanent manufacturing imperfections, and the raw data those chips expose to a web page carries that imperfection as a signature. This piece looks at how the DeviceMotion, DeviceOrientation, and Generic Sensor APIs expose that signal, why it's overwhelmingly a phone-and-tablet phenomenon, and why the permission changes that closed it on iOS never arrived on Android.
Key Takeaways
- The
DeviceMotionEventandDeviceOrientationEventAPIs expose live readings from a device's motion hardware. The newer Generic Sensor API classes (Accelerometer,Gyroscope) cover the same hardware but are Chromium-only — Safari and Firefox implement neither. - Manufacturing tolerances leave every accelerometer and gyroscope chip with a slight, consistent bias and noise pattern — a calibration fingerprint that stays stable across sessions, browsers, and even factory resets, because it's baked into the physical silicon, not software state.
- This is a mobile-first vector: laptops and desktops generally have no accelerometer or gyroscope at all, so the signal barely exists off of phones and tablets.
- Permission gating is split, not universal. iOS has required an explicit prompt since iOS 13, which genuinely closed the silent version there. Chromium never prompts: its own design docs specify accelerometer and gyroscope as auto-grant. On Android, a top-level HTTPS page can still read calibration noise with no prompt at all.
- BrowserInsight's fingerprint check reports your device's exposed signals side by side, and the dedicated mobile fingerprinting guide covers how this fits into the broader mobile-tracking picture.
The DeviceMotion, DeviceOrientation, and Generic Sensor APIs
Two overlapping generations of API expose motion data to a web page. The older pair — DeviceMotionEvent and DeviceOrientationEvent — fire continuously once a listener is attached, delivering acceleration, rotation rate, and orientation angles as plain event properties:
window.addEventListener('devicemotion', (event) => {
const { x, y, z } = event.accelerationIncludingGravity;
// x, y, z drift slightly even when the device sits still on a table
});
The newer Generic Sensor API family — Accelerometer, Gyroscope, and Magnetometer — replaces the event-based model with dedicated sensor objects a script can construct, configure, and poll directly. (The W3C's Motion Sensors Explainer is a helpful non-normative Working Group Note describing how these fit together; the interfaces themselves are defined in separate per-sensor specifications.)
const sensor = new Accelerometer({ frequency: 60 });
sensor.addEventListener('reading', () => {
console.log(sensor.x, sensor.y, sensor.z);
});
sensor.start();
Two caveats on reach. The Generic Sensor classes are a Chromium feature: Chrome, Edge, and Opera implement them, while Safari and Firefox implement neither Accelerometer nor Gyroscope, so the older event pair remains the only route that works across every engine. And within Chromium, Magnetometer sits behind the #enable-generic-sensor-extra-classes flag rather than shipping on by default — magnetometer readings aren't available to an ordinary page the way accelerometer and gyroscope readings are.
Both approaches ultimately read the same underlying hardware. For fingerprinting purposes what matters isn't which API delivered the numbers — it's what the numbers contain even when nothing is moving.
Calibration Noise as a Stable Per-Device ID
Set a phone flat on a table and query its accelerometer. It should report (0, 0, 9.8) — gravity, and nothing else. In practice it reports something like (0.013, -0.007, 9.79): small, non-zero readings on every axis. That deviation isn't measurement error in the everyday sense — it's the accelerometer's factory calibration, and it's remarkably consistent. MEMS accelerometers and gyroscopes are manufactured in bulk, and each individual chip carries a slightly different bias and scale-factor error from the manufacturing process. Academic research on sensor-based device fingerprinting has repeatedly found that this bias vector carries real entropy — enough to help tell individual units of the same model apart, especially when readings from several axes and sensors are combined.
That's what makes calibration noise a genuinely different category of signal from canvas or WebGL output. A canvas hash changes if you switch browsers or GPU drivers change how they rasterize; a font list changes if you install a new font. Calibration noise doesn't change with any of that — it survives a browser update, a factory reset, a fresh OS install, even switching from Chrome to Firefox on the same phone, because it's a property of the physical sensor die itself, not of any software state a script could clear. A script that captures a few seconds of "at rest" readings and extracts the mean bias per axis gets a value that's stable for the working life of the device.
Permission Gating — and Where It Doesn't Apply
For years, both DeviceMotionEvent and DeviceOrientationEvent fired with no permission prompt at all — any page could attach a listener and start reading calibration noise silently, in the background, with no visible indication to the user. That changed with iOS 13, when Apple began requiring an explicit call to DeviceOrientationEvent.requestPermission() — which must originate from a user gesture like a tap — before Safari delivers any motion or orientation events at all. A page can no longer read the accelerometer just by loading; it has to ask, and the user has to see and accept a system dialog first.
It's tempting to assume every engine followed. Chromium didn't, and that's the detail worth getting right, because it covers most of the world's phones.
Chromium does restrict who can reach the sensors. Access is gated through the Permissions Policy mechanism, whose default allowlist for accelerometer and gyroscope is 'self' — so a cross-origin third-party iframe can't read them — and readings require a secure (HTTPS) context and a top-level, focused browsing context. What Chromium does not do is ask the user. Its own Generic Sensor design document spells the model out plainly: accelerometer and gyroscope are "auto-grant + opt-out". The permission is granted without a prompt ever appearing.
This is also why accelerometer, gyroscope, and magnetometer show up as queryable names in the broader Permissions API fingerprint vector — but a name being queryable is not the same as a user being asked.
So the honest summary is a split, not a clean win: the raw calibration signal is still there in the hardware everywhere. On iOS, a script genuinely cannot harvest it without a user tapping "Allow". On Chrome for Android, an ordinary top-level HTTPS page can still attach a devicemotion listener and read calibration noise with no prompt and no visible indication — exactly as it could a decade ago. iOS closed the silent version of this technique; Chromium narrowed the doorway without ever putting the decision in front of the user.
Why This Is a Mobile-First Vector
Accelerometers and gyroscopes exist in a laptop or desktop for exactly one common reason — a lid-close or shake-detection feature on some machines — but the overwhelming majority of desktop hardware ships with none of this sensor package at all, and neither DeviceMotionEvent nor the Generic Sensor classes have anything to read on a typical desktop browser. Phones and tablets are the opposite: motion and orientation sensors are essentially universal, because the OS itself depends on them for screen-rotation, step-counting, and augmented-reality features, so the hardware — and the API surface exposing it — is present on effectively every device in that category.
That's also why this technique complements rather than duplicates the rest of the mobile fingerprinting picture: screen geometry and device-pixel-ratio narrow down which device model you're likely holding, while sensor calibration noise, where it's still readable, can narrow all the way down to that specific unit — the same distinction that makes it valuable on a platform where GPU and font entropy are otherwise flattened by mass production. It's a small piece of the overall browser fingerprinting picture, but on mobile traffic specifically, it's one of the few signals that survives even when a user resets everything else about their device.
Mitigations
- Keep your OS and browser current. The iOS permission gate shipped as a browser update, not an opt-in setting — an outdated mobile browser may still expose motion data without ever prompting.
- Decline motion/orientation prompts you don't recognize needing — and know when you won't get one. On iOS, a page requesting accelerometer access for no obvious reason (it isn't a game, AR feature, or step counter) has little legitimate use for it, and declining works. On Chrome for Android there is usually no prompt to decline at all, so the prompt is not a control you can rely on there.
- On Android, the browser you choose is the actual lever. Because Chromium auto-grants, the meaningful mitigation isn't a prompt — it's using a browser that restricts or randomizes sensor access as a matter of policy, which is the same class of defense covered in our anti-fingerprinting tooling comparison.
- Treat this as one signal among many. Even where it's readable, calibration noise contributes one axis to a larger fingerprint alongside screen metrics, GPU strings, and permission states — no single signal is a silver bullet for trackers, and no single fix eliminates fingerprinting risk on its own.
- Check what your own device exposes. BrowserInsight's fingerprint check reports your browser's live signal set, run directly on the phone you're trying to evaluate.
Frequently Asked Questions
Can a website read my phone's accelerometer without asking?
It depends on the phone. On iOS, no — Safari has required an explicit permission prompt via DeviceOrientationEvent.requestPermission() since iOS 13, and no events arrive until you accept. On Chrome for Android, usually yes: Chromium treats accelerometer and gyroscope as auto-granted and shows no prompt. It does require HTTPS, a top-level page (not a cross-origin iframe), and a focused tab — but within those limits, a page can read motion data silently.
Does resetting my phone change its sensor fingerprint?
No. Calibration noise comes from manufacturing tolerances in the physical accelerometer and gyroscope chips, not from any software state. A factory reset, OS reinstall, or browser switch leaves the underlying hardware bias unchanged.
Do desktop and laptop browsers expose this signal too?
Rarely. Most desktop and laptop hardware simply doesn't include an accelerometer or gyroscope, so DeviceMotionEvent and the Generic Sensor API classes have nothing to report. This is overwhelmingly a phone-and-tablet signal.
Is sensor fingerprinting more identifying than canvas or WebGL fingerprinting?
Not on its own — it's a narrower, single-axis signal. Its value to trackers is that it's unusually stable (surviving resets and browser changes) and available on mobile devices where other high-entropy desktop signals like fonts and canvas rendering are comparatively flat.
Does declining the motion-permission prompt fully protect me?
Where you actually get a prompt — iOS — declining is effective for that origin: a page that never receives permission gets no motion or orientation events at all. On Chromium there is typically no prompt to decline, so this isn't a control you can lean on there. Either way it doesn't affect other passive signals like screen size, GPU renderer strings, or permission states, which a page can still read without any prompt.
Conclusion
Sensor fingerprinting is a narrow but unusually durable signal: where a canvas hash or font list can shift with a software update, the calibration bias baked into an accelerometer or gyroscope chip stays put for the device's working life. It's also a clean example of how mobile and desktop fingerprinting genuinely diverge — a signal that's nearly absent on laptops is close to universal on phones, precisely because the hardware itself is universal there.
The permission story is the part most summaries get wrong. iOS really did close the silent version of this technique in 2019, and it's easy to generalize from that into "browsers fixed this." Chromium never adopted a prompt — its documented model is auto-grant with an opt-out — so on the Android majority of mobile traffic, a top-level HTTPS page reads calibration noise today about as freely as it did before iOS 13. The underlying physics hasn't changed either way, which is exactly why this vector is worth understanding on its own rather than folding it into the desktop-oriented fingerprinting playbook.
Recommended Reading:
