From 91a2c9225e6f8cbe4999b118ef9f1d761463acc3 Mon Sep 17 00:00:00 2001
From: Raphael Kubo da Costa <raphael.kubo.da.costa@intel.com>
Date: Wed, 15 Dec 2021 17:00:14 +0100
Subject: [PATCH] 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 <dfn export>sensor feature names</dfn>.
 
+A [=sensor type=] may have an associated <dfn export>threshold check
+algorithm</dfn>, 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 <dfn export>reading quantization
+algorithm</dfn>, which takes a [=sensor reading=] and returns a less accurate
+[=sensor reading=].
+
 <h3 id="model-sensor">Sensor</h3>
 
-The current [=browsing context=]'s [=platform sensor=] has an associated [=ordered set|set=]
-of <dfn>activated sensor objects</dfn>, which is initially [=set/is empty|empty=] and an
-associated <dfn>latest reading</dfn> [=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 <dfn>activated sensor objects</dfn>,
+  which is initially [=set/is empty|empty=];
+- An associated <dfn>latest reading</dfn> [=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| → <var ignore>value</var> 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=].