Re: [sensors] Relax requirements for asking permissions in sensors

@tobie I think it's fair to say that you and I are in complete agreement.

In particular, I totally agree that the specification must require developers to go through the Permissions API. In terms of concrete changes, I think your suggested language change makes complete sense and gives browsers the flexibility to determine their privacy and security UI based on a host of factors.

The question of permission granularity is a very good one (should this be a different issue? Is there already one? Sorry I'm just ramping up on this...). Frankly I'm not qualified enough in either fused sensors or the Permissions API to provide much input as to the model so please don't take these views as authoritative but simply personal naive observations, but with that disclaimer aside here are a few passing thoughts on the subject:

1. I don't think browsers should expect to ask users on an individual basis to grant sites access to "accelerometer", "gyroscope" etc as most are likely not knowledgeable enough to be entirely sure what they are or what the risks are
2. Thus, from a purely user perspective I don't think there's any meaning in the distinction between the site accessing LinearAcceleration using a low pass-filter on the accelerometer vs one that uses a gyroscope to remove gravity
3. This distinction only exists insofar as the browsers understand risks such as fingerprinting associated with them
4. This brings me to agree with your point of grouping them as one permission called "motion-sensor", although from a pragmatic perspective I would be fine with a separate permissions API entry for each, since a browser can always treat a request for any one as a request for all and update their permission state consistently between all three.

Additionally, for Chrome at least, I can confidently state that we will consider every new sensor, or potentially risky update to one (e.g. increasing frequency, new input source, fusing data etc), as a new change to be reviewed for from a privacy and security perspective to determine whether we will need to permission it, or simply not support it.

Finally, on a pragmatic basis and taking LightSensor as an example, I fully expect the Blink implementation to apply frequency limiting, rounding, jitter etc as necessary to prevent developers from inferring what TV channel the user is watching, or fingerprint their device. I can imagine a world in which some developers would want access to higher accuracy data, but personally I'm not too motivated to worry much about this use case so only supporting a simple permission for the light sensor works fine for me (although again take my views with a large handful of salt as I am not deep in the sensor world)

-- 
GitHub Notification of comment by owencm
Please view or discuss this issue at https://github.com/w3c/sensors/issues/174#issuecomment-285581989 using your GitHub account

Received on Friday, 10 March 2017 05:28:51 UTC