Join GitHub today
Relax requirements for asking permissions in sensors #174
Google Chrome team proposes not to introduce permissions at least for ALS, Gyroscope, Magnetometer and Accelerometer.
The rational: "Discussion of past issues discovered in Blink’s Device Orientation and Motion APIs is here, we believe they are all addressed by the above mitigations".
I think the Generic Sensor specification could be updated so that it does not say permissions "must" be obtained, and instead leaves it for UA to decide (s/must/may).
referenced this issue
Mar 8, 2017
referenced this issue
Mar 8, 2017
So after more consideration, I see two options here:
If it's option 1, you're already good to go. You'll still need to spec and implement as if there were permissions, define a permission name, etc., but permission will be always "granted" by default on Chrome (whether always granting is a good idea or not is another discussion that might be worth having on Chromium's tracker). Option 1 has the added benefit of allowing different vendors to adjust their permission settings for sensors. Given the documented privacy and security issues of exposing sensors to the Web, this is the right thing to do.
Option 2 is a no go as it would create interop issues should another vendor decide to require permission where Chrome decided it doesn't need to. The only way this could work would be to get all vendors to agree upfront about this for a given set of sensors (and create a
Given the above, I'll close this. Feel free to reopen if you can get all vendors on the same page here or if there's another solution to this problem that I haven't thought about.
Thanks for filing this!
From a practical perspective, if there are extensions to the permissions API for each individual sensor then browsers can implement and decide to mark as granted if we feel that specific sensor doesn't warrant a permission. That way we have good interop between browsers that choose to permission, or not, these sensors.
If a sensor is introduced in the future that a browser decides to permission, we can also do it for that one specifically which is nice.
For example, if a sensor is introduced that creates a fingerprinting risk and no mitigations are available we may then choose to expose it only with a permission.
My take away here is that some browsers may choose to expose some subset of the sensors possible without permissioning, for example the accelerometer and gyroscope and as note that these are already exposed via DeviceOrientation events.
For that reason I think it would be better for the spec to say that browsers may require user permission for any sensors they wish and developers must always request permission before using one
Thanks, @owencm, for dropping by. A couple of comments/questions inline:
Yes. Agreed. We discussed this a while back already and that's baked into the spec. There are ongoing conversations around how coarse-grained these permission names need to be.
A concrete example of this is motion sensors. For context, there are (generally) three hardware sensors on a mobile device: gyroscope, accelerometer, and magnetometer. The two former have similar security and privacy issues, the latter's less of a risk. But all three get combined in various ways in fused sensors we're also planning to expose.
What's the best level of coarseness here?
If you go for fine-grained solutions, you quickly end-up having to answer hard questions. For example, if you've obtained access the accelerometer, will that give you also access to LinearAcceleration on a device that uses a low pass-filter on the accelerometer but not on one that uses a gyroscope to remove gravity? Or would you require a new permission for fused sensors despite it being just the combination of the gyroscope, accelerometer, and magnetometer?
In my opinion, anything but to combine these three under a "motion-sensor" denomination is cause for a lot of trouble for very little gain.
The same answer might be different for say ambient light, where a LightLevel sensor that would give extremely coarse values (e.g. an enum with "dim", "normal" and "washed" values) probably wants to be given a different permission name than the ambient-sensor who provides data that can be used to infer what TV channel the user is watching, or fingerprint their device.
Going back to motion sensors, a pedometer, despite being built using the three motion sensors, probably deserves its own permission name.
So while the generic sensor spec can provide direction for what concrete specs specify, a lot needs to happen on a case per case basis.
If you have thoughts on a framework we could use to help determine the degree of coarseness, I think that would be useful and I'd love to add it in the extensibility section of the spec.
We're in full agreement, here.
So I agree on the first part of this last comment (see my example above on ambient-light vs. light-level), but I disagree with your comment regarding keeping accelerometer and gyroscope open because of DeviceOrientation events.
First of all, we're looking at supporting much higher frequencies on these sensors than DeviceOrientation events allows. Secondly, we're restricting these sensors to secure context, which afaik DeviceOrientation isn't, so there's a lack of consistency in this reasoning which I find troubling. By the same token, should we also remove the [SecureContext] extended attribute?
Instead, I argue that we should jump on the occasion to increase the overall privacy and security of the platform. Better and more performant APIs have proven to be an excellent carrot to move developers to use secure origins. Consider for example the successful deprecation of AppCache on insecure origins we've seen recently. I don't see why we couldn't use the same kind of strategy to move APIs behind permissions. I certainly hope we'll have similar phasing of the DeviceOrientation event as we've had for AppCache once ServiceWorkers were launched. My ideal goal here would be to end up with the modern APIs behind permissions on secure origins only, and get completely rid of DeviceOrientation event, or if that's really not possible, keep it around with strongly reduced polling frequencies, perhaps on secure origins only.
As mentioned in one of my earlier comments on this thread and I think as you seem to agree in your comment, we can't bypass the permission spec's abstract operations if we want to be interoperable across vendors who decide to grant permissions by default or put them behind a prompt.
With that in mind, I assume that the only thing you're requiring is to tone down the language of § 5.3. Obtaining Explicit User Permission. Would changing the title to just "Permission" and appending something along the following suit your needs: "…. As described in the permission spec, user agents may use a number of criteria to grant permission, including automatically granting the permission in full without prompting the user."
@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:
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)
referenced this issue
Mar 10, 2017
referenced this issue
Apr 3, 2017
I suggest to reassess our threat models?