w3c
[css-color] Mitigating fingerprinting for AccentColor/AccentColorText
AccentColor/AccentColorText were created here: https://github.com/w3c/csswg-drafts/issues/7347
We still haven't shipped this in chromium due to fingerprinting concerns, but I have gotten a lot of interest about providing access to the system accent color so I'd really like to ship it. WebKit has also avoided shipping this by returning a static color instead of the actual system accent color, and I'd hope that if we do mitigations then they will start using the system accent color as well: https://github.com/WebKit/standards-positions/issues/136
I think proving that the system accent color is not significantly fingerprintable would be difficult or impossible, especially since there are many different platforms which we want to ship this on.
@emilio said that we shouldn't allow this color to resolve to something other than a color since we don't do that for anything else, but in the interest of shipping this in chromium I think that we should.
Some limitations to consider:
- Prevent AccentColor/AccentColorText from being used to draw to a canvas.
- Prevent getComputedStyle() from returning the actual system accent color. Should it return a fixed color or something else?
- Prevent interpolation when AccentColor/AccentColorText is used.
Prevent AccentColor/AccentColorText from being used to draw to a canvas.
What mechanism do you plan to use for this exactly?
Prevent getComputedStyle() from returning the actual system accent color. Should it return a fixed color or something else? Prevent interpolation when AccentColor/AccentColorText is used.
Two bits about these... At least in Gecko (I suspect in WebKit as well), we don't preserve the system color past the computed value phase (that's a whole thing, see https://github.com/w3c/csswg-drafts/issues/6773). Having to do that just for AccentColor / AccentColorText is rather annoying.
Re. the interpolation, not being able to interpolate AccentColor seems like a severe limitation, which no other color has aiui. I'm assuming that this would also apply to color-mix() and co, right?
In particular, consider something like a generic:
button {
color: var(--button-color);
background-color: var(--button-background);
&:hover {
button-background: color-mix(in srgb, var(--button-background) 80%, transparent);
}
}
It'd be extremely confusing if now having something like:
--button-color: accentcolortext;
--button-background: accentcolor;
Now didn't work at all and made the hover effect useless.
All-in-all, I'm still of the opinion that AccentColor shouldn't be special (or at least shouldn't be more special than any other system color, like e.g. Highlight).
This is probably part of a larger conversation, but is obfuscation/privacy a concern for PWA/Home screen/"Psuedo-Native" apps?
I very much want to my web apps to look and feel identical to native. System accents is just one of them. (Font size is the other).
For Materials Design (Android), I don't think the entire series of color options can be replicated with just color mixing. That would mean secondary/complimentary hues and all their variations. The use of HCT as a custom colorspace instead of BT709/SRGB makes it impossible to do with CSS. I haven't tried it, and might be able to get close, but no real color access would definitely be a limitation.
I mentioned this somewhere before, but limiting to a hue with limited variations is probably enough. Take the 360º hue and segmenting them maybe 15 or 20 is probably enough to replicate a user's preferred primary device palette/hue.
What mechanism do you plan to use for this exactly?
Good question. I suppose that if we start passing colors around as unresolved values in certain places, then maybe canvases can check for these values...?
not being able to interpolate AccentColor seems like a severe limitation
I agree, but it seems better to me than not implementing at all. We could emit a console message in this case to help developers know what they did wrong.
This is probably part of a larger conversation, but is obfuscation/privacy a concern for PWA/Home screen/"Psuedo-Native" apps?
If we can't make progress here, then yeah we might ship for installed websites since fingerprinting might not be an issue there.
At least in Gecko (I suspect in WebKit as well), we don't preserve the system color past the computed value phase
I'm not sure if we do this in chromium either, but if there is enough desire for this feature then maybe it's worth changing.
@alisonmaher @padmapriyap1 what do you think about emilio's questions?
we don't preserve the system color past the computed value phase (that's a whole thing, see https://github.com/w3c/csswg-drafts/issues/6773). Having to do that just for AccentColor / AccentColorText is rather annoying.
@emilio what do you mean by "preserve" here? Is it the part about flagging that they were system colors? If so, Chromium, in contrast, does follow this resolution as per spec.
I agree, though, that we shouldn't do anything specific for AccentColor or AccentColorText. Whatever we decide here should likely be extended to all system colors that we expose.
What mechanism do you plan to use for this exactly?
Good question. I suppose that if we start passing colors around as unresolved values in certain places, then maybe canvases can check for these values...?
In Chromium, we do store a bit that notes if a color was a system color, so we could use the same mechanism here to tell what cases it would be needed. Chromium also has a fallback set of colors we use for system colors that are not tied to any OS that we could consider falling back to in cases where needed.
However, I am not familiar with the fingerprinting risk of using these in canvas and interpolation. @josepharhar would you be able to provide more details on that?
Prevent getComputedStyle() from returning the actual system accent color. Should it return a fixed color or something else?
I do think this could be an option. As mentioned above, perhaps we could set a fallback color for the different system colors and use those in this case.
AccentColor as I understand is a relatively recent addition to the set of system colours. Given the fingerprinting concerns, wouldn't it have been better to just not ship this system colour at all, than to ship it with a false colour? Is the idea that for forced colours mode specifically it might be an acceptable trade off to leak the actual colour?
It would be nice to be able to match the system theming, but as mentioned before it's more applicable to the installed web app case, so perhaps exposing it to "PWAs" but not to in-browser apps is enough?
Not being able to interpolate wouldn't be desirable, it stops you generating hover variants for example.
@lukewarlow IIRC for forced colors mode, the argument that was made was that most users of the feature end up using one of the default-supplied high contrast themes provided by Windows, as such, limiting the fingerprinting risk.
However, I am not familiar with the fingerprinting risk of using these in canvas and interpolation. @josepharhar would you be able to provide more details on that?
If we allow the system accent color to be painted to a canvas, then it would be possible for javascript to read back the color. For this reason, we don't allow the system accent color to be used when painting form controls to a canvas for example.
As for interpolation, I suppose this is another way that the page could figure out what the color is by doing something with javascript.
I don't have sample code for either of these cases but I could find it if needed.
Emilio, I echo your concerns that we may make colors way more complicated by doing this which is unfortunate, but I don't see another way around the fingerprinting issue. Do you have any other ideas? Were you able to prove that there is no fingerprinting risk in order to ship in firefox?
No, there is a trade off regarding fingerprinting. In our case, Firefox was already shipping similar colours for e.g. selection (Highlight/HighlightText) which already exposed / were derived from the system accent color, so adding the accent color didn't add any extra fingerprinting surface except for obscure GTK themes. Also, on windows we don't expose the system accent color, currently.
If we wanted to tackle that fingerprinting surface (tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1861362, cc @martinthomson) the way to fix it would be returning a hard-coded color not only for accent color, but also for Highlight / SelectedItem / etc.
on windows we don't expose the system accent color, currently.
I believe that what @alisonmaher and/or @padmapriyap1 want to implement in chromium would expose the system accent color on windows.
Firefox was already shipping similar colours for e.g. selection (Highlight/HighlightText) which already exposed / were derived from the system accent color
I believe that we might still be leaking the system accent color on macos in chromium via -webkit-focus-ring-color because nobody has made a big stink about it yet, but I could see us patching that like WebKit did eventually. We don't use the accent color for anything on any other platforms so I don't think we can use this macos behavior as precedent to start leaking for the other platforms either.
the way to fix it would be returning a hard-coded color not only for accent color, but also for Highlight / SelectedItem / etc
This sounds to me like we should give up on AccentColor/AccentColorText unless it would be useful for installed websites to have access to the system accent color and we can get confirmation that fingerprinting is OK in those cases.
I noticed Google's commit has AccentColor and AccentColorText behind a flag called CssSystemAccentColor. This is fine for me if the operating system /browser can decide later what sites or environments will expose this value.
For example, on Android and Safari, this could be Web Apps added to Home Screen. Electron could enable this. I'd imagine a @supports { color: AccentColor} or CSS.supports('color', 'AccentColor'); would be use the dev check.
If fingerprinting is a concern in certain environments, perhaps the browser can decide what is trusted and what is not. Another permission can come along later down the road, as well.
So where are we on AccentColor?
In the spec we already have
User Agents may, to mitigate privacy and security risks such as fingerprinting, elect to return fixed values for the used value of system colors which do not reflect customisation or theming choices made by the user.
but that is general for all system colors. Is it enough?
And given the may should a specific mention be added to Privacy Considerations?
@svgeesus I tend to agree, this feels like it generally would be sufficient to me.
In Chromium, we are considering shipping the true AccentColor/AccentColorText only on installed apps, and then falling back to a default color in all other cases to help in mitigating the risk.
Adding this to the agenda to see if the current text is sufficient, or if there is more that is needed.
Once #5900 ships I imagine in most cases pages would be setting accent-color so it can be used by components etc, so the default value mainly matters as a fallback, so having something is more important than having the actual accent color used.
But if we go that route, that should be used everywhere. At some point WebKit used a weird middle ground that was the worst of all worlds: native form controls used the real accent color, but AccentColor was hardcoded to a shade of blue, producing inconsistent results when used alongside native form controls. I see that now they have "fixed" it by always hardcoding accent color to a fixed value (testcase).
That said, I don't think the fingerprinting surface is significant enough to be worth the complexity being proposed here around hiding the actual value, especially since other UAs do expose the value. How is this significantly different from having ui-* font keywords? While we don't expose means to read what the actual font name is for this, pages can read enough information to match it against a list of known system fonts.
As an additional data point, I don't know what the Windows UI looks like, but at least in OSX the selection is between 8 presets:
If anything, exposing the highlight color introduces more entropy, since that can be custom!
That is a fair point, we likely want these two to match (i.e. always fallback or not in all the same scenarios) for consistency.
I do agree it is worth discussing how this system color introduces any further fingerprinting surface than other system colors, since completely unconstricting both would be another option.
FWIW, on Windows, the accent color can be custom:
The CSS Working Group just discussed [css-color] Mitigating fingerprinting for AccentColor/AccentColorText.
The full IRC log of that discussion
<kbabbitt> kyerebo: I'm Alex, recently taken over implementation of accent-color in Chromium<kbabbitt> ... summary of issue is: we resolved to add support for accent color keyword using actual system's accent color
<kbabbitt> ... have a blocking privacy concern regarding user's accent color
<kbabbitt> ... and what we currently have in spec is that we're leaving up to UA to mitigate privacy risks by returning fixed values
<kbabbitt> ... which don't reflect actual customization or choices made by user
<kbabbitt> ... in Chromium we're considering exposing accent color only in installed appliecations
<kbabbitt> ... discussion that fingerprinting surface was not significant enough to warrant complexity
<kbabbitt> ... some concern about using in form controls or native keywords
<kbabbitt> ... wanted to get some thoughts around whether language in spec is sufficient
<jarhar> q+
<kbabbitt> ... and whether fingerprinting surface is a real concern
<astearns> ack jarhar
<kbabbitt> jarhar: don't have anything to say about spec text. in terms of whetehr this is a real privacy issue, I'd be happy to ask that question again and bring in chrome security and privacy people
<kbabbitt> ... not an expert but that seemed like a concern to me
<kbabbitt> ... if you have evidence that it's not a big issue pleas let me know I'd be happy to help
<kbabbitt> astearns: other comments or questions?
<kbabbitt> alisonmaher: how these compare to other system colors - on Windows, accent color can be customized
<kbabbitt> ... which increases fingerprinting risk
<kbabbitt> ... but other system colors are also customizable
<kbabbitt> ... raises question, do users customize this more than other system colors?
<lea> q+
<kbabbitt> ... but at least on windows, all system colors are customizable
<astearns> ack lea
<kbabbitt> lea: on OSX, the highlight color is customizable but accent color isn't
<kbabbitt> ... it seems we currently do expose highlight color
<kbabbitt> ... so that's introducing more entropy
<kbabbitt> ... since it can be customized, so it doesn't seem any worse than what we have right now
<kbabbitt> ... once we impolement the resolution that accent color resolves to value of accent-color property, this becomes less of an issue
<kbabbitt> ... because most pages will set accent-color anyway
<kbabbitt> astearns: whether or not authors set the accent-color, doesn't really affect the fingerprinting risk
<kbabbitt> ... because someone who is interested in getting more fingerprint surface won't set accent-color
<kbabbitt> lea: I was thinking that you would need control over whole page for that kind of fingerprinting
<kbabbitt> astearns: maybe we need more info from privacy folks
<kbabbitt> alisonmaher: does the current spec text suffice? leaves it up to UA to mitigate these risks
<kbabbitt> ... or do we need more specific text here for accent color and accent color text in general?
<lea> (and also once it reflects the value of `accent-color` in theory extensions or user CSS can override and the page wouldn't know)
<kbabbitt> astearns: don't know but it seems an interoperable implementation would be better
<kbabbitt> alisonmaher: definitely want interoperable, maybe we need spec text for that
<astearns> s/interoperable implementation/interoperable mitigation/
<kyerebo> q+
<astearns> ack kyerebo
<kbabbitt> jarhar: I guess we can follow up with some more security and privacy discussions outside WG
<kbabbitt> kyerebo: alisonmaher and I put this on agenda, jarhar is the resolution here to have further talks on security and privacy to see if fingerprinting is significant
<kbabbitt> ... and get text for interoperable resolution?
<kbabbitt> jarhar: sure
<kbabbitt> ... if things are already exposed as mentioned earlier, that can be used to reexamine how bad fingerprinting is
<kbabbitt> ... I think that makes sense
<kbabbitt> astearns: I think that makes sense as well
<kbabbitt> ... get expert opinions, and based on those, are there changes to spec to say you can return real color
<kbabbitt> ... or here's what you need to do to hide real color, interoperable either way
<kbabbitt> ... who can take this to privacy people?
<kbabbitt> alisonmaher: kyerebo and I can figure that out
<kbabbitt> astearns: anything more?
Did a reassessment of the privacy risks with privacy folks in Chromium. They posited that AccentColor/AccentColorText provides a significant fingerprinting vector beyond that of other system colors, quote:
the accent color can have quite some identifying information (e.g. when it is derived from the wallpaper, or based on users' selection). We've previously required the accent color to not be exposed to scripts (https://chromestatus.com/feature/6548224737017856?gate=6390813732634624), and I would treat current exposures as bugs that should be fixed. So we should not regress on that.
That being said, scoping this exposure to installed websites was approved as a sufficient mitigation, and I think we can close this issue as such.
To the point of accent-color: auto and AccentColor/AccentColorText having different levels of availability, since AccentColor/AccentColorText has been more restricted, I think it makes sense to scope down accent-color: auto system color availability to installed websites only as well for consistency.
I think it makes sense to scope down accent-color: auto system color availability to installed websites only as well for consistency.
But where does the auto value actually get exposed to script? It just resolves to auto in computed style? The fingerprinting issue is because when you use AccentColor you're able to access the value in script. accent-color:auto should be completely safe?
Right, but LeaVerou and alisonmaher's points were that having inconsistent exposure on accent-color: auto and AccentColor is confusing. Because they have different levels of fingerprinting, they aren't held to the same level of scoping. If one is fully available everywhere, but the other is only scoped to installed websites, it introduces an inconsistency that developers might not be expecting.
Because of this, I think it makes sense here to scope to the level required by the riskier of the two.
Because of this, I think it makes sense here to scope to the level required by the riskier of the two.
Personally I think lowest common denominator feature availablity is a bad idea. We should make the platform as capable as possible within the constraints set (privacy, security etc). In this case if we can't expose AccentColor then we can't do that. But that doesn't mean we should change accent-color: auto to be less capable.
Right, but LeaVerou and alisonmaher's points were that having inconsistent exposure on
accent-color: autoand AccentColor is confusing. Because they have different levels of fingerprinting, they aren't held to the same level of scoping. If one is fully available everywhere, but the other is only scoped to installed websites, it introduces an inconsistency that developers might not be expecting. Because of this, I think it makes sense here to scope to the level required by the riskier of the two.
I can't speak for @alisonmaher, but the inconsistency I was talking about is that we should absolutely avoid them resolving to different colors on the same page, at the same time, e.g. AccentColor resolving to blue so web components using it are blue and native form controls use accent-color which resolves to pink. As long as they resolve to the same color at any given time, I think it's ok to expose one of them on a broader set of websites than the other, though ideally both should be available everywhere...
I think it makes sense for AccentColor and accent-color: auto to produce the same results across the board to provide consistency for authors. This was something that @emilio brought up in https://groups.google.com/a/chromium.org/g/blink-dev/c/uP9MI1IdZj8/m/rJA77EppAAAJ, as well.
As long as they resolve to the same color at any given time, I think it's ok to expose one of them on a broader set of websites than the other
@LeaVerou could you clarify what you mean by this point? As I understand it, if we limit the exposure of AccentColor to installed apps to mitigate the fingerprinting risk, we'd need to limit accent-color: auto in the same way in order to guarantee these use the same color in all cases, unless I misunderstand. Or are you saying that if only accent-color: auto is used on a page (and that page doesn't apply AccentColor anywhere), then we could expose it more fully? And if both are used, restrict both? If so, that also could potentially lead to author confusion in some cases.
ideally both should be available everywhere...
Fwiw we did consider having system color keywords resolve to themselves, which would have allowed us to expose AccentColor in all the same cases we do for accent-color: auto today https://github.com/w3c/csswg-drafts/issues/5710. However, from what I recall, we decided against this as a result of the following issue on interpolation support for system colors: https://github.com/w3c/csswg-drafts/issues/5780 (if we want to reconsider any of these resolutions, that would be another the way to avoid the fingerprinting risk for AccentColor).
Adding back to the agenda to discuss the results of the privacy review and whether the same restriction should apply to accent-color: auto as is being considered for AccentColor.
As long as they resolve to the same color at any given time, I think it's ok to expose one of them on a broader set of websites than the other
@LeaVerou could you clarify what you mean by this point? As I understand it, if we limit the exposure of
AccentColorto installed apps to mitigate the fingerprinting risk, we'd need to limitaccent-color: autoin the same way in order to guarantee these use the same color in all cases, unless I misunderstand. Or are you saying that if onlyaccent-color: autois used on a page (and that page doesn't applyAccentColoranywhere), then we could expose it more fully? And if both are used, restrict both? If so, that also could potentially lead to author confusion in some cases.
I’m saying that it should not be possible, in any context, and under any conditions, for the same page to be visibly using two different accent colors at the same time. Whether those are obtained by using the AccentColor keyword, or setting accent-color to something and having native controls adapt. This also applies to AccentColor being used in interpolation, relative colors etc. If authors cannot trust that they won't end up in this situation, they simply won't use AccentColor, so I think that bare minimum should be a hard requirement.
For example, this means:
- If
accent-color: autoresolves to the system accent color, so shouldAccentColor - If
AccentColoris aliased to some default value, that's whataccent-color: autoshould produce as well.
If accent-color: auto resolves to the system color in installed apps, and AccentColor allows you to read that system color, whereas in non-installed apps both resolve to a default e.g. blue, that's fine, since it still maintains consistency within the page itself.
Or are you saying that if only
accent-color: autois used on a page (and that page doesn't applyAccentColoranywhere), then we could expose it more fully?
I think that's a slippery slope. What are you going to do if e.g. JS reads it later? Flip everything to use blue all of a sudden?
In addition to the point above, my personal vote would go towards exposing the system value in all contexts, but I'm not a privacy expert.
Unpopular opinion
Given that at this point users can be uniquely identified by the way they type or their mouse behavior anyway, I suspect the battle to conserve bits of entropy in web platform design (with clear ergonomics and capability tradeoffs) is not going to be seen as a worthy goal for much longer.
I believe that the controls should be able to match the system accent color if the UA so desires (ultimately this is all up to user agent discretion anyway), I don't think the inconsistency would be a real issue.
While I disagree with Lea's preferred outcome, I do agree that this should just be exposed in the default mode.
If the entropy really is unacceptable (there's plenty already exposed) then imo browsers should update their colour pipelines such that system colours can compute to their keywords or to a fake value but paint with their real value. This would probably provide privacy benefits for other existing system colours too.
If the entropy really is unacceptable (there's plenty already exposed) then imo browsers should update their colour pipelines such that system colours can compute to their keywords or to a fake value but paint with their real value.
We had considered this in https://github.com/w3c/csswg-drafts/issues/5710, but from what I recall, we decided against this as a result of the following issue on interpolation support for system colors: https://github.com/w3c/csswg-drafts/issues/5780. We could potentially revisit these, though, if desired
The CSS Working Group just discussed [css-color] Mitigating fingerprinting for AccentColor/AccentColorText.
The full IRC log of that discussion
<fantasai> kyerebo: Issue is, we have AccentColor styling for setting form controls<fantasai> kyerebo: accent-color: auto uses the system accent color
<fantasai> kyerebo: Recently trying to ship AccentColor keyword, should respond to system color
<fantasai> kyerebo: But keyword, because values can be computed and used by script, there was a privacy issue
<fantasai> kyerebo: We can't be exposing this for accent-color: auto
<fantasai> kyerebo: Considering mitigations in Chromium, such as limiting to installed web apps
<fantasai> kyerebo: But problem is that authors may expect them to resolve to the same value
<fantasai> kyerebo: Should we also restrict `accent-color: auto` then?
<ChrisL> Authors would be astonished if they resolved differently, I think
<Rossen3> q?
<fantasai> kyerebo: That's the question.
<weinig> q+
<fantasai> kyerebo: If we don't restrict it, then `accent-color: auto` will use a different value than AccentColor
<fantasai> kyerebo: which would return a system default
<lea> q?
<Rossen3> ack weinig
<fantasai> ydaniv: But if we do restrict it, then a regression of sorts because web apps can no longer match the system accent color
<fantasai> weinig: Did we investigate tainting for colors, similar to images?
<fantasai> weinig: So that if the color is e.g. mixed or whatever, would taint the mixed value
<Rossen3> s/ydaniv: But if we do/kyerebo: But if we do/
<fantasai> weinig: And tainted value would not be discernable from script
<fantasai> weinig: One way to do that would be providing a fake value
<fantasai> weinig: but would need more complex due to things like color-mix() or canvas().
<lea> q+
<fantasai> weinig: If you use tainted AccentColor with canvas, can no longer read the bits
<fantasai> weinig: This is what we do with origin-tainted [missed]
<kbabbitt> s/[missed]/images/
<fantasai> kyerebo: We did consider returning a different value than what is used
<lwarlow> q+
<lea> q-
<lea> q+
<fantasai> kyerebo: but we resolved previously that system colors should compute to themselves
<fantasai> weinig: Problem is that colors these days don't exist in a vacuum
<fantasai> weinig: you can have color-mix() or relative colors, or use colors in <canvas>
<fantasai> weinig: Would have to consider all of these together
<Rossen3> ack lwarlow
<fantasai> lwarlow: My thoughts on this are that, if we can't expose the system accent color because fingerprinting is too bad
<fantasai> lwarlow: I don't think that should result in accent-color: auto being less capable
<dbaron> +1 to lwarlow
<fantasai> lwarlow: Realistically, if approach is "provide a fake color, always use blue", we might as well not ship accentcolor
<florian> q+
<fantasai> lwarlow: Exposing a system color and then never making it do the thing it's meant to do seems wrong.
<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
<fantasai> lwarlow: There's still -webkit-focus-ring which exposes this color in Chrome on MacOS
<dholbert> q+
<fantasai> lwarlow: If we go down the "dont' expose these colors", then we need to actually follow through on that.
<fantasai> alisonmaher: I believe we did roll that back on Chromium.
<fantasai> alisonmaher: so that it's no longer exposed.
<Rossen3> ack lea
<fantasai> lea: Tainting is not that simple, becaue not color itself, but color-mix(), color-extract(), relative colors
<fantasai> lea: color-extract() lets you grab a color component and use it in e.g. variables etc.
<fantasai> lea: I don't have a strong opinion on what to do, but
<fantasai> lea: having accent-color use one color and AccentColor another, this is bad
<lwarlow> q+
<fantasai> lea: I think it's ok if exposed in some contexts and not others, as long as page has one accentColor
<weinig> q+
<fantasai> lea: What if it's UA *MAY* expose the accent color or system color?
<fantasai> lea: But should be hard requirement that these are the same color
<fantasai> lea: less critical for canvas. Most UI doesn't combine canvas and CSS.
<fantasai> lea: but between built-in components and web components, should be able to depend on accent color being the same
<fantasai> lea: Also, wrt can we just not expose as a system color
<fantasai> lea: built-ins also need to access it through appearance:base. Their style needs to be expressable in CSS.
<fantasai> dbaron: My read of current situation is that computed values of system colors compute to color values.
<fantasai> dbaron: we didn't have to do it that way, but been that way for a long time
<Rossen3> ack dholbert
<Rossen3> ack dbaron
<fantasai> dbaron: also means that tainting is easier ot implement and describe, but also more destructive
<Rossen3> q+ dholbert
<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
<fantasai> dbaron: One of the problems there is that you can't expose anything useful in getComputedStyle()
<fantasai> dbaron: I see the problem with both main alternatives brought up originally
<fantasai> dbaron: It's bad to break existing accent-color: auto; feature but also the inconsistency is bad
<Rossen3> ack florian
<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.
<alisonmaher> This was the original issue that was discussed: https://github.com/w3c/csswg-drafts/issues/5710
<fantasai> florian: This exact problem is why I pushed back against accent-color property affecting AccentColor keyword
<fantasai> florian: because it makes it more desirable to use it more often
<fantasai> florian: In some browsers, the color you see is different from AccentColor
<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
<Rossen3> ack dholbert
<fantasai> dholbert: Premise is that developers shouldn't use accent color or read it
<lea> q?
<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
<fantasai> dholbert: There are good reasons to have this info
<Rossen3> ack lwarlow
<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?
<fantasai> lwarlow: That's status quo
<lea> q+
<fantasai> lwarlow: For appearance:auto, browsers can do whatever they want anyway
<fantasai> lwarlow: If they really wanted consistency, they could just set accent-color and then they'll match
<florian> [to dbaron, yes, I was]
<fantasai> lwarlow: Status quo is that it doesn't match. I don't think we should expose it if it doesn't match.
<fantasai> lwarlow: wrt not exposing due to appearance: base ... ideally all those styles should be explainable with CSS
<fantasai> lwarlow: but could it resolve when it's in a UA stylesheet and not in author style sheet?
<fantasai> lwarlow: Though currently no appearance:base style uses AccentColor anyway
<Rossen3> ack weinig
<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
<fantasai> weinig: I don't expect this to be the last time we run into this
<dbaron> s/dbaron's suggestion/dbaron's suggestion about tainting by propagating a computed color plus an additional bit/
<fantasai> weinig: wrt existin system colors resolving to a specific rgb value, those system colors are deprecated because of that behavior
<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
<fantasai> weinig: and the absolutely-resolving system colors can just be legacy behavior
<fantasai> weinig: But experiement of having color + taint bit is a good experiment to see what the cost would be
<fantasai> weinig: that's the only solution if we actually want to match system colors anywhere
<Rossen3> ack lea
<fantasai> lea: wrt status quo, AccentColor wasn't broadly supported so not much status quo
<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)
<fantasai> lea: Multiple acccent colors would be unacceptable to authors
<fantasai> lea: they'd have to set accent-color as a boilerplate always
<fantasai> lea: But you'd need to taint not just colors but also other things given color-extract()
<fantasai> lea: could make it not-tainted in certain contexts, e.g. installed web apps
<fantasai> lea: authors should be able to detect if a value is tainted
<fantasai> lea: and there should be a reasonable default behavior
<fantasai> lea: for where breakage could make things unreadable
<noamr> scribe+ noamr
<Rossen3> ack fantasai
<Zakim> fantasai, you wanted to reply on that
<noamr> fantasai: a reason why the resolve to absolute is to avoid the complexity of maintaining all the channels of color, when mixing them
<noamr> fantasai: very similar to currentcolor
<noamr> fantasai: this was for simplicity of implementation, not having to maintain channels
<ChrisL> Yes that was exactly the reason
<weinig> I think we have gone way past that complexity at this point
<noamr> fantasai: in terms of default, if we were going to paint it it should have a default (blue or other)
<lea> q?
<lea> q++
<lwarlow> +1
<lea> qq+
<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
<fantasai> Rossen3: Time to switch topics. Next steps is continue engage on the issue,
<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
Something we can perhaps consider is to resolve an interpolated color that is a derivative of system colors as some opaque keyword/function (e.g. getComputedStyle(element).color would return something like from-system(12) (or some other system-generated number and whatever function name).
This would be a color function like all the other color functions, and can be mixed and painted with in the scope of the current document. Internally it would represent the actual color rather than the whole chain (which was the issue with #5780).
We should make these colors also taint a canvas they are painted into, in the same way cross-origin no-cors images taint a canvas, so that pixels can't be read from it.
Are we sure canvas is the only exploit angle? Why couldn't SVG filters be used to exploit this?
Are we sure canvas is the only exploit angle? Why couldn't SVG filters be used to exploit this?
I don't think there is a way to read back the pixel output of an SVG filter.
getComputedStyle and canvas pixel read-backs are the obvious exploits. If something else comes up we can look at it in a concrete manner?
https://www.usenix.org/conference/usenixsecurity24/presentation/oconnell is solved?
https://www.usenix.org/conference/usenixsecurity24/presentation/oconnell is solved?
No, we need to consider those timing attacks as well and it should be mentioned in the OP. Tainting canvas or the text representation wouldn't help with timing attacks.