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

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](https://w3c.github.io/sensors/#permissioning). 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."

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

Received on Thursday, 9 March 2017 23:24:38 UTC