You tap Allow on the camera prompt, Allow on the contacts prompt, and by the third install of the week you're just tapping the blue button like it owes you something. Reasonable. But some data never triggers a prompt at all. That's the part nobody explains.
Whether an app needs your permission to read a sensor depends on one thing: whether the operating system classifies that sensor's data as dangerous. Sensors deemed low-risk are open to any installed app by default, no prompt, no permission string in the manifest, no decision required from you whatsoever. The accelerometer, gyroscope, and barometer all live here, on both Android and iOS.
The lobby and the locked room
Think of your phone's sensors as two tiers. One tier sits in the lobby: anyone who walks in the building can read it. The other is behind a desk with a sign-in sheet.
The lobby sensors are the motion and position ones. Accelerometer, gyroscope, magnetometer, barometer, step counter. These measure the physical world around the phone itself, not anything about you specifically, which is the justification OS designers used for leaving them open. A fitness app shouldn't need to explain why it wants to count steps. Fair enough, as far as it goes.
The locked sensors are the ones tied to identity or intimate context: camera, microphone, GPS, and on some devices, the heart rate monitor. These require an explicit runtime permission. The user sees the prompt, taps Allow or Deny, the OS logs the decision. Revoke it later in settings and the app goes blind.
Android formalizes this split in its permission model. Sensors without a `uses-permission` entry in an app's AndroidManifest.xml are simply readable. iOS uses a similar framework, though Apple has tightened background access to motion data in successive OS versions, requiring a `NSMotionUsageDescription` key in the app's Info.plist before Core Motion data flows.
What an open sensor can actually reveal
Here's where it gets uncomfortable.
The accelerometer was designed for screen rotation and shake-to-undo. Researchers at universities including Newcastle and Illinois have repeatedly demonstrated that accelerometer data alone, sampled at high frequency, can infer PINs typed on a touchscreen with accuracy rates above 70% after a few attempts. The physical micro-vibrations of your finger landing at position X versus position Y are distinct enough to classify. It's less like hacking and more like a safecracker pressing an ear to the door.
Gyroscope data has been used to reconstruct speech in lab conditions, because the sensor picks up the resonance of sound waves vibrating the phone's chassis. Not reliably, not at scale in the wild. But the channel exists.
Consider two people who download the same free game: Priya on Android 13, Marcus on an older device running Android 9. Priya's OS caps the accelerometer sampling rate available to background apps, a mitigation Google introduced specifically to limit side-channel attacks. Marcus's phone has no such cap. Same app, same install, meaningfully different sensor exposure.
The mitigation matters. Both Android and iOS have progressively rate-limited background sensor access, even for the open sensors. iOS 12.2 required explicit permission for DeviceMotion and DeviceOrientation in web browsers, closing a significant web-based vector. Android's `HIGH_SAMPLING_RATE_SENSORS` permission, introduced in Android 12, requires apps to declare intent before sampling above 200Hz.
The lobby is still open, but the OS has started checking bags at the door.
What you can actually do
Update your OS. Not for the new emoji. Running a current OS is the single most effective thing you can do here, because the rate-limiting and permission tightening that actually close these gaps simply don't exist on older versions. On Android, Settings > Privacy > Permission Manager shows which apps hold declared permissions. It won't show you which apps are reading the open sensors, because by definition nothing is logged for those.
For browser-based sensor access, both Chrome and Safari now surface permission prompts for motion data on sites that request it. If a random website asks for motion access, that's worth a raised eyebrow.
If you find an app you don't recognize holding the motion permission in your settings, revoke it. The cost is low.
The honest read on all of this: the open-sensor risk is largely theoretical in everyday use. Exploits require sustained access and significant post-processing. But the reason it stays theoretical isn't that the channel is harmless. It's that OS vendors have been quietly narrowing the window, version by version, treating it as a slow-burn engineering problem rather than a crisis. Which is probably the right call. It just means the work is never quite finished, and the lobby never quite closes.