- From: Alexander Kyereboah via GitHub <noreply@w3.org>
- Date: Wed, 10 Dec 2025 22:31:39 +0000
- To: public-css-archive@w3.org
Sure, to clarify the tainting model I'm proposing here- it would allow user agents to preserve the rendering of these system colors while preventing them from becoming script‑observable fingerprinting vectors. When a system color value is derived from `AccentColor[Text]` directly, through mixing or relative color functions, color extraction, or during animation it becomes “tainted.” Tainted colors can still be used for rendering, ensuring authors get the actual system accent color visually, but any attempt to read the computed value through CSSOM would return a stable, non‑revealing fallback instead of the real user‑specific color. I explored returning an error or string as a fallback, but `getComputedStyle()` already has precedent for spoofing returned values to default blue so I thought that might make the most sense. The approach mirrors established web platform patterns such as canvas origin tainting and `attr()`. We can definitely be careful here about being too heavy-handed by making sure we're only tainting when `AccentColor[Text]` is derived from a system color and not in other cases (like when `accent-color` is a fixed value). This would make sure the fingerprinting risk is zero rather than less granular, which would satisfy privacy concerns fully. -- GitHub Notification of comment by kyerebo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10372#issuecomment-3639227052 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 December 2025 22:31:40 UTC