Declare quantization and threshold check algorithms for extension to the spec #429
Conversation
rakuco
changed the title
|
@anssiko @reillyeon @sandandsnow this is a draft of where I'm thinking of heading with the fix for w3c/ambient-light#63. This PR should be viewed together with w3c/ambient-light#77. AFAICS, only specifying the granularity of the illuminance data is not enough, as the Chrome implementation also checks if the new reading differs from the latest one significantly enough, and IIRC @reillyeon mentioned only doing the rounding was not enough to avoid fingerprinting. |
|
I like where this is going and how this PR lays the infrastructure that can be reused by any Generic Sensor-based specifications to normative specify "reduce accuracy" type of mitigations. I'll lean on @sandandsnow and other PING participants for privacy experts' perspective. |
rakuco
force-pushed
the
add-privacy-terms-and-enhancements
branch
from
2eb7baa to
1184586
Compare
rakuco
changed the title
rakuco
force-pushed
the
add-privacy-terms-and-enhancements
branch
2 times, most recently
from
7dce5d4 to
a4d6301
Compare
|
@anssiko @xfq any idea why the CI is failing? The error looks like this: https://github.com/w3c/sensors/actions/runs/2434380983 |
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.
There was a problem hiding this comment.
Thanks! One minor fix.
Can we convert this PR from Draft to Ready for review?
CI error was not helpful to me. https://github.com/w3c/sensors/blob/main/.github/workflows/auto-publish.yml seems legit as does this PR.
rakuco
force-pushed
the
add-privacy-terms-and-enhancements
branch
from
a4d6301 to
138a564
Compare
I think so, done.
Heh this was... interesting. It's caused by some spec-prod updates that break links inside embedded SVG documents like the one we ship in the Sensor Lifecycle section. I've filed w3c/spec-prod#139 and will submit a workaround in the meantime. |
…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.
... 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.
rakuco
force-pushed
the
add-privacy-terms-and-enhancements
branch
from
138a564 to
d6f55ec
Compare
|
Gentle ping @reillyeon and @sandandsnow. @sandandsnow maybe schedule this for the next PING call together with issue w3c/ambient-light#63 and its associated PR w3c/ambient-light#77 ? We'd like to make sure you're happy with this direction since we may want to add similar anti-fingerprinting measures to other APIs that take a dependency on the Generic Sensor API. We're using the Ambient Light Sensor as the first concrete sensor for this privacy enhancement. (This is already implemented so we have that experience, now we want to land the spec changes so any new or existing sensor capability can more easily integrate these mitigations in a consistent manner. This simplifies both spec and implementation work and helps with "privacy by design".) |
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.
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
changed the title
|
@anssiko @reillyeon could either of you merge this PR? I think we've waited long enough, and if @lknik is OK with it I'm OK with it :-) |
|
With @lknik's 👍 I feel we can indeed merge this PR. He has followed this work closely for many years so I trust in his privacy judgment. @sandandsnow, we want to be inclusive of the whole PING, so if other PING participants have further feedback, we are happy to discuss improvements to these algorithms in subsequent updates. |
|
I am happy to be guided by @lknik on the details of the improvements. I understand that the WG will continue to consider improvements as the specification and include them in updates as they are identified. |
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.
…ents". The new algorithms were defined in the "Sensor Type" section, but it makes sense to list them when describing what extension specifications may do.
…ents". The new algorithms were defined in the "Sensor Type" section, but it makes sense to list them when describing what extension specifications may do.
…ents". The new algorithms were defined in the "Sensor Type" section, but it makes sense to list them when describing what extension specifications may do.
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:
threshold check algorithm that compares two readings and returns whether
they differ enough or not.
used to quantize readings returned by the "get value from latest reading"
algorithm (which is used by attribute getters, for example).
are encouraged to go with either none or both.
Preview | Diff