Skip to content

Commit 0ee4037

Browse files
author
Raphael Kubo da Costa
committed
editorial: Add reading quantization and threshold check algorithms.
Related to #63, which says the granularity of the data exposed by Ambient Light Sensors should be specified normatively. This commit goes a bit further and specifies the two 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. w3c/sensors#429 defines the concepts of "reading quantization algorithm" and "threshold check algorithm" that concrete sensors can specify. We specify both here, along with some values used by them (based on the current Chromium values): - An "illuminance rounding multiple" of at least 50lx. - An "illuminance threshold value" of at least 25lx (half the illuminance roundig multiple, to be more precise). These values are then used in the following algorithms: - The "threshold check algorithm" checks that the difference between new and current illuminance values is above the illuminance threshold value. - The "reading quantization algorithm" rounds up readings to the closest multiple of the illuminance rounding multiple.
1 parent 632fa60 commit 0ee4037

File tree

1 file changed

+157
-4
lines changed

1 file changed

+157
-4
lines changed

index.bs

Lines changed: 157 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,54 @@ urlPrefix: https://w3c.github.io/sensors/; spec: GENERIC-SENSOR
4949
text: mock sensor type
5050
text: MockSensorType
5151
text: mock sensor reading values
52+
text: threshold check algorithm
53+
text: reading quantization algorithm
54+
text: latest reading
55+
urlPrefix: https://tc39.es/ecma262/; spec: ECMA-262
56+
type: abstract-op
57+
text: abs; url: eqn-abs
58+
</pre>
59+
60+
<pre class=biblio>
61+
{
62+
"ALSPRIVACYANALYSIS": {
63+
"title": "Privacy analysis of Ambient Light Sensors",
64+
"authors": [
65+
"Lukasz Olejnik"
66+
],
67+
"href": "https://blog.lukaszolejnik.com/privacy-of-ambient-light-sensors/",
68+
"id": "ALSPRIVACYANALYSIS",
69+
"date": "31 August 2016"
70+
},
71+
"PINSKIMMINGVIASENSOR": {
72+
"title": "PIN Skimming: Exploiting the Ambient-Light Sensor in Mobile Devices",
73+
"authors": [
74+
"Raphael Spreitzer"
75+
],
76+
"href": "https://arxiv.org/abs/1405.3760",
77+
"id": "PINSKIMMINGVIASENSOR",
78+
"date": "15 May 2014"
79+
},
80+
"STEALINGSENSITIVEDATA": {
81+
"title": "Stealing sensitive browser data with the W3C Ambient Light Sensor API",
82+
"authors": [
83+
"Lukasz Olejnik"
84+
],
85+
"href": "https://blog.lukaszolejnik.com/stealing-sensitive-browser-data-with-the-w3c-ambient-light-sensor-api/",
86+
"id": "STEALINGSENSITIVEDATA",
87+
"date": "19 April 2017"
88+
},
89+
"VIDEORECOGNITIONAMBIENTLIGHT": {
90+
"title": "Video recognition using ambient light sensors",
91+
"authors": [
92+
"Raphael Spreitzer"
93+
],
94+
"href": "https://doi.org/10.1109/PERCOM.2016.7456511",
95+
"id": "VIDEORECOGNITIONAMBIENTLIGHT",
96+
"publisher": "IEEE",
97+
"date": "21 April 2016"
98+
}
99+
}
52100
</pre>
53101

54102
Introduction {#intro}
@@ -185,14 +233,56 @@ the device environment. Potential privacy risks include:
185233
the light levels associated with visited and unvisited links i.e. visited
186234
links styled as a block of black screen; white for unvisited.
187235

188-
To mitigate these Ambient Light Sensor specific threats, user agents should
189-
use one or both of the following mitigation strategies:
190-
- <a>limit maximum sampling frequency</a>
191-
- <a>reduce accuracy</a> of sensor readings
236+
Works such as [[ALSPRIVACYANALYSIS]], [[PINSKIMMINGVIASENSOR]],
237+
[[STEALINGSENSITIVEDATA]], and [[VIDEORECOGNITIONAMBIENTLIGHT]] delve further
238+
into these issues.
239+
240+
To mitigate these threats specific to Ambient Light Sensor, user agents must
241+
<a>reduce accuracy</a> of sensor readings. User agents may also <a>limit
242+
maximum sampling frequency</a>.
192243

193244
These mitigation strategies complement the [=mitigation strategies|generic mitigations=]
194245
defined in the Generic Sensor API [[!GENERIC-SENSOR]].
195246

247+
Reducing sensor readings accuracy {#reduce-sensor-accuracy}
248+
-----
249+
250+
In order to [=reduce accuracy=] of sensor readings, this specification defines
251+
a [=threshold check algorithm=] (the [=ambient light threshold check
252+
algorithm=]) and a [=reading quantization algorithm=] (the [=ambient light
253+
reading quantization algorithm=]).
254+
255+
These algorithms make use of the [=illuminance rounding multiple=] and the
256+
[=illuminance threshold value=]. Implementations must adhere to the following
257+
requirements for their values:
258+
259+
- The [=illuminance rounding multiple=] must be at least 50 lux.
260+
- The [=illuminance threshold value=] should be at least half of the
261+
[=illuminance rounding multiple=].
262+
263+
Note: Choosing an [=illuminance rounding multiple=] requires balancing not
264+
exposing readouts that are too precise while also providing readouts that are
265+
still useful for API users. The value of 50 lux as a minimum for the
266+
[=illuminance rounding multiple=] was determined in <a
267+
href="https://github.com/w3c/ambient-light/issues/13#issuecomment-302393458">GitHub
268+
issue #13</a> after different ambient light level measurements under different
269+
lighting conditions were <a
270+
href="https://docs.google.com/spreadsheets/d/1vUojkaaif6AmftQmtqra1w9Z7CH00Cn9pb0Ci6v5_Jk">gathered
271+
</a> and shown to thwart the attack described in [[STEALINGSENSITIVEDATA]]. 50
272+
lux is also higher than the 5 lux required to make video recognition using
273+
ambient light sensor readings ([[VIDEORECOGNITIONAMBIENTLIGHT]]) infeasible.
274+
275+
Note: The [=illuminance threshold value=] is used to prevent leaking the fact
276+
that readings are hovering around a particular value but getting quantized to
277+
different values. For example, if [=illuminance rounding multiple=] is 50, this
278+
prevents switching the illuminance value between 0 and 50 if the raw readouts
279+
switch between 24 and 26. The efficacy of the [=threshold check algorithm=] as
280+
an auxiliary fingerprinting mitigation strategy has not been mathematically
281+
proven, but it has been added to this specification based on implementation
282+
experience. <a href="https://crbug.com/1332536">Chromium bug 1332536</a> and <a
283+
href="https://crrev.com/c/3666917">Chromium review 3666917</a> contain more
284+
information about this.
285+
196286
Model {#model}
197287
=====
198288

@@ -218,6 +308,17 @@ Note: The precise lux value reported by
218308
different devices in the same light can be different,
219309
due to differences in detection method, sensor construction, etc.
220310

311+
The <a>Ambient Light Sensor</a> has an <dfn>illuminance rounding
312+
multiple</dfn>, measured in lux, which represents a number whose multiples the
313+
illuminance readings will be rounded up to.
314+
315+
The <a>Ambient Light Sensor</a> has an <dfn>illuminance threshold value</dfn>,
316+
measured in lux, which is used in the [=ambient light threshold check
317+
algorithm=].
318+
319+
Note: see [[#reduce-sensor-accuracy]] for minimum requirements for the values
320+
described above.
321+
221322
API {#api}
222323
===
223324

@@ -264,6 +365,58 @@ Abstract Operations {#abstract-operations}
264365
1. Return |ambient_light_sensor|.
265366
</div>
266367

368+
<h3 dfn>Ambient light threshold check algorithm</h3>
369+
370+
The [=Ambient Light Sensor=] [=sensor type=] defines the following [=threshold
371+
check algorithm=]:
372+
373+
<div algorithm="ambient light threshold check">
374+
: input
375+
:: |newReading|, a [=sensor reading=]
376+
:: |latestReading|, a [=sensor reading=]
377+
: output
378+
:: A [=boolean=] indicating whether the difference in readings is
379+
significant enough.
380+
381+
1. If |newReading|["illuminance"] is null, return true.
382+
1. If |latestReading|["illuminance"] is null, return true.
383+
1. Let |newIlluminance| be |newReading|["illuminance"].
384+
1. Let |latestIlluminance| be |latestReading|["illuminance"].
385+
1. If [$abs$](|latestIlluminance| - |newIlluminance|) < [=illuminance
386+
threshold value=], return false.
387+
1. Let |roundedNewIlluminance| be the result of invoking the [=ambient light
388+
reading quantization algorithm=] algorithm with |newIlluminance|.
389+
1. Let |roundedLatestIlluminance| be the result of invoking the [=ambient
390+
light reading quantization algorithm=] algorithm with |latestIlluminance|.
391+
1. If |roundedNewIlluminance| and |roundedLatestIlluminance| are equal,
392+
return false.
393+
1. Otherwise, return true.
394+
</div>
395+
396+
Note: This algorithm invokes the [=ambient light reading quantization
397+
algorithm=] to ensure that readings that round up to the same value do not
398+
trigger an update in the main [=update latest reading=] algorithm. Not doing so
399+
would indicate to users that the raw illuminance readings are within a range
400+
where they differ by at least the [=illuminance threshold value=] but do not
401+
round up to different [=illuminance rounding multiple=].
402+
403+
<h3 dfn>Ambient light reading quantization algorithm</h3>
404+
405+
The [=Ambient Light Sensor=] [=sensor type=] defines the following [=reading
406+
quantization algorithm=]:
407+
408+
<div algorithm="ambient light reading quantization">
409+
: input
410+
:: |reading|, a [=sensor reading=]
411+
: output
412+
:: A [=sensor reading=]
413+
414+
1. Let |quantizedReading| be |reading|.
415+
1. Set |quantizedReading|["illuminance"] to the multiple of the [=illuminance
416+
rounding multiple=] that |reading|["illuminance"] is closest to.
417+
1. Return |quantizedReading|.
418+
</div>
419+
267420
Automation {#automation}
268421
==========
269422
This section extends the [=automation=] section defined in the Generic Sensor API [[GENERIC-SENSOR]]

0 commit comments

Comments
 (0)