Re: sensor calibration fingerprinting

I’ve opened https://github.com/w3c/accelerometer/issues/54 <https://github.com/w3c/accelerometer/issues/54> to track the calibration concern for accelerometer (in addition to device orientation) and linked to this thread with Paul’s recommended mitigation.

I’m not totally sure if a mitigation on the accelerometer API should apply to the LinearAcceleration and Gravity as well as default accelerometer sensor, but I suspect it would make sense to apply to all of them. We can discuss more details in the GitHub issue.

Related, we might note device calibration as another source of the device fingerprinting privacy risk in the Generic Sensor document:
https://github.com/w3c/sensors/issues/404 <https://github.com/w3c/sensors/issues/404>

Thanks,
Nick

> On Feb 12, 2020, at 3:57 PM, Kostiainen, Anssi <anssi.kostiainen@intel.com> wrote:
> 
> Hi Pete,
> 
> My short answer is: PRs welcome.
> 
> Please make sure there's a matching GH issue that clearly describes the problem the PR fixes. I think some of the relevant context might be in public-privacy ML archives currently, such as in this thread.
> 
> Thanks,
> 
> -Anssi (DAS WG co-chair)
> 
>> On 12. Feb 2020, at 21.59, Pete Snyder <psnyder@brave.com> wrote:
>> 
>> Wonderful and terrific! Double thanks again to Paul and Nick.
>> 
>> Anssi, it sounds like there is now a good solution for how to have a concise, robust, easy to implement solution to the privacy harm.  Whats the next step to get this added as part of the algorithms in the spec?  I (and im sure others on this thread) would be happy to work with the WG to put a PR together, if thats helpful.
>> 
>> Pete
>> 
>>> On Feb 12, 2020, at 11:55 AM, Paul Jensen <pauljensen@google.com> wrote:
>>> 
>>> It's great that you came up with the same rounding thresholds!
>>> 
>>> Applying a similar mitigation to accelerometer data seems prudent.  I propose rounding accelerometer values to the nearest 0.1 m/s^2.
>>> Similar to the orientation and rotation mitigation, I chose 0.1 m/s^2 because:
>>> 1. I think this is sufficient accuracy for typical accelerometer use cases.  Use cases I considered:
>>> a. For applications involving hand movement, my testing indicated accelerometer accuracy at this level was noise when holding a phone in hand.
>>> b. For pedometer applications, 0.1 m/s^2 accuracy should be sufficient as walking step detection requires an order of magnitude more minimum measurement. [0]
>>> c. For things like automobile 0-60mph measurement, 0.1 m/s^2 accuracy should be sufficient as the slowest acceleration is nearly an order of magnitude more. [1]
>>> 2. I think 0.1 m/s^2 should be larger than most sensor quantization step sizes, and near enough to low resolution sensor quantization step sizes that contributions from the other axis' sensors for calibration purposes are undetectable. [2]
>>> 
>>> [0]
>>> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4030415/
>>> "walking (including stair climbing and fidgeting of the feet while standing) when the SMA was between 0.135 g and 0.8 g"
>>> 0.135g = 1.32 m/s^2
>>> [1]
>>> 60mph = 26.8 m/s.
>>> Slowest car (https://www.zeroto60times.com/slowest-cars-0-60-mph-times/) takes 30s, which is 0.89 m/s^2.
>>> [2]
>>> Common discrete accelerometers:
>>> https://www.st.com/en/mems-and-sensors/accelerometers.html
>>> https://www.analog.com/en/parametricsearch/11175
>>> Someone looked at accelerometer ranges on some common phones:
>>> https://stackoverflow.com/questions/12739143/android-accelerometer-max-values/19981219#19981219
>>> These accelerometer ranges seem reasonable compared to those of "common discrete accelerometers" linked above.
>>> So the biggest range, -4g to +4g is 8g which is 78.5 m/s^2.
>>> Common accelerometers have resolutions from 8-bits to 16-bits.
>>> So a +/-4g 10-bit sensor would have a quantization step size of 0.077m/s^s.
>>> A +/-4g 8-bit sensor would have a quantization step size of 0.307m/s^s.
>>> 
>>> P.S. I'll miss next week's call as I'm on vacation.
>>> 
>>> On Thu, Jan 30, 2020 at 6:47 PM Nick Doty <npdoty@ischool.berkeley.edu> wrote:
>>> It looks like we separately came to the same conclusion on a recommended mitigation, down to suggesting the same threshold number of 0.1 degrees and 0.1 degrees per second. That is most encouraging!
>>> 
>>> (Paul, I pasted in the current text of your github proposal below, just for the ease of those reading through these email archives.)
>>> 
>>> It sounds like the Chromium proposal also included some evaluation that in fact these numbers are common, and that this would work for the typical sensor, not just the sensors evaluated in the paper. If that’s right, 1) thank you! and 2) that should give us more confidence in the general success of this mitigation and that browser implementation can be effective even when deployed on a variety of hardware.
>>> 
>>> Finally, in double-checking the paper and the sensors covered, it also sounds like there is a threat of calibration fingerprinting on *accelerometer* data (although that particular piece of research didn’t evaluate the exact precision of that fingerprinting for Pixel 2 and Pixel 3 phones, just that it appeared to be possible with those devices), which is separate from orientation and rotation rate, but is included in the DeviceMotion event. The Accelerometer API (which extends the Generic Sensor API) also provides access to that data; its security & privacy section notes the possibility of decreasing frequency for mitigating some privacy threats, but I’m not sure that would be effective for calibration fingerprinting. 
>>> 
>>> 1. should we apply the same class of mitigation to reported accelerometer data?
>>> 2. can we determine the typical sensor gain in order to come up with a threshold?
>>> 
>>> Thanks,
>>> Nick