[css-color-4] Prevent fingerprinting with deprecated system colors

[AmeliaBR]

In #3804, we agreed to un-deprecate system colors that have important use cases for accessibility (high contrast mode) and dark mode theming.

I'd like to suggest that the spec get more strict about what "deprecated" means for the remaining colors. Specifically, user agents should not expose any user-specific data through the deprecated color names; they should standardize the values for these colors so that they can't be used as fingerprinting data. The colors could still be adjusted for browser & OS, with light & dark mode variants, since that doesn't expose any new information relative to what's already exposed by user agent strings and media queries.

Of the colors that we are keeping deprecated, the problematic one that I know of is Background. In the spec, this is the "desktop background". On my windows system, both Firefox and EdgeHTML do expose my custom OS desktop background color. Chrome instead exposes my custom OS theme accent color. Which are sufficiently different that I can't see any user benefit from theming to match my colors, but I can see a significant fingerprinting vector.

PS, Codepen with all the system colors & their definitions, on various colored backgrounds, if you want to poke around to see what is being exposed for you

[svgeesus]

related to #3847

[tabatkins]

Agenda+ to see if we can upgrade the current text "encouraging" either using static defaults or mapping to the undeprecated system colors to being a MUST.

[css-meeting-bot]

The CSS Working Group just discussed Prevent fingerprinting with deprecated system colors, and agreed to the following:

• RESOLVED: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests for them

The full IRC log of that discussion

<dael> Topic: Prevent fingerprinting with deprecated system colors
<dael> github: https://github.com//issues/3873
<dael> AmeliaBR: Already in fonts 4 there's a vague warning about how system colors have some fingerprinting potential b/c they review user settings
<dbaron> I'm getting basically unusable audio via WebEx
<dael> AmeliaBR: I think browsers haven't followed up with changes. I suggest now that we have a decision on which system colors are useful for a11y and which are legacy we go one step further and say UI should not expose any fingerprintable data in the deprecated ones
<dael> AmeliaBR: Esp true b/c some deprecated ones are so vague that hte data from browsers can't be used in a useful way.
<dael> AmeliaBR: CHange from vague wording to normative requirement. These colors would still have to result in a reasonable value, but that should be determined by nothing more than the combo of UA and OS. It shouldn't have any individualized colors.
<dael> fantasai: Not quite
<dael> fantasai: Also consideration in cases where can map toa user color they should do that
<dael> fantasai: If you map all background to canvas that seems reasonable
<dael> AmeliaBR: Okay.
<dael> AmeliaBR: You suggest that the deprecated ones could be consistently mapped to one of the theme colors we are undeprecating. As long as UA is consistent not addtional fp
<dael> dbaron: One notes is there was comment about how not defined well. We do know how to define them well. I tried to propose the defintions ~17 years ago. WG wasn't interested in better definitions
<dael> TabAtkins: WE accepted the definitions at least 6 years ago. They're in spec
<dael> dbaron: I think some, not sure if all
<dael> TabAtkins: All ones in email we found when we transferred to github are in the spec. If you've got more, great, we're glad to take them
<dael> AmeliaBR: Might not be definitions, but that no one updated implementations. There are one sentence definitions, not sure when added
<dael> AmeliaBR: Background is one I brought up with different results between browsers about which OS theme was exposed
<dael> TabAtkins: Chrome is nonsensical on background.
<dael> TabAtkins: I'm hapy with this sort of change. We mandate deprecated system colors most not be more user specific then good colors. THey must map to good colors or is not user specific. I'd be happy to do that and spec in more detail how they work and what should look like.
<dael> TabAtkins: Given current lack of interop it's not like anyone is depending on them so might as well give reasonable definition for browsers.
<dael> TabAtkins: Sounds good to me all around
<dael> chris: Sounds good if browsers will do it
<dael> TabAtkins: No one uses the colors because no one can use them so they're not high to work on. But they're good first blood for someone to work on a browser. So I'm happy to give definitions so that it can be done
<dael> myles: web platforms need motivation
<dael> AmeliaBR: Making this normative and with tests are the keys to get browsers to change
<dael> TabAtkins: Unless we mandate what the colors or mappings are I don't see how to test besides run this on 2 machines and see if it's different and that's not something test engine can do
<dael> AmeliaBR: Good point. Testing isn't set for you to control OS settings. And even then we don't know which expose the fingerprint
<dael> AmeliaBR: If we normatively say these colors must not be certain values or must match a non-dprecated keyword we can test. Might get false passes on a default install that doesn't have user customizations
<dael> chris: [missed]
<dael> TabAtkins: I'm fine with specific colors. I want one for light and one for dark
<dael> chris: White and black!
<dbaron> clearly the default set of colors should be whatever those colors were in the default theme of Windows XP :-)
<dael> Rossen_: This was stated as something used for FP for people with a11y needs?
<dael> AmeliaBR: Not jsut a11y. Certain system colors have a11y needs but that's separated. We have list of undeprecated ones with use cases. THis is ones still deprecated. Some expose user theme settings
<dael> TabAtkins: Not a11y. It's a fingerprinting vector with no gain
<dael> Rossen_: I want to separate and make sure rest [missed]
<dael> TabAtkins: She's saying previously mix of used for a11y and just legacy. a11y ones are separated out. The remaining only exist for backwards compat. We can remove fingerprinting there because there's no value to them. THey have no reason to be user dependent
<dael> AmeliaBR: THey are FP risk for everyone. Ones we're keeping for a11y benefits they still have a FP risk but enough benefit to justify the risk. These have no benefit to jsutify the risk
<dael> Rossen_: That's fine. I think we're still abusing user a11y here but keep going
<dael> TabAtkins: Prop: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests
<dael> many: sounds good
<dael> Rossen_: Objections?
<dael> RESOLVED: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests for them
<dbaron> Worth noting that some UAs might want to make different fingerprinting tradeoffs for the nondeprecated ones.

[fantasai]

Dropping a note here to say: don't forget to say how these values compute, if they compute to other keyword values or to a fixed color or to themselves. (I'm guessing fewer keywords that compute to themselves here is better for implementations.)

[tabatkins]

Depends on whether we want them to respond to color-scheme or not.

[AmeliaBR]

Depends on whether we want them to respond to color-scheme or not.

Given that these are legacy values for legacy compat & we don't want authors using them in new content, we can probably safely define them all as light mode values. If you want to use system colors in a dark mode theme, only use the non-deprecated values.

But, there should probably be a clear warning to authors about that!

[tabatkins]

Yeah that sounds reasonable.

[svgeesus]

OK so concretely: does this need a survey of what each browser does on each platform, to see if there is any commonality?

Or do we just pick "reasonable" colors and everyone returns those values?

[svgeesus]

Allright, no-one had any suggestions so:

• anything to do with borders is mapped to ButtonBorder because that is the only non-deprecated border color
• backgrounds are mapped to Canvas
• text names are mapped to CanvasText
• ThreeDFace is mapped to ButtonFace
• oh and InactiveCaptionText is mapped to GrayText because it is inactive

and all of that is MUST.

Will browsers sign up to implement these changes so that the deprecated system colors are consistently anti-fingerprinting on all browsers on all platforms?

[css-meeting-bot]

The CSS Working Group just discussed [css-color] Prevent fingerprinting with deprecated system colors, and agreed to the following:

• RESOLVED: Accept the mappings in https://github.com/w3c/csswg-drafts/issues/3873#issuecomment-713658800

The full IRC log of that discussion

<emilio> Topic: [css-color] Prevent fingerprinting with deprecated system colors
<emilio> github: https://github.com//issues/3873
<TabAtkins> https://github.com//issues/3873#issuecomment-713658800
<TabAtkins> ^^^ his mapping
<astearns> need a resolution on all of https://github.com//issues/3873#issuecomment-713658800
<emilio> chris: I made specific mappings from deprecated to non-deprecated system colors
<emilio> ... so I think that's enough to close the issue
<emilio> Rossen_: do we need resolution?
<chris> These mappings https://drafts.csswg.org/css-color/#deprecated-system-colors
<emilio> RESOLVED: Accept the mappings in https://github.com//issues/3873#issuecomment-713658800