Re: [csswg-drafts] [css-color] Mitigating fingerprinting for AccentColor/AccentColorText (#10372)

The CSS Working Group just discussed `[css-color] Mitigating fingerprinting for AccentColor/AccentColorText`.

<details><summary>The full IRC log of that discussion</summary>
&lt;astearns> kyerebo<br>
&lt;fantasai> scribe+<br>
&lt;fantasai> kyerebo: Recap, we previously brought up issue of fingerprinting for AccentColor and AccentColorText when using the system colors<br>
&lt;fantasai> kyerebo: Initially thought we could gate on installing the web app, but [problems]<br>
&lt;lea> q+<br>
&lt;fantasai> kyerebo: Since then we investigated tainting<br>
&lt;fantasai> kyerebo: This solution definitely works, it can apply to getComputedStyle(), color-mix(), color extraction with if(), etc.<br>
&lt;fantasai> kyerebo: We already have tainting with cross-origin canvas etc.<br>
&lt;fantasai> kyerebo: We think this protects the users well enough, and want to move forward with it<br>
&lt;TabAtkins> q+<br>
&lt;emilio> q+<br>
&lt;TabAtkins> (I'm probably just going to +1 what Lea is gonna say)<br>
&lt;fantasai> kyerebo: I do want to summarize, in GH issue, Lea proposed splitting out AccentColor keywords so that authors can avoid the tainting if desired<br>
&lt;fantasai> kyerebo: Also discussion about may vs should, so that UAs can make decisions of tradeoffs<br>
&lt;Rossen5> ack lea<br>
&lt;fantasai> lea: I think we should prioritize tainting only when needed, not whenever AccentColor is used<br>
&lt;fantasai> lea: Basically authors should be able to escape any tainting by setting accent-color to a fixed color<br>
&lt;fantasai> lea: As long as OS accent color is not used, should not be tainting.<br>
&lt;fantasai> lea: Either we only taint the auto value, or we have a separate OSAccentColor keyword and that one gets tainted<br>
&lt;fantasai> lea: I don't have a preference between the two<br>
&lt;fantasai> lea: Separate color keyword does enable some additional use cases, e.g. can use OS-default hue ...<br>
&lt;fantasai> lea: Important bit is not to have tainting unless we actually need it<br>
&lt;fantasai> lea: Wrt may or should or must, I'm not sure there's consensus that this is a significant fingerprinting issue<br>
&lt;fantasai> lea: and tainting has a lot of complexity<br>
&lt;Rossen5> ack TabAtkins<br>
&lt;fantasai> lea: So each UA should be able to choose, so prefer to use MAY or SHOULD<br>
&lt;fantasai> TabAtkins: +1 to what lea said<br>
&lt;fantasai> TabAtkins: tainting should be from use of OS color, not AccentColor itself (which could be a manually set color)<br>
&lt;fantasai> TabAtkins: I like proposal of adding an explicit color for OS Accent Color<br>
&lt;fantasai> TabAtkins: Because still useful to be able to tweak that color and use it as an accent color<br>
&lt;fantasai> TabAtkins: So support adding another color like OSAccentColor which is what carries the taint<br>
&lt;fantasai> TabAtkins: and AccentColor just becomes value of 'accent-color' value<br>
&lt;Rossen5> ack emilio<br>
&lt;fantasai> TabAtkins: just like currentColor and 'color'<br>
&lt;fantasai> emilio: Why are we doing this for AccentColor and not [missed]?<br>
&lt;fantasai> emilio: I think I agree with only tainting the OS values, but also I think we should treat all the system colors consistently.<br>
&lt;lea> s/[missed]?/HighlightColor?/<br>
&lt;fantasai> emilio: I don't see why AccentColor is special, other than authors want to use it a bit more<br>
&lt;kyerebo> q+<br>
&lt;fantasai> emilio: It would be nice to also use, e.g. system selection colors without exposing to authors<br>
&lt;fantasai> emilio: Also, what is the effect of tainting? If it's mixed, what do you return?<br>
&lt;fantasai> emilio: would be nice to see details of what is proposed<br>
&lt;fantasai> emilio: But I would prefer to treat all system colors consistently<br>
&lt;emilio> q+<br>
&lt;fantasai> kyerebo: Privacy review from chromium folks was that accentcolor is increased because highlightcolor etc is gated on accessibility features<br>
&lt;fantasai> kyerebo: Might not be true for other systems<br>
&lt;emilio> ack kyerebo<br>
&lt;fantasai> kyerebo: In our tainting implementation, we use a spoofed blue color<br>
&lt;fantasai> kyerebo: Spoofing of color is a resolution already in the spec, so this makes sense to me<br>
&lt;fantasai> kyerebo: but we could also do something like ????<br>
&lt;Rossen5> ack emilio<br>
&lt;fantasai> emilio: Seems basically same as highlight, except chrome spoofs highlight by default but doesn't want to spoof accentcolor. But they're the same.<br>
&lt;fantasai> emilio: Main issue with tainting, as of right now we resolved that system colors resolve to an actual color, and that's how they interact with light/dark etc.<br>
&lt;lea> q+<br>
&lt;fantasai> emilio: Spoofing seems appropriate...<br>
&lt;fantasai> emilio: returning a keyword would mean that you have to maintain it at computed value time, which won't get the expected behavior for light-dar()<br>
&lt;fantasai> emilio: but does seem like a fair bit of complexity<br>
&lt;fantasai> emilio: but if we apply consistently to all system colors, seems ok<br>
&lt;fantasai> emilio: I think it'd be really weird to only apply to AccentColor and AccentColorText<br>
&lt;fantasai> emilio: at the very least apply to AccentColorText, but also apply to all system colors<br>
&lt;Rossen5> ack lea<br>
&lt;fantasai> lea: Assuming what spoofing means, it's like treat it like a predefined color like blue<br>
&lt;fantasai> lea: Then authors will try to do things and get different values on the page<br>
&lt;emilio> q+<br>
&lt;ChrisL> I agree that users will be confused by mixing the colors and getting the wrong result<br>
&lt;fantasai> lea: I would be ok with not using the OS color, or only use it if you do certain things like install the app<br>
&lt;fantasai> lea: I also think taintining is not a great solution. It causes all kinds of problems, we should not choose it lightly.<br>
&lt;fantasai> lea: Personally I also don't mind if we don't do anything here, but recognize it's an issue from others' perspectives<br>
&lt;ChrisL> q+<br>
&lt;Rossen5> ack emilio<br>
&lt;fantasai> [what is tainting]<br>
&lt;fantasai> TabAtkins: if you read the tainted value, we pretend the value was something else than it was<br>
&lt;fantasai> lea: Hm... can we pick a value in the spec, rather than making it OS-dependent?<br>
&lt;fantasai> ChrisL: It looks like 3 options<br>
&lt;Rossen5> ack ChrisL<br>
&lt;TabAtkins> Yes, it needs to be a value in the spec; if it's OS-dependent, then it's fingerprinting too obviously ^_^<br>
&lt;fantasai> ChrisL: 1) Don't do anything special. This exposes some fingerprinting, but everything is simple to implement.<br>
&lt;lea> qq+ to reply to Chris<br>
&lt;fantasai> ChrisL: 2) Do all this tainting, so people get unexpected values. They create tints etc and it all goes wrong and they can't understand why.<br>
&lt;fantasai> ChrisL: 3) Use keywords and stuff, so color-mix() maintains these as independent channels. This also adds tons of complexity to values.<br>
&lt;fantasai> emilio: It would also inherit the keyword, which means the foreground color changes with color-scheme<br>
&lt;Rossen5> ack lea<br>
&lt;Zakim> lea, you wanted to react to ChrisL to reply to Chris<br>
&lt;fantasai> lea: My understanding of the tainting is that you only get the tainted value if you try to read it. Creating tints etc will work.<br>
&lt;fantasai> ChrisL: Ah, didn't understand. Thought it meant "use the value".<br>
&lt;fantasai> lea: That said, not sure it would work in every case. Right now you can exfiltrate color components using if() and style and registered color properties<br>
&lt;fantasai> lea: Then you would end up tracking all kinds of other properties... seems hellish to implement.<br>
&lt;fantasai> Rossen5: Ok, kyerebo, what are you advocating for here?<br>
&lt;fantasai> kyerebo: Yes, tainting as we talk about is it's available to use for color mixing and rendering, but any attempted reads using getComputedStyle() etc would return a fake color<br>
&lt;fantasai> kyerebo: Option 3 doesn't work for reasons emilio said<br>
&lt;fantasai> kyerebo: Option 1, there's definitely a fingerprinting vector here but there's argument that it's small enough or already existing system colors that do this<br>
&lt;emilio> q+<br>
&lt;fantasai> kyerebo: Option 2, color is available to use but reads are blocked<br>
&lt;fantasai> kyerebo: I'm advocating for option 2, because we did a privacy review and it was found to be a significant fingerprinting vector<br>
&lt;fantasai> Rossen5: This is also going to match highlightcolor?<br>
&lt;fantasai> kyerebo: Specifically for accent-color when using OS color<br>
&lt;Rossen5> ack emilio<br>
&lt;lea> and in the future this will be even easier, via `color-extract()`<br>
&lt;fantasai> emilio: lea brought up really good point that can propagate color to non-color properties, so it's a lot harder than using fake color when querying<br>
&lt;fantasai> emilio: because then you need to track a lot more things<br>
&lt;lea> q?<br>
&lt;lea> q+<br>
&lt;fantasai> emilio: If we do tainting, I'd like to see deep detailed explanation of what it's supposed to do<br>
&lt;fantasai> emilio: And color should be fixed, independent of platform, just like some other system colors<br>
&lt;fantasai> emilio: And also we shouldn't special-case accentColor<br>
&lt;kyerebo> q+<br>
&lt;lea> ack lea<br>
&lt;fantasai> Rossen5: Seems we're out of time, let's take back to the issue and then continue next week.<br>
&lt;kyerebo> ack kyerebo<br>
&lt;Rossen5> ack fantasai<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10372#issuecomment-3608117119 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:01:21 UTC