- From: Alexander Kyereboah via GitHub <noreply@w3.org>
- Date: Wed, 03 Dec 2025 18:11:50 +0000
- To: public-css-archive@w3.org
> Another idea: This started to be considered a significant fingerprinting vector when we realized that some OSes allow freeform color selection, right? What if instead of tainting per se, we reduced the granularity of the returned values? E.g. we could define "buckets" of hue, chroma, lightness based on how many bits of entropy would be acceptable and return those values, which would ensure that any calculations are at least done based on a somewhat similar color. The exact granularity of the buckets could even be UA-dependent. This is an interesting idea, if the vector of the fingerprinting is the concern this could work. Privacy folks seemed to think that any exposure of a user set color (especially one that can be automatically derived from the user's wallpaper on some OSes), introduces an unacceptable level of fingerprinting, but I'm open to reinvestigating whether this would address concerns with them. It seems like there are different levels of exposure for system colors across different UAs and OSes, and there might not be a one size fits all solution. Considering this, would a more flexible resolution be to leave reads of `AccentColor[Text]` as a "MAY" block per UA? This allows UA's that already exposed other system colors in the same capacity to not have to implement a complex mitigation for something that wouldn't add more entropy for them, while giving UA's that don't have exposure in the same capacity the option to block reads of `AccentColor[Text]` with gating behind installed applications, tainting and returning fake values, etc. -- GitHub Notification of comment by kyerebo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10372#issuecomment-3608160232 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 December 2025 18:11:51 UTC