Re: RfC: wide review of WebDriver extensions for Sensor APIs

Hi Anssi,

We briefly discussed the state of the Sensor API specs during our PING call this morning.  We had a couple of concerns.  I’ll mention them briefly below, and open up issues against the spec too:

1. The spec makes the unexpected statement that permission-protected functionality does not require explicit user permission to grant.  This is a pretty heavy deviation from how permissions are dealt with elsewhere in specs.  If the web platform is going to move to a model of “inferred permissions” (with “how to infer” tbd), it would be much better to address that in the Permissions spec, or some other central location.  

2. While the spec does a great job discussing the risks associated with the exposed functionality, there is relatively little in the way of required mitigations. We think its bad practice to have standards require privacy risky functionality, but then leave it up to implementors to figure out non-standard ways of protecting users; the protections are just as much a part of the web platform as the functionality.  The spec should be updated / modified to specify the steps implementors must take to keep their users safe from the risk the standard adds.

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

Received on Thursday, 24 October 2019 20:38:33 UTC