A modern handset carries a cluster of inertial and environmental sensors: a three-axis accelerometer, a three-axis gyroscope, a magnetometer, usually a barometer, an ambient light sensor and a proximity sensor. They are cheap, low power, and sampled continuously by the operating system for screen rotation, step counting, image stabilisation and navigation.
None of them were treated as sensitive when the mobile permission models were designed, because none of them are pointed at anything. A camera looks at a scene. An accelerometer measures the acceleration of a small block of silicon. The gap between those two descriptions is where this whole category lives.
Typing has a physical signature
When you tap a phone screen, the device moves. The movement is tiny and depends on where on the glass the tap landed, because a tap near the top-left rotates the handset differently from one near the bottom-right. The gyroscope and accelerometer register that difference.
Work on turning this into keystroke recovery goes back to 2011 and has been repeated in many forms since. Broadly, a classifier trained on motion traces labelled with known taps can then recover unknown input from the same device and grip. Accuracy varies enormously with posture, walking versus sitting, keyboard layout and the number of candidate values. The results are far better than chance and far worse than a keylogger.
The result that made this concrete for the web was work published in 2017 showing that the inference could run from JavaScript in a mobile browser, with no permission prompt, recovering PINs from a numeric entry field at rates well above guessing. A background tab, an embedded advert frame, or an open page in another app's web view was enough to be listening.
Keystroke inference from motion is noisy and rarely recovers arbitrary text cleanly. It performs far better against short inputs from a small alphabet, where a ranked list of a few dozen candidates is already a successful attack. A PIN pad has ten keys and four positions, which is close to the ideal target for a noisy classifier.
A gyroscope is a poor microphone, and poor is not zero
Researchers at Stanford presented work in 2014 showing that a MEMS gyroscope is sensitive enough to register acoustic vibration in the surface it rests on. Sampling limits mean it captures only the low end of the speech band, so the result is not a recording. What they demonstrated was speaker identification, some recovery of spoken digits, and enough signal to distinguish speakers by gender reliably.
Later work extended the idea to the loudspeaker inside the same phone, where the vibration path is shorter and the coupling stronger. The general lesson is that any device sensitive to vibration is on the acoustic channel to some degree, whatever it was designed to measure. This is the mobile relative of the older physical-emanation research, which found readable signals in the electromagnetic leakage of display cables.
Calibration data as a device fingerprint
The result with the widest practical reach is not about content at all. Every MEMS sensor is imperfect, and manufacturers store a small per-unit calibration correction at the factory. Researchers showed in 2019 that this correction can be recovered from ordinary sensor output, that it does not change over the device's life, and that the combination across accelerometer, gyroscope and magnetometer is effectively unique to the individual handset.
That gives a globally unique, permanent device identifier that:
- Requires no permission on the platforms that exposed the sensors to the web
- Survives a factory reset, since it comes from the hardware
- Is identical across apps and across browsers, so it links otherwise separate identities
- Cannot be reset by the user, because there is nothing to reset
This is a stronger identifier than anything in conventional browser fingerprinting, which mostly assembles probabilistic signals from configuration. Apple responded by adding noise to sensor output and restricting web access to motion data. The response elsewhere has been less uniform.
The rest of the sensor cluster
| Sensor | Intended use | Demonstrated inference |
|---|---|---|
| Accelerometer | Orientation, step counting | Tap position, gait identification, transport mode, speech-band vibration |
| Gyroscope | Rotation, stabilisation | Tap position, limited audio recovery, calibration fingerprint |
| Magnetometer | Compass heading | Indoor position from magnetic maps, nearby electrical activity |
| Barometer | Altitude assist for navigation | Floor within a building; correlated with weather data, a location constraint |
| Ambient light | Screen brightness | Coarse inference about screen content and nearby movement |
The barometer entry deserves a note, because it is the one people find least intuitive. Atmospheric pressure varies with altitude at a rate fine enough to distinguish building floors, and it also varies with weather. A pressure reading, compared against public meteorological data for a set of candidate regions, narrows where a device is without touching the location API.
What the platforms changed
The mitigations that have landed are worth knowing precisely, because they are partial and uneven.
Android added a permission in version 12 that gates sensor sampling above 200 Hz. Below that rate, motion sensors remain available to any installed app without a prompt. The rate limit removes the highest-fidelity attacks and leaves a usable channel.
iOS gates activity and pedometer data behind a Motion and Fitness permission, while raw motion readings inside an app are available without one. On the web side, mobile Safari requires an explicit user gesture and permission before a page receives device motion events, and there is a setting to refuse it outright.
Browsers generally now restrict these interfaces to secure contexts and gate them through permissions policy, so a third-party frame does not inherit access from the page containing it. That closes the specific advertising-frame path from the 2017 work.
Hardened Android distributions go further: GrapheneOS adds a user-toggleable Sensors permission covering the sensors the standard model leaves ungated, so an app that has no business reading the gyroscope can be told it has no gyroscope to read.
How much this should change what you do
Proportionality matters here. For most people, most of the time, this is not the channel that is going to hurt them. A malicious app that already got installed has better options. An advertising network gets more from the identifiers it is handed than from statistical inference on jitter.
Two situations are different. The first is fingerprinting, which needs no accuracy at all: a permanent unique identifier is valuable whether or not anyone can also read your PIN, and it is the part of this research with a clear commercial incentive attached. The second is targeted attention, where an adversary willing to spend effort on one person can use a channel that is impractical at scale.
Permission models describe capabilities in the language of what a component is for. Attacks work in the language of what it physically measures. Every gap between those two vocabularies is a candidate side channel.
The reasonable steps are the ordinary ones. Keep the number of installed apps small, since permission review only covers the permissions that exist. Refuse motion access to websites, which mobile Safari lets you turn off in settings and which nothing you use will miss. Enter high-value PINs and passphrases while the phone is resting on a surface rather than held, which flattens the very signal these attacks depend on. If your situation warrants it, use a distribution that lets you revoke sensor access per app.
The wider point outlasts any one sensor. As devices gain more instruments, the number of physical quantities they measure grows faster than the number of things users are asked to consent to, and the research keeps finding that the two lists were never the same list.