4 ms·

> As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that. Not all the sensor APIs have a hard requ

> As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that. 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.

baybal2 8y ago
Well, not all... Googlers had no idea what a gold mine they were giving away up until around late 2016, when they unknowingly broke high precision timing in V8. What about a keylogger with 50% accuracy?
- gsnedders 8y ago
  V8's timers have nothing to do with this, given the API doesn't give the data to even do any timing analysis on. 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.
  - baybal2 8y ago
    The tricks had much to do with kalman like techniques, and possibly non-linear analysis, than doing brute force position estimation or statistics. 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.

4 ms·

> As for Facebook and the accelerometer, I'm presuming you're on Android, so you can definitely blame Google for that. Not all the sensor APIs have a hard requ

by gsnedders 8y ago

baybal2 8y ago
Well, not all... Googlers had no idea what a gold mine they were giving away up until around late 2016, when they unknowingly broke high precision timing in V8. What about a keylogger with 50% accuracy?
- gsnedders 8y ago
  V8's timers have nothing to do with this, given the API doesn't give the data to even do any timing analysis on. 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.
  - baybal2 8y ago
    The tricks had much to do with kalman like techniques, and possibly non-linear analysis, than doing brute force position estimation or statistics. 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.