Re: sensor calibration fingerprinting

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
>
> On Jan 15, 2020, at 1:24 PM, Paul Jensen <pauljensen@google.com> wrote:
>
> Here's our proposal for what to do in Chromium:
> https://github.com/JensenPaul/sensor-fingerprint-mitigation
>
>
> Device Orientation and Rotation Sensor Calibration Fingerprint Mitigation
>
> Background
>
> Most mobile phones contain device orientation sensors that attempt
> to measure the phone’s orientation and rotation around the three
> spatial axes.  These sensors undergo a factory calibration to ensure
> their accuracy. At present on many devices, each individual device’s
> chosen calibration values can be inferred from a sequence of sensor
> readings.  These calibration values are fairly identifying. This
> paper found the device orientation sensor calibration values for the
> iPhone 6S to offer roughly 42 bits of entropy, more than enough to
> distinctly identify everyone uniquely.  This represents a privacy concern
> for mobile phone users browsing the web as the device orientation
> sensor readings are available to all web sites without a permission prompt,
> and cannot be cleared, reset or modified so the user cannot control
> what sites track them or for how long.
>
> Proposed Mitigation
>
> Fingerprinting the sensor calibration relies on being able to infer values
> in the gain matrix that were set during factory calibration.  This
> requires analysis of the sensor readings with a level of
> precision significantly beyond sensor quantization step size so that the
> gain matrix’s contributions to the sensor readings can be inferred.
> The DeviceOrientation Event Specification returns the device orientation on
> each axis as a 64-bit double floating point value representing degrees.  To
> mitigate performing this attack using readings that can be collected in a
> reasonable amount of time, we’re proposing rounding the sensor readings to
> the nearest tenth of a degree.  A tenth of a degree represents two
> things: First, it’s generally larger than the typical device orientation
> sensor quantization step size so it should mitigate inferring the gain
> matrix.  Second, it’s small enough that Web sites using the device
> orientation API should not be impacted by the rounding. Experimentation
> indicated that for human hand and head motion, a tenth of a degree level of
> precision is mostly noise.  Measuring head and hand motion should cover the
> known use cases these sensors support, including WebVR and game input. Use
> of a fixed value (i.e. 0.1 degrees) has the benefit that it’s not
> sensor dependent so it can be applied universally; this paper recommended
> rounding to the nearest multiple of the sensor’s nominal gain which
> requires knowledge of a device’s specific sensor.  The mitigation proposed
> here can be applied in the Web browser app which can be updated more easily
> and in a more timely manner compared to the mobile operating system.  This
> isn’t to say this fingerprinting method shouldn’t be mitigated at the
> operating system level as well.
>
> For APIs that return device orientation in other units
> (e.g. OrientationSensor and Gyroscope), we’re proposing rounding them to
> equivalent amounts (e.g. to the nearest multiple of 0.00174533 radians,
> which is roughly equivalent to a tenth of a degree).
>
> Similar to the device orientation sensor outputs, for the device rotation
> sensor outputs, we’re proposing rounding them to the nearest tenth of a
> degree per second.  Similar experimentation indicated that this level of
> precision is mostly noise for human hand and head motion, so it shouldn’t
> degrade Web site experiences, and is generally larger than the typical
> device orientation sensor quantization step size so it should mitigate
> inferring the gain matrix.
>
>
> On Mon, Jan 13, 2020 at 5:39 PM Nick Doty <npdoty@ischool.berkeley.edu>
> wrote:
>
>> Regarding DeviceOrientation and research showing persistent
>> fingerprintability based on factory calibration of orientation sensors in
>> mobile devices; I’ll add some notes to the GitHub issue here [0], but since
>> it might be worth longer discussion in PING, especially for how it applies
>> to other sensors, I’m writing out these comments for the mailing list.
>>
>> From my reading of the paper [1], the authors suggest two mitigations
>> that they seem to identify as resolving the issue altogether:
>>
>> 1. adding random noise of -0.5-to-0.5 to each value and then rounding to
>> the resolution of the sensor (16 bits, in the case of the iOS devices in
>> question)
>> 2. rounding the output to the nearest multiple of the nominal gain of the
>> sensor (61 or 70 millidegrees per second, in the case of the iOS devices in
>> question)
>>
>> Those mitigations do seem to be hardware specific, so we might not be
>> able to include hard numbers in the spec, but could still provide a
>> normative indication that sensors should be rounded using the provided
>> algorithm, based on their hardware details. If nominal sensor gain and
>> sensor resolution are known for each device (*and* accessible to the
>> browser from the underlying operating system), then those mitigation
>> algorithms could be implemented by all browser implementers.
>>
>> I’m not entirely clear on this yet, but it also seems possible that we
>> could do a survey of the accelerometers and gyroscopes currently in use by
>> most mobile devices and then require no more precision than slightly below
>> the typical or lowest precision sensor in the survey. Would that be a huge
>> detriment to functionality? I’m not sure, but if I’m reading it correctly
>> that the iOS devices measure a range of 4000 degrees per second with a
>> resolution (and nominal gain) of 0.061, then we’d be talking about an extra
>> error of 0.1 / 4000 = 0.0025%. That certainly sounds small, though I’m sure
>> it depends on the particular use cases.
>>
>> We might also chat with Apple folks about the mitigations that they
>> implemented in response to the paper; it sounds like they added noise
>> before rounding and deployed that for native iOS devices. Did that cause
>> functionality problems for iOS apps? Was the implementation different for
>> every hardware version?
>>
>> This is all based on my non-expert reading of the “SensorID" paper, so
>> I’d welcome more ideas from implementers or those more familiar with
>> gyroscope/accelerometer sensors. I believe there will be some discussion of
>> that at this week’s PING call (with regrets, I won’t be able to join, but
>> will read the minutes).
>>
>> Because the authors demonstrated an in-the-wild risk of permanent (across
>> factory reset of the device even) identifiers, there are good reasons for
>> implementers and spec maintainers to try to implement short-term fixes, and
>> some have over the past year in response to previous research (like
>> permission gating). But the paper also suggests — and this is something I
>> would really value input on from others — that other device sensors are
>> likely to have similar risks of persistent cross-origin identification,
>> based on being able to detect factory calibrations from a relatively small
>> sample of readings. If we can understand what causes that risk, how to
>> identify it and how to mitigate it, we can provide more specific guidance
>> (in the fingerprinting guidance doc, or perhaps the threat model) and apply
>> it to all new sensor specs that come up for review.
>>
>> Cheers,
>> Nick
>>
>> [0] https://github.com/w3c/deviceorientation/issues/85
>> There’s also some related discussion in
>> https://github.com/w3c/deviceorientation/issues/57 although that thread
>> goes a little off-topic, so it’s not the easiest to follow.
>>
>> [1] https://www.ieee-security.org/TC/SP2019/papers/405.pdf
>> Zhang, Jiexin, Alastair R. Beresford, and Ian Sheret. “SensorID: Sensor
>> Calibration Fingerprinting for Smartphones.” In 2019 IEEE Symposium on
>> Security and Privacy (SP), 638–55. San Francisco, CA, USA: IEEE, 2019.
>> https://doi.org/10.1109/SP.2019.00072.
>>
>>
>>
>>
>> Previously discussed on public-privacy here:
>>
>> > On Oct 24, 2019, at 4:38 PM, Pete Snyder <psnyder@brave.com> wrote:
>> >
>> > 3. I double checked with the authors of the paper I linked to, and they
>> say that the functionality they use to fingerprint devices (quote: “the
>> DeviceMotionEvent APIs, particularly DeviceMotionEvent.acceleration and
>> DeviceMotionEvent.rotationRate”) don’t require permissions to access.  The
>> standard needs to be updated so that users cannot be passively
>> fingerpritined.
>> >
>> > Also re the findings: the findings were that devices with high quality
>> accelerometers are vulnerable.  The Pixel and iPhone devices they tested
>> were all vulnerable; the other android devices they tested just had lower
>> quality sensors.  As the avg quality of phones increase, more and more
>> devices will be vulnerable then.  So its still an active harm / concern.
>> >
>> > I’ll open up issues for 1-3 in the repo now.
>> >
>> > Thanks,
>> > Pete
>> >
>> >> On Oct 21, 2019, at 2:09 PM, Kostiainen, Anssi <
>> anssi.kostiainen@intel.com> wrote:
>> >>
>> >>
>> >>> On 21. Oct 2019, at 22.40, Pete Snyder <psnyder@brave.com> wrote:
>> >>>
>> >>> In the meantime though, was wondering if your group was familiar with
>> this work [1] on using sensor APIs for permission less fingerprinting, if
>> the standard has been updated to fix / prevent these attacks, and if not,
>> how the standard should be adopted to fix.  (TL;DR; you can derive devices
>> w/ ~67 bit identifiers if they have accelerometers installed, using the
>> sensor APIs).
>> >>
>> >> Thanks for the pointer.
>> >>
>> >> This paper published after the specs reached CR has not been discussed
>> in the group. Other similar fingerprinting vectors brought to the group’s
>> attention have been considered, however:
>> >>
>> >> https://w3c.github.io/sensors/#device-fingerprinting
>> >>
>> >> We could add this paper to the list of references for completeness.
>> >>
>> >> Mitigations are discussed in:
>> >>
>> >> https://w3c.github.io/sensors/#mitigation-strategies
>> >>
>> >> We could consider adding the other proposed mitigation (add uniformly
>> distributed random noise to ADC outputs before calibration is applied) to
>> the mitigations section. Permissions is already covered and the specs
>> define hooks for prompting.
>> >>
>> >> As a general comment, it *seems* this particular attack was fixed in
>> more recent iOS versions and on most or all(?) Android devices tested there
>> was less entropy, so no global uniqueness.
>> >>
>> >> Suggestions (and PRs) from PING welcome.
>> >>
>> >> Thanks,
>> >>
>> >> -Anssi
>> >>
>> >>
>> >>> Refs:
>> >>> 1:
>> https://www.repository.cam.ac.uk/bitstream/handle/1810/294227/405.pdf?sequence=3
>>
>>
>