Your Phone's Fingerprint Is Its Flaws

On a phone, press Run the test and follow the instructions: lay the phone flat, flip it over, then stand it on each long edge and each end. The current instruction also sits in a bar at the bottom of the screen, so there's no need to scroll back. The test stops by itself once it has all six poses, after two minutes, or when you leave the page; press Finish to stop sooner. Nothing is read before you press the button or after the test stops. The result appears here, and the panels below show the details.

No phone handy? Simulate a phone runs the same test on a made-up phone with known flaws.

Gravity is the one reference everyone carries. Lying flat, a perfect accelerometer reads exactly 1 g on one axis and zero on the other two. Turn it face down and that axis should read exactly −1 g. The average of the two readings is the axis's offset; half the difference, compared with 1 g, is its gain error. A gyroscope is even simpler: at rest it should read zero.

Lay the phone flat, then face down, then stand it on each long edge and each end, holding each pose still for about a second. A face fills in once the page has seen it held still.

Inside the sensor, an analog-to-digital converter turns each reading into a whole number of counts. The phone then multiplies by a calibration gain measured for this unit at the factory, adds an offset, and hands the result to the browser. Strictly the gain is a 3×3 matrix, because each axis also picks up a little of the other two. Either way, the change from one reading to the next is gain × whole number of counts: the offset cancels, even if the browser lets it drift. Zoom in on those changes and they aren't continuous at all. They sit on a grid whose spacing is the factory's gain.

Finding the spacing is a greatest-common-divisor problem with decimals. The page follows the SensorID paper: it guesses each axis's step from the spacing the changes cluster at, rounds every change to whole counts, and refits the whole gain matrix by least squares, letting in bigger changes as the estimate sharpens. Noise from the physical sensor doesn't blur the grid, because that noise happens before the counting: it moves a reading to a different grid point, never between two.

The grid steps are numbers the factory chose for this one phone, and they don't change: not when you clear cookies, not in a private window, not after a factory reset, because they live in the sensor's calibration, not in the browser. Round each step to 20 parts per million, hash the results, and you have an ID.

Press Keep this one, then capture again. The check compares the steps themselves, so it can tell the same phone from a different one even if a step happens to sit on a rounding boundary and flips the hex.

The GCD trick needs every change between readings to be an exact whole number of counts. So the cure is to break that exactness. The SensorID authors proposed adding random noise, spread evenly between −½ and +½ count, to each count before the calibration is applied: a reading can then land anywhere in its cell instead of on a grid point, the changes stop being whole multiples of anything, and the grid search comes back empty. They report that Apple adopted it in iOS 12.2 and also turned off Safari's motion access by default. Apple's own security note says only that the issue "was addressed with improved motion sensor processing" (CVE-2019-8541).

Their second suggestion suits browsers, which don't know the gain: round each reading to a multiple of the sensor's nominal step. Browsers took a blunter version. The W3C DeviceOrientation spec now requires readings to be limited to 0.1 m/s² and 0.1 °/s, and Chromium rounds them to those multiples, citing exactly this attack in its source. That puts every phone on the same grid, the browser's.

Neither costs ordinary motion features much. Walking swings the accelerometer by a few m/s² each step. On the simulated phone here, half a grid step is about 0.001 m/s², under a thousandth of that, and even rounding to 0.1 moves a reading by at most 0.05. Switch the defenses below: the walk's step count doesn't move, but the grid and the fingerprint above do.

A stable error is information. Calibration exists because no two sensors come out of the factory alike, so on many phones each one is measured and given its own correction. That correction makes the readings accurate, and it also makes them distinctive, because the correction itself is different for every unit and never changes. Accuracy needs the correction to be applied; privacy needs nobody to be able to read it back. The grid trick reads it back.

Why the grid gives so much away. Gravity can only tell you a gain to a fraction of a percent: your latitude alone shifts it by up to about 0.3%. The grid doesn't depend on gravity at all. Every change between two readings is an exact whole number of counts, so a few hundred readings pin the step far more tightly than gravity can, and the answer comes out the same every time. That combination, precise and repeatable, is what makes an identifier. A slow drift in the offset, by contrast, is useless for tracking, because it doesn't repeat.

The same stream, used honestly. Ride Report turns the same motion-sensor stream into a ride-quality meter on a tray table, and Scroll Report into a rolling 3D seismograph of your phone's motion. Both care about how readings change: bumps, sway, turbulence. Neither cares exactly which grid point a reading lands on. That gap between what motion features need and what fingerprinting needs is why the fixes are cheap: blur the last digit and every honest use still works. Rounding to 0.1 m/s² is the heavier hand: it erases any vibration smaller than that.

Fingerprinting in general. Browsers leak identity through anything that differs between devices and stays put: screen size, installed fonts, how a graphics card draws a curve, how the audio stack renders a test tone. Many of those shift with a software update or a settings change. Calibration is unusual because it's hardware: it survives clearing cookies, private windows and a factory reset. The fix had to come from the platform (Apple's noise, the browsers' rounding and permission prompts), because no page can protect you from another page.

What this page can and can't see. The SensorID fingerprint for iPhones came from the gyroscope and the magnetometer. The authors found their method didn't directly apply to the iPhone's accelerometer, and devicemotion doesn't include the magnetometer at all, so on an iPhone the gyroscope is the part that matters. This page tries the accelerometer too, which the authors could fingerprint on the Google Pixel 2 and 3. Like the paper, it recovers each sensor's full gain matrix, so axes that mix are fine. It skips the paper's last trick: on iPhones with an M-series motion coprocessor the matrix entries are whole multiples of 2⁻¹⁶ °/s, which let the authors round a slightly blurred estimate (Safari's offset drifted) back to the exact values.

What to expect on your phone. On an iPhone in Safari, the accelerometer sat on a grid of 1/65536 g on all three axes (exactly in one capture, to within a few parts in ten thousand in another). That is fixed-point storage, the same kind of 2⁻¹⁶ resolution the paper found in iPhone gyroscope data, and it is identical on every iPhone, so the page labels it "format" and leaves it out of the ID. Beneath it there was no coarser grid of the phone's own, and the gyroscope showed no grid at all, which fits the noise Apple added in iOS 12.2. A current Chromium-based browser should show the browser's 0.1 grid, going by its source; that hasn't been tried on an Android phone yet. A grid of your phone's own would mean neither defense reached this page.

Privacy. Everything runs on your device. Readings and the fingerprint are never sent anywhere: the only network request is an anonymous visit count when the page loads (GoatCounter, no cookies). The page stores nothing, and the fingerprint exists only in this tab until you close or reload it.