From 1e0e2c907dd1047f953c93d793f0da2779715fa1 Mon Sep 17 00:00:00 2001 From: Raphael Kubo da Costa Date: Wed, 15 Dec 2021 17:00:14 +0100 Subject: [PATCH 1/2] Declare quantization and threshold check algorithms for extension to the spec. Related to w3c/ambient-light#63, which says the granularity of the data exposed by Ambient Light Sensors should be specified normatively. This commit goes a bit further and lays out some of the scaffolding necessary to specify the anti-fingerprinting measures currently implemented by Chrome -- namely, not only are illuminance values rounded but there's also a threshold value check to avoid storing values that are too close to the latest reading. The changes work as follows: * Concrete sensor types (i.e. extension specifications) may define a threshold check algorithm that compares two readings and returns whether they differ enough or not. * Concrete sensor types may define a reading quantization algorithm that is used to quantize readings returned by the "get value from latest reading" algorithm (which is used by attribute getters, for example). * Specifications may define one of the algorithms above, both, or none, but are encouraged to go with either none or both. --- index.bs | 40 +++++++++++++++++++++++++++++++++++++--- 1 file changed, 37 insertions(+), 3 deletions(-) diff --git a/index.bs b/index.bs index a9b97b3..9f16d78 100644 --- a/index.bs +++ b/index.bs @@ -512,6 +512,20 @@ might also help mitigate certain threats, thus user agents should not provide unnecessarily verbose readouts of sensors data. +Implementations of concrete sensors may define a [=threshold check algorithm=] +so that new readings that do not meet the [=reading change threshold=] when +compared to the [=latest readings=] are discarded. + +Implementations of concrete sensors may define a [=reading quantization +algorithm=] to reduce the accuracy of the [=sensor readings=] received from a +[=device sensor=]. + +Note: these two mitigation measures often complement each other. An +implementation that only executes the [=threshold check algorithm=] might +expose readings that are too precise, while an implementation that only rounds +readings up may provide attackers with information about more precise readings +when raw readings are rounded to different values. + Note: Inaccuracies will further increase for operations carried out on the [=sensor readings=], or time deltas calculated from the [=reading timestamp|timestamps=]. So, this mitigation strategy can affect certain use cases. @@ -803,11 +817,23 @@ A [=sensor type=] has a [=permission request algorithm=]. A [=sensor type=] has a [=set/is empty|nonempty=] [=ordered set|set=] of associated [=policy-controlled feature=] tokens referred to as sensor feature names. +A [=sensor type=] may have an associated threshold check +algorithm, which takes as arguments two separate [=sensor readings=] and +determines if the difference between them is higher than an +implementation-defined [=reading change threshold=]. + +A [=sensor type=] may have an associated reading quantization +algorithm, which takes a [=sensor reading=] and returns a less accurate +[=sensor reading=]. +

Sensor

-The current [=browsing context=]'s [=platform sensor=] has an associated [=ordered set|set=] -of activated sensor objects, which is initially [=set/is empty|empty=] and an -associated latest reading [=ordered map|map=], which holds the latest available [=sensor readings=]. +The current [=browsing context=]'s [=platform sensor=] must have: +- An associated [=ordered set|set=] of activated sensor objects, + which is initially [=set/is empty|empty=]; +- An associated latest reading [=ordered map|map=], which holds the + latest available [=sensor readings=]. +- An associated [=sensor type=]. Note: User agents can share the [=latest reading=] [=ordered map|map=] and the [=activated sensor objects=] [=ordered set|set=] between different @@ -1393,6 +1419,11 @@ to {{SensorErrorEventInit}}. : output :: None + 1. Let |type| be |sensor|'s associated [=sensor type=]. + 1. If |type|'s [=threshold check algorithm=] is defined, then: + 1. Let |result| be the result of invoking |type|'s [=threshold check algorithm=] + with |reading| and |latest reading|. + 1. If |result| is false, then abort these steps. 1. [=map/For each=] |key| → value of [=latest reading=]. 1. [=map/Set=] [=latest reading=][|key|] to the corresponding value of |reading|. @@ -1514,6 +1545,9 @@ to {{SensorErrorEventInit}}. 1. If |sensor_instance|.{{[[state]]}} is "activated", 1. Let |readings| be the [=latest reading=] of |sensor_instance|'s related [=platform sensor=]. + 1. Let |type| be |sensor_instance|'s associated [=platform sensor=]'s associated [=sensor type=]. + 1. If |type|'s [=reading quantization algorithm=] is defined, then: + 1. Set |readings| to the result of invoking |type|'s [=reading quantization algorithm=] with |readings|. 1. If the [=extension specification=] defines a [=local coordinate system=] for |sensor_instance|, 1. Remap (see [[COORDINATES-TRANSFORMATION]]) |readings| values to the [=local coordinate system=]. From d6f55ecb6902e61413bee76b5288672acaedcc7f Mon Sep 17 00:00:00 2001 From: Raphael Kubo da Costa Date: Fri, 27 May 2022 16:01:49 +0200 Subject: [PATCH 2/2] Remove mentions of "reading change threshold". ... And the accompanying "Reading change threshold" section. With the introduction of the "threshold check algorithm", this section is a bit simplistic and is no longer necessary, as it only covers thresholds provided by the device sensor or the operating system. --- index.bs | 29 ++++++++++------------------- 1 file changed, 10 insertions(+), 19 deletions(-) diff --git a/index.bs b/index.bs index 9f16d78..3406fe9 100644 --- a/index.bs +++ b/index.bs @@ -513,8 +513,8 @@ thus user agents should not provide unnecessarily verbose readouts of sensors data. Implementations of concrete sensors may define a [=threshold check algorithm=] -so that new readings that do not meet the [=reading change threshold=] when -compared to the [=latest readings=] are discarded. +so that new readings that do not differ enough from the [=latest readings=] are +discarded. Implementations of concrete sensors may define a [=reading quantization algorithm=] to reduce the accuracy of the [=sensor readings=] received from a @@ -725,19 +725,6 @@ define ways to uniquely identify each one. -## Reading change threshold ## {#concepts-reading-change-threshold} - -A [=platform sensor=] reports [=sensor readings|readings=] to the user agent considering -the [=reading change threshold=]. - -The reading change threshold refers to a value which indicates whether or -not the changes in the [=device sensor=]'s measurements were significant enough to -update the corresponding [=sensor readings=]. - -The [=reading change threshold|threshold=] value depends on the surrounding software and hardware -environment constraints, e.g., software power consumption optimizations or the underlying -[=device sensor=]'s accuracy. - ## Sampling Frequency and Reporting Frequency ## {#concepts-sampling-and-reporting-frequencies} For the purpose of this specification, sampling frequency for a [=platform sensor=] is @@ -753,8 +740,12 @@ can support it. The [=sampling frequency=] differs from the [=requested sampling frequency=] in the following cases: - the [=requested sampling frequency=] exceeds upper or lower [=sampling frequency=] bounds supported by the underlying platform. - - the [=reading change threshold|threshold=] value is significant so that some of the - [=device sensor=]'s measurements are skipped and the [=sensor readings=] are not updated. + - the operating system and/or the [=device sensor=] automatically discard + readings that do not differ enough (in absolute or relative terms) from the + previously reported ones via a hardware or operating system filter. + - the [=platform sensor=]'s associated [=sensor type=]'s [=threshold check + algorithm=] fails and the [=platform sensor=]'s [=latest readings=] are not + updated. The reporting frequency for a concrete {{Sensor}} object is defined as a frequency at which the "reading" event is [=fire an event|fired=] at this object. @@ -819,8 +810,8 @@ A [=sensor type=] has a [=set/is empty|nonempty=] [=ordered set|set=] of associa A [=sensor type=] may have an associated threshold check algorithm, which takes as arguments two separate [=sensor readings=] and -determines if the difference between them is higher than an -implementation-defined [=reading change threshold=]. +determines if they differ enough to cause a [=platform sensor=]'s [=latest +reading=] map to be updated. A [=sensor type=] may have an associated reading quantization algorithm, which takes a [=sensor reading=] and returns a less accurate