Consider making granularity of the data normative #63
Assignees
Labels
privacy-needs-resolution
Issue the Privacy Group has raised and looks for a response on.
Comments
xfq
added
the
privacy-tracker
w3cbot
added
privacy-needs-resolution
|
@cynthia are you able to explain a little further the granularity changes Chrome makes, I don't see much in the minutes or non normative in the spec text. |
|
Thank you @xfq for bringing this issue to our attention in PING via the privacy-tracker label. We are pleased to see that you are working to make the privacy mitigations normative in the spec. |
This was discussed in #13 and the first Chromium commit is https://chromium-review.googlesource.com/c/chromium/src/+/1834346 (see also https://bugs.chromium.org/p/chromium/issues/detail?id=642731). The idea is to:
|
|
@jonathanKingston are you interested in joining our TPAC meeting w3c/devicesensors-wg#47 as a guest for this and possibly other privacy topics of interest? I’ll follow up separately. |
|
Just to be on record, while it probably is very confusing, I don't work on Chrome - so I can't answer Chrome specific questions. The granularity quantization must have been discussed and recorded somewhere under the WG though. |
|
Checking in to see where things stand on this issue |
|
@sandandsnow thanks for checking. Most recently, we made the following resolution:
Let us know if this satifies your request and we’ll update the spec to match the implementation in this regard. @rakuco implemented this mitigation IIRC, so maybe he can spec this and loop in @sandandsnow for review. |
|
Thank you @anssiko. This is very helpful. Also, any idea when this resolution will be fully implemented? |
This is something in my to-do list. The spec changes aren't big, but I need to ask for input from people who reviewed the original mitigations that were added to Chrome years ago, as that work precedes my involvement with this spec and I don't fully remember how we reached those specific threshold values. I'd like to get this done by 2022 Q1. |
rakuco
pushed a commit
to rakuco/sensors
that referenced
this issue
Dec 15, 2021
…n use. 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. A new algorithm, the threshold check algorithm, can be defined by concrete sensors and is associated with a sensor type. It is invoked by the "update sensor reading" abstract operation when defined, and if it returns false, "update sensor reading" will abort and not update the `latest reading` map. A few other parts also had to be adjusted to make this work possible: - A platform sensor is now explicitly associated with a sensor type. - Extension sensor attribute getters are no longer normatively required to simply return the value of invoking "get value from latest readings", as `AmbientLightSensor.illuminance`'s getter needs to do extra work. We only require that the attributes be read-only now.
rakuco
pushed a commit
to rakuco/ambient-light
that referenced
this issue
Dec 15, 2021
… check. Related to w3c#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 (and both are necessary). We first define a few values: - An "illuminance threshold value" of at least 50lx. - An "illuminance rounding multiple" of at least 50lx. 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. - `AmbientLightSensor.illuminance`'s getter returns values that are rounded to the closest multiple of the illuminance rounding multiple.
|
I've sent w3c/sensors#429 and #77 here to try to address this. The changes ended up being larger than just specifying a granularity value because Chrome specifies granularity and checks if new readings differ enough from the current one to store them, and both are required. Feedback is highly appreciated, especially because this is the first time I'm normatively specifying security related stuff so I'm assuming everything will explode in weird ways :-) |
rakuco
pushed a commit
to rakuco/sensors
that referenced
this issue
Jun 3, 2022
…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.
rakuco
pushed a commit
to rakuco/sensors
that referenced
this issue
Jun 3, 2022
…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.
rakuco
pushed a commit
to rakuco/ambient-light
that referenced
this issue
Jun 3, 2022
Related to w3c#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.
rakuco
pushed a commit
to rakuco/sensors
that referenced
this issue
Jun 3, 2022
…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.
rakuco
pushed a commit
to rakuco/sensors
that referenced
this issue
Jun 7, 2022
…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.
rakuco
pushed a commit
to rakuco/ambient-light
that referenced
this issue
Jun 10, 2022
Related to w3c#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.
rakuco
pushed a commit
to rakuco/ambient-light
that referenced
this issue
Jun 15, 2022
Related to w3c#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.
The PRs above have been merged, so I think we're finally done here! |
miketaylr
pushed a commit
to miketaylr/ambient-light
that referenced
this issue
Oct 18, 2022
Related to w3c#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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Discussed in the virtual TPAC discussion here: https://www.w3.org/2020/10/23-dap-minutes.html
Currently, the only implementation (Chromium) gates the sensor information through a step function of privacy/security reasons - would it make sense to consider making this behavior normative in the spec?
The text was updated successfully, but these errors were encountered: