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.