- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 10 Sep 2025 16:30:13 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-color] Mitigating fingerprinting for AccentColor/AccentColorText`. <details><summary>The full IRC log of that discussion</summary> <fantasai> kyerebo: Issue is, we have AccentColor styling for setting form controls<br> <fantasai> kyerebo: accent-color: auto uses the system accent color<br> <fantasai> kyerebo: Recently trying to ship AccentColor keyword, should respond to system color<br> <fantasai> kyerebo: But keyword, because values can be computed and used by script, there was a privacy issue<br> <fantasai> kyerebo: We can't be exposing this for accent-color: auto<br> <fantasai> kyerebo: Considering mitigations in Chromium, such as limiting to installed web apps<br> <fantasai> kyerebo: But problem is that authors may expect them to resolve to the same value<br> <fantasai> kyerebo: Should we also restrict `accent-color: auto` then?<br> <ChrisL> Authors would be astonished if they resolved differently, I think<br> <Rossen3> q?<br> <fantasai> kyerebo: That's the question.<br> <weinig> q+<br> <fantasai> kyerebo: If we don't restrict it, then `accent-color: auto` will use a different value than AccentColor<br> <fantasai> kyerebo: which would return a system default<br> <lea> q?<br> <Rossen3> ack weinig<br> <fantasai> ydaniv: But if we do restrict it, then a regression of sorts because web apps can no longer match the system accent color<br> <fantasai> weinig: Did we investigate tainting for colors, similar to images?<br> <fantasai> weinig: So that if the color is e.g. mixed or whatever, would taint the mixed value<br> <Rossen3> s/ydaniv: But if we do/kyerebo: But if we do/<br> <fantasai> weinig: And tainted value would not be discernable from script<br> <fantasai> weinig: One way to do that would be providing a fake value<br> <fantasai> weinig: but would need more complex due to things like color-mix() or canvas().<br> <lea> q+<br> <fantasai> weinig: If you use tainted AccentColor with canvas, can no longer read the bits<br> <fantasai> weinig: This is what we do with origin-tainted [missed]<br> <kbabbitt> s/[missed]/images/<br> <fantasai> kyerebo: We did consider returning a different value than what is used<br> <lwarlow> q+<br> <lea> q-<br> <lea> q+<br> <fantasai> kyerebo: but we resolved previously that system colors should compute to themselves<br> <fantasai> weinig: Problem is that colors these days don't exist in a vacuum<br> <fantasai> weinig: you can have color-mix() or relative colors, or use colors in <canvas><br> <fantasai> weinig: Would have to consider all of these together<br> <Rossen3> ack lwarlow<br> <fantasai> lwarlow: My thoughts on this are that, if we can't expose the system accent color because fingerprinting is too bad<br> <fantasai> lwarlow: I don't think that should result in accent-color: auto being less capable<br> <dbaron> +1 to lwarlow<br> <fantasai> lwarlow: Realistically, if approach is "provide a fake color, always use blue", we might as well not ship accentcolor<br> <florian> q+<br> <fantasai> lwarlow: Exposing a system color and then never making it do the thing it's meant to do seems wrong.<br> <fantasai> lwarlow: On the other side of things, in an ideal world, rather than make it lie, would make it paint correctly and do some kind of tainting to not expose the color<br> <fantasai> lwarlow: There's still -webkit-focus-ring which exposes this color in Chrome on MacOS<br> <dholbert> q+<br> <fantasai> lwarlow: If we go down the "dont' expose these colors", then we need to actually follow through on that.<br> <fantasai> alisonmaher: I believe we did roll that back on Chromium.<br> <fantasai> alisonmaher: so that it's no longer exposed.<br> <Rossen3> ack lea<br> <fantasai> lea: Tainting is not that simple, becaue not color itself, but color-mix(), color-extract(), relative colors<br> <fantasai> lea: color-extract() lets you grab a color component and use it in e.g. variables etc.<br> <fantasai> lea: I don't have a strong opinion on what to do, but<br> <fantasai> lea: having accent-color use one color and AccentColor another, this is bad<br> <lwarlow> q+<br> <fantasai> lea: I think it's ok if exposed in some contexts and not others, as long as page has one accentColor<br> <weinig> q+<br> <fantasai> lea: What if it's UA *MAY* expose the accent color or system color?<br> <fantasai> lea: But should be hard requirement that these are the same color<br> <fantasai> lea: less critical for canvas. Most UI doesn't combine canvas and CSS.<br> <fantasai> lea: but between built-in components and web components, should be able to depend on accent color being the same<br> <fantasai> lea: Also, wrt can we just not expose as a system color<br> <fantasai> lea: built-ins also need to access it through appearance:base. Their style needs to be expressable in CSS.<br> <fantasai> dbaron: My read of current situation is that computed values of system colors compute to color values.<br> <fantasai> dbaron: we didn't have to do it that way, but been that way for a long time<br> <Rossen3> ack dholbert<br> <Rossen3> ack dbaron<br> <fantasai> dbaron: also means that tainting is easier ot implement and describe, but also more destructive<br> <Rossen3> q+ dholbert<br> <fantasai> dbaron: if what we're tainting is a computed value that's just a color, then what you're propagating is a color + flag about whether it's tainted<br> <fantasai> dbaron: One of the problems there is that you can't expose anything useful in getComputedStyle()<br> <fantasai> dbaron: I see the problem with both main alternatives brought up originally<br> <fantasai> dbaron: It's bad to break existing accent-color: auto; feature but also the inconsistency is bad<br> <Rossen3> ack florian<br> <fantasai> dbaron: We could have had alternative path of storing sytem colors as system color keywords. That would have made tainting more complicated but more useful.<br> <alisonmaher> This was the original issue that was discussed: https://github.com/w3c/csswg-drafts/issues/5710<br> <fantasai> florian: This exact problem is why I pushed back against accent-color property affecting AccentColor keyword<br> <fantasai> florian: because it makes it more desirable to use it more often<br> <fantasai> florian: In some browsers, the color you see is different from AccentColor<br> <fantasai> florian: I think dbaron's suggestion is the most promising path forward -- just saying you don't use the system accent color at all is probalby not reasonable, even though it would bring consistency<br> <Rossen3> ack dholbert<br> <fantasai> dholbert: Premise is that developers shouldn't use accent color or read it<br> <lea> q?<br> <fantasai> dholbert: If you're using the color, and user has similar shade of blue, maybe you want a different color for some other purpose so you don't have unreadable content<br> <fantasai> dholbert: There are good reasons to have this info<br> <Rossen3> ack lwarlow<br> <fantasai> lwarlow: Is it actually really that big of a deal if the accentColor keyword doesn't match what color the system colors render with?<br> <fantasai> lwarlow: That's status quo<br> <lea> q+<br> <fantasai> lwarlow: For appearance:auto, browsers can do whatever they want anyway<br> <fantasai> lwarlow: If they really wanted consistency, they could just set accent-color and then they'll match<br> <florian> [to dbaron, yes, I was]<br> <fantasai> lwarlow: Status quo is that it doesn't match. I don't think we should expose it if it doesn't match.<br> <fantasai> lwarlow: wrt not exposing due to appearance: base ... ideally all those styles should be explainable with CSS<br> <fantasai> lwarlow: but could it resolve when it's in a UA stylesheet and not in author style sheet?<br> <fantasai> lwarlow: Though currently no appearance:base style uses AccentColor anyway<br> <Rossen3> ack weinig<br> <fantasai> weinig: I really think that coming up with some definition, probably in a color spec, of codifying concept of a tainted color and how it behaves is the way forward<br> <fantasai> weinig: I don't expect this to be the last time we run into this<br> <dbaron> s/dbaron's suggestion/dbaron's suggestion about tainting by propagating a computed color plus an additional bit/<br> <fantasai> weinig: wrt existin system colors resolving to a specific rgb value, those system colors are deprecated because of that behavior<br> <fantasai> weinig: maybe the right way forward is to come upw tih a function that always has a tainting behavior, for things that actually want to match the system<br> <fantasai> weinig: and the absolutely-resolving system colors can just be legacy behavior<br> <fantasai> weinig: But experiement of having color + taint bit is a good experiment to see what the cost would be<br> <fantasai> weinig: that's the only solution if we actually want to match system colors anywhere<br> <Rossen3> ack lea<br> <fantasai> lea: wrt status quo, AccentColor wasn't broadly supported so not much status quo<br> <dbaron> (curious if weinig was proposing that the "new" system color type would be part of the computed value -- that's also a bit more complicated since it requires that multiple other things that contain color values be part of the computed value representation -- which I think they don't have to today)<br> <fantasai> lea: Multiple acccent colors would be unacceptable to authors<br> <fantasai> lea: they'd have to set accent-color as a boilerplate always<br> <fantasai> lea: But you'd need to taint not just colors but also other things given color-extract()<br> <fantasai> lea: could make it not-tainted in certain contexts, e.g. installed web apps<br> <fantasai> lea: authors should be able to detect if a value is tainted<br> <fantasai> lea: and there should be a reasonable default behavior<br> <fantasai> lea: for where breakage could make things unreadable<br> <noamr> scribe+ noamr<br> <Rossen3> ack fantasai<br> <Zakim> fantasai, you wanted to reply on that<br> <noamr> fantasai: a reason why the resolve to absolute is to avoid the complexity of maintaining all the channels of color, when mixing them<br> <noamr> fantasai: very similar to currentcolor<br> <noamr> fantasai: this was for simplicity of implementation, not having to maintain channels<br> <ChrisL> Yes that was exactly the reason<br> <weinig> I think we have gone way past that complexity at this point<br> <noamr> fantasai: in terms of default, if we were going to paint it it should have a default (blue or other)<br> <lea> q?<br> <lea> q++<br> <lwarlow> +1<br> <lea> qq+<br> <noamr> fantasai: we shouldn't taint derived numbers; if someone does something complicated they should use a real color and not a tainted system color<br> <fantasai> Rossen3: Time to switch topics. Next steps is continue engage on the issue,<br> <lea> just to reply to fantasai re: doing weird things: the primary value of accentcolor is for different parties to communicate. If you can handshake, you can just use a CSS variable. So the web component doing "weird things" does not control the page-level accent color<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-3275684205 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 September 2025 16:30:14 UTC