Not all the sensor APIs have a hard requirement to require permissions; accelerometer data is available at a low sampling frequency in Chrome, which as far as I'm aware avoids any known attacks based on accelerometer data.
Not all the sensor APIs have a hard requirement to require permissions; accelerometer data is available at a low sampling frequency in Chrome, which as far as I'm aware avoids any known attacks based on accelerometer data.
What about a keylogger with 50% accuracy?
The accelerometer is limited to (IIRC) 25Hz without a permissions prompt. IIRC, at that sampling interval, you can't even distinguish between a phone being held in a hand and a phone in a pocket, and I know the decision to go with 25Hz was done on the basis of various studies. From memory, some study failed to get numeric PINs from full-screen entry at 60Hz, and a typical on-screen keyboard requires much more granularity than that.
For that though, you had to have an ability to do millisecond precision timestamping. I'm not math PhD, but been told by one that the only avenue to mitigate that was to drive down sampling frequency to single hertz.
Guys who write web standards today don't even try to put some farsight into security implications of countless random apis being introduced to the web standard every year.
Would Chrome unbreak the timing, or if somebody will find a workaround, that technique will become viable again.