[css-color] Mitigating fingerprinting for AccentColor/AccentColorText

[josepharhar]

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.

[emilio]

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).

[clshortfuse]

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.

[josepharhar]

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?

[alisonmaher]

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.

[lukewarlow]

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.

[alisonmaher]

@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.

[josepharhar]

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?

[emilio]

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.

[josepharhar]

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.