Relation to Permissions API

[reillyeon]

Discussions of the privacy considerations of this API have floated the idea of a low-resolution mode which does not require a permission, and a high-resolution mode that does. While the definition of low and high resolution should be left to the User Agent there should be a well defined interface for determining whether the user has granted permission for high-resolution mode. This can be done through the Permissions API.

[reillyeon]

@riju

[riju]

{Low,High}-Resolution mode has 2 facets:

1. Accuracy of sensor readings (rounding)
2. Frequency

Without Permission the user gets ->

• "Lower" accuracy sensor readings (readings rounded in a "big" way).
  e.g. ALS may be rounded to the nearest 50 lux, making it in a way comparable to CSS light-level.
• "Lower" frequency as determined by UA to be comfortably safe to mitigate any known threats.
  For example:
  ALS : 0.5 Hz.

With Permission the user gets ->

• "Higher" accuracy sensor readings (readings may be rounded in a "small" way).
  ALS rounded to say 10 lux, or just to the nearest decimal point.
  Spec may add a note that UA may still do a bit of rounding although it's gated behind Permissions to minimize fingerprinting.
• "Higher" frequency as determined by UA.
  For example:
  ALS : 4 Hz.

Argument: If it is already behind permissions why still clip data or frequency?
Users(advanced) may still be not aware of the threat models.
vs
I know what I am doing !

(numbers are just for illustration purposes, UA needs to set its threshold after "user-studies" , as is the case with rounding factor, UA defines its own "big" and "small").

Edit: We need some more research to come up with any numbers for Accelerometer, Gyroscope and Magnetometer.

Papers:
Pin skimming with ALS: https://arxiv.org/pdf/1405.3760.pdf

[pozdnyakov]

We (me and @alexshalamov) have a concern that introducing of low(high)-resolution mode will be quite confusing for web developers who will not know exactly which permission token is required for the functionality they intend to provide. Moreover, definition of high / low thresholds by the UA, would lead to fragmentation between browsers.

Also for motion sensor we can hardly find a ‘safe’ zone for both frequency or accuracy (#98 (comment) ), search papers [ ALS, Motion sensors, Gyro ] tell that there can be vulnerabilities even at low frequencies.

For ALS we do not really have the use cases requiring accurate readings (@tobie do we?), even rough data (10 - 100 lux accuracy) shall be enough for example for updating a web page style based on the surrounding illumination.

We believe that for any sensor type the returned data can be rounded to the values which are good enough to implement the use cases, if it improves user’s security/privacy (this UA can decide), but there is no actual need for introducing any extra modes and permission tokens.

[tobie]

For ALS we do not really have the use cases requiring accurate readings (@tobie do we?), even rough data (10 - 100 lux accuracy) shall be enough for example for updating a web page style based on the surrounding illumination.

I don't really have an opinion, here. My involvement with ALS has been limited to rewriting the existing spec to rely on the generic sensor API instead. As far as I'm concerned, all the use cases I've seen don't require more than an light-level inspired enum. Maybe we should drop ALS for now (that is, until we find more conclusive evidence of its need) an release an enum-based, mediaquery-matching LightLevelSensor instead.

[tobie]

WRT to resolution mode, for ALS the situation seems easier to handle; it's ALS vs LightLevelSensor. We could go with just exposing the second one for now, with a dedicated permission descriptor. Then if we find legit use cases for ALS, figure out how to make those descriptors work together.

[anssiko]

Couple of options. I'm hearing preference toward option 2. What is your preference?

(The names are just placeholders, no need to bikeshed.)

1) Add lightLevel to the existing AmbientLightSensor.

Low-resolution mode:

• Grant access by default.
• Cap the polling frequency so that it mitigates the known attacks satisfactorily.
• Set illuminance to some fixed default value (null?), or round it very aggressively, again, to mitigate the known attacks. Default value or rounding? Use cases?

High-resolution mode:

• Require more explicit user permission.
• Do not cap the polling frequency as aggressively.
• Report also the illuminance readings with higher granularity.

enum LightLevel = { "dim", "normal", "washed" }; // [1]

[Constructor(optional SensorOptions sensorOptions)]
interface AmbientLightSensor : Sensor {
  readonly attribute unrestricted double? illuminance; // high-resolution mode, null? otherwise
  readonly attribute LightLevel lightLevel;
};

2) Dedicated constructors: AmbientLightSensor for illuminance and LightLevelSensor for lightLevel.

Low-resolution mode:

• As above, but with its own constructor:

enum LightLevel = { "dim", "normal", "washed" };

[Constructor(optional SensorOptions sensorOptions)]
interface LightLevelSensor : Sensor {
  readonly attribute LightLevel lightLevel;
};

High-resolution mode:

• As above, but with its own constructor:

[Constructor(optional SensorOptions sensorOptions)]
interface AmbientLightSensor : Sensor {
  readonly attribute unrestricted double illuminance;
};

3. Something else.

[1] LightLevel enum values lifted from now obsoleted https://www.w3.org/TR/2016/WD-mediaqueries-4-20160126/#descdef-media-light-level

[tobie]

[1] LightLevel enum values lifted from now obsoleted https://www.w3.org/TR/2016/WD-mediaqueries-4-20160126/#descdef-media-light-level

LightLevel hasn't been obsoleted, it's been moved to MQ5: https://github.com/w3c/csswg-drafts/blob/master/mediaqueries/deferred-for-level-5.txt

Nonetheless, liaising with the CSS WG would be important before moving ahead with this.

[tobie]

I've explained my position about this issue here: w3c/ambient-light#23 (comment)

And in particular:

For ALS, I agree we don't seem to have use cases that require anything beyond the granularity of the CSS Light Level API. […]

That said, we have such use cases for sensors beyond ALS, notably motion sensors. The use cases for motion sensors require high precision and high frequency (120Hz and beyond). Furthermore, as the data is often integrated, mitigating privacy concerns by adding noise to the data samples (or even to their timestamps) isn't really an option as its effect would be exponential.

Hence we have to solve this issue for motion sensors. Once we do, we might find this solution applies just as well to ALS, or instead ditch ALS altogether for now in favor of a mediaquery-inspired LightLevelSensor.

In short: we need to find an acceptable solution for motion sensors. If we don't the whole exercise is moot (we'll basically have failed). If we do, we can probably use that solution as is on ALS.

In the meantime, we may attempt to move forward with LightLevel instead, but if we do this will imply liaising with the CSS WG. This might considerably delay us.

I recommend:

1. putting ALS on the back-burner.
2. attempting to solve permission issues for motion sensors.
3. then only figuring out whether to revive ALS, switch to LLS, or do both in parallel.

[anssiko]

Sorry for spamming this issue with ambient-light specifics in #183 (comment) -- my bad, I thought this was the ALS repo :-/

Let's continue the ALS specific discussion over in w3c/ambient-light#23 where the context is.

[raymeskhoury]

We (me and @alexshalamov) have a concern that introducing of low(high)-resolution mode will be quite confusing for web developers who will not know exactly which permission token is required for the functionality they intend to provide. Moreover, definition of high / low thresholds by the UA, would lead to fragmentation between browsers.

Also for motion sensor we can hardly find a ‘safe’ zone for both frequency or accuracy (#98 (comment) ), search papers [ ALS, Motion sensors, Gyro ] tell that there can be vulnerabilities even at low frequencies.

For ALS we do not really have the use cases requiring accurate readings (@tobie do we?), even rough data (10 - 100 lux accuracy) shall be enough for example for updating a web page style based on the surrounding illumination.

We believe that for any sensor type the returned data can be rounded to the values which are good enough to implement the use cases, if it improves user’s security/privacy (this UA can decide), but there is no actual need for introducing any extra modes and permission tokens.

From a permissions standpoint I agree with the sentiment above. I would much rather avoid having low/high precision modes if we can avoid it. It's complicated for developers and for user agents and I'm not convinced of the value of it (e.g. that it enables additional use cases or provides better security/privacy).

[anssiko]

Revisiting this issue after some thought, I now feel the low/high precision mode and related machinery should not be exposed to the web developer direct. I'm not yet sure whether allowing some implementers to toggle such a mode as a side-effect of a permission state would be a smart thing to do or whether that would in fact lead to interoperability issues across implementations.

@reillyeon you said:

there should be a well defined interface for determining whether the user has granted permission for high-resolution mode

Did you mean the granted permission state could be taken as a hint for high precision, or that an explicit extension to the permission descriptor à la the enableHighAccuracy flag of the Geolocation API should be added? If the latter, I'd like to understand how well that has worked in real life for geo and what the web developer feedback has been to date. My recollection is there has been issues with it, but I don't have a pointer at hand to backup my claim.

[tobie]

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.

[pozdnyakov]

So far it was agreed to proceed with the implementation without low/high precision modes. Moving this issue to level 2.