Declare quantization and threshold check algorithms for extension to the spec

[rakuco]

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.

---

Preview | Diff

[rakuco]

@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.

[anssiko]

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]

@anssiko @xfq any idea why the CI is failing? The error looks like this: https://github.com/w3c/sensors/actions/runs/2434380983

[rakuco]

Can we convert this PR from Draft to Ready for review?

I think so, done.

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.

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.

[anssiko]

Gentle ping @reillyeon and @sandandsnow.

@sandandsnow maybe schedule this for the next PING call together with issue https://github.com/w3c/ambient-light/issues/63 and its associated PR https://github.com/w3c/ambient-light/pull/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".)

[rakuco]

@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 :-)

[anssiko]

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.

[sandandsnow]

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.