Re: [sensors] Relation to Permissions API

So you have three different cases here:

1. **Reducing accuracy and/or polling frequency reduces threats without impeding use cases.** In this case, there's no reason to offer permission two states, just reduce the threat.
2. **Reducing accuracy and/or polling frequency reduces threats and impedes a number of use cases but still meet the requirements of others.** For example, this might be the case with the ambient light use cases. Some of those require 10 Lux accuracy, others would do with CSS LightLevel mediaquery three value enum. In this case, it might be worth looking a introducing explicit permission descriptor members (or just different permission names, e.g.: `light-level` vs `ambient-light-sensor`).
3. **Reducing accuracy and/or polling frequency reduces threats but impedes most significant use cases.** It might not be worth offering both options here.

Additionally, for this to be effective, you have to incentivize developers to pick the more secure option when they don't require more precision, e.g. by making the permission opt-out vs. opt-in. This implies that the threat level difference between high and low precision must be important enough to warrant this difference in treatment. Developer incentive was completely missing out of the geolocation `enableHighAccuracy` setting, which is why it's not a good parallel to this issue (and why it mostly failed to work). The name also didn't help, would the setting have been called `enableSaveBatteryMode`, I'm sure we'd be looking at different numbers. Naming is important.

Agree with @anssiko that making the precision distinction isn't necessarily something that should be exposed as is to the end-user. As mentioned above, this could be also done in certain cases with different permission names, high-level vs. low level sensor types (e.g. pedometer vs. access to low-level motion sensors), or UA level distinction (e.g. opt-in vs. opt-out permissions; available across the web vs. only available on installed PWAs).

Finally, while this is something that probably needs to be defined at the generic sensor level, whether it's useful to a given concrete sensor needs to be defined at the concrete sensor level.

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

Received on Monday, 8 May 2017 08:21:34 UTC