W3C home > Mailing lists > Public > public-device-apis-log@w3.org > May 2017

Re: [sensors] Relation to Permissions API

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 May 2017 08:21:27 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-299803630-1494231686-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:54 UTC