Re: [csswg-drafts] [css-color-4][css-color-adjust-1] Shielding system colors to avoid fingerprinting? (#5710)

This is a summary of the state of the CSSWG discussion:

The CSS system colors, in forced colors mode, are required to match the user-required colors so that the page can style itself in that color scheme. They also are required to change based on color-scheme, so that the default text and background colors match the user preference.

The used values of these colors are exposed via getComputedStyle(), which creates a privacy leak.

Note that the following information is already provided explicitly via Media Queries:
- Whether forced colors mode is on
- What color scheme the reader prefers
    
Thus the additional privacy leak presented by getComputedStyle() is not of a new type of information, but rather merely a greater amount of information for users that are already segmentable via MQs.

There are three ways forward here:
1. Continue to return the used valuse in getComputedStyle().
2. Return the system color keywords rather than the colors themselves.
3. Lie about the colors in getComputedStyle().

For the case of :visited, we took approach (3).
- First, because it was a much more severe data leak (of the user's browsing history).
- Secondly, because the impact of lying about :visited colors by returning :link colors is not very severe. Because :link and :visited are almost always styled very similarly in terms of color contrast, even if the author calculates some colors to use based on the returned :link color rather than the true :visited color, the text is most probably still readable.

But for the case of forced colors and color schemes, this approach is much more dangerous to the readability of the page. If the page believes itself to be rendered as dark text on a white background, but the system forces it to white text on a black background without, and the author calculcates custom color variants based on its own colors rather than the true colors, the page could become unreadable. Note that while the author can guess that this has happened for the page overall by combining the prefers-color-scheme media query with the forced-colors media query, these queries will only tell the author about the contrast nature of the Canvas and CanvasText colors, and not of button colors or other elements on the page, whose contrasts could be inverted.

Meanwhile the concern about option (2) is that, because of the existence of color schemes, all of the elements on the page are now expressed using system colors in the default UA stylesheet, whereas before they were all expressed as absolute colors. Because of this history of absolute colors returned by getComputedStyle(), the Web expects getComputedStyle() to return absolute colors for any element styled in its default colors: changing it to return keywords is therefore likely a change that we cannot make without breaking many pages.

The current conclusion of the CSSWG is thus that we believe that the risk of breaking pages (either via JS errors or by unreadable colors) for users employing forced colors is greater than the harm from increased fingerprinting entropy for those users.

We submit this analysis for review by Accessibility, Privacy, and the TAG.

-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5710#issuecomment-840772752 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 13 May 2021 19:11:42 UTC