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

Hi Pete & PING,

On 24 Oct 2019, at 23.38, Pete Snyder <psnyder@brave.com<mailto:psnyder@brave.com>> wrote:

Hi Anssi,

We briefly discussed the state of the Sensor API specs during our PING call this morning.  We had a couple of concerns.

Thank you for reviewing the Sensor API specs and for going beyond what was expected in terms of the wide review scope.

I've responded to the issues (links below) with further context and encourage the DAS WG participants to chime in and fill me in as needed.

As a summary, the concerns raised in these three issues have been acknowledged and discussed in the group in the past and they have already yielded in a number of changes to strengthen privacy protections defined in the specifications. I outlined details of these changes in my comments to the respective GitHub issues. We will revisit these issues to ensure the concerns are adequately addressed.

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.

https://github.com/w3c/sensors/issues/396


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.

https://github.com/w3c/sensors/issues/397


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

https://github.com/w3c/deviceorientation/issues/85


(Note: Device Orientation Event spec is not in scope of this wide review, but we of course welcome any feedback on it nevertheless.)

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,

-Anssi (DAS WG co-chair)

On Oct 21, 2019, at 2:09 PM, Kostiainen, Anssi <anssi.kostiainen@intel.com<mailto:anssi.kostiainen@intel.com>> wrote:


On 21. Oct 2019, at 22.40, Pete Snyder <psnyder@brave.com<mailto: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