Relax requirements for asking permissions in sensors

[pozdnyakov]

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).

[tobie]

Does this take in account that we'll be providing uses cases that require polling frequencies greater than 60 Hz?

[tobie]

/cc @lknik @maryammjd

[tobie]

So after more consideration, I see two options here:

1. Hook into the permission system and always return "granted" as it seems the Permission spec let's you do (see user intent), or
2. Completely bypass the permission's API.

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 PermissionBasedSensor API inheriting from Sensor were there would be agreement that permissions were needed). This seems like an ineffective way to handle this.

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.

[maryammjd]

For high frequencies, Chrome's approach would definitely affect user security and privacy. I can see this conversation has been locked in a loop for a while now. I expect more issues will be reported from the security research community in the future.

[kenchris]

Wouldn't it makes sense to invite Owen (@owencm) to one of the DAP meetings to hear their reasoning and discuss further? It might be that we are talking by each other

[tobie]

Yup. I reached out a while back. Haven't heard back since and haven't had time to chase. 100% agree better communication would be helpful.

[owencm]

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

[anssiko]

Thanks! Reopening to make sure we reflect @owencm's feedback in the spec.

[tobie]

Thanks, @owencm, for dropping by. A couple of comments/questions inline:

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.

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.

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.

We're in full agreement, here.

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.

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.

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

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."

[owencm]

@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)

[lknik]

There will be both security and privacy issues in low and high frequencies regarding those sensors. It will be a risk.

[lknik]

I suggest to reassess our threat models?

https://blog.lukaszolejnik.com/stealing-sensitive-browser-data-with-the-w3c-ambient-light-sensor-api/