System Colors should explicitly allow for spoofing

[annevk]

https://www.w3.org/TR/css-color-4/#css-system-colors is not exactly clear that a user agent can, for privacy reasons, decide not to expose a particular color to avoid the end user being targeted or fingerprinted through that color.

[emilio]

cc @svgeesus (see discussion in WebKit/standards-positions#136 for context)

[svgeesus]

@emilio thanks!

@annevk wrote:

Given that we seem to reach different conclusions reading the same specification I opted to file #9373.

So there is currently no consensus on how to approach this? Some people want to return hard-coded values (which are then useless and misleading, eg in color-mix() others want an @supports query to return false (meaning the OS is not going to tell them what the color is) which does seem more reasonable but may not be Web-compatible.

[emilio]

I think implementor wise the consensus is the former. They're not useless, they just don't expose the OS preference directly. It's still an accent color for example.

[svgeesus]

I added this, how does it look:

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.

I think that this still allows testing, things like system-color-consistency are verifying internal consistency, not color matching with user preferences.

[svgeesus]

@emilio @annevk does that capture implementer consensus?