[CSS-COLOR-4] Security/Privacy: Incognito mode

[jsalowey]

I've been assigned to security review this document. There are some potential fingerprinting issues with respect to system-colors and color-profiles. Should there be specific recommendations for handling these in incognito mode?

[svgeesus]

We are aware of fingerprinting issues with system colors. Could you outline the fingerprinting issue with color profiles?

[jsalowey]

Correction, color-profiles is more of a tracking risk than fingerprinting.

I think the fingerprinting risk from color profiles is low, but it may depend upon the implementation behavior. For example, if some implementations build-in some profiles then perhaps there would be a way to determine what the built-in profiles are (perhaps through timing). I think this risk is low, but would need more privacy review.

[tabatkins]

That seems to be a generic "what properties/values/etc are supported by this browser" info leak, right? That's completely unavoidable, and would be similarly exposed by any other newish feature with varying support, across the entire web platform.

Or is there something specific to color-profiles you're seeing here?

[mallory]

I also reviewed this from a privacy perspective, and I think a reliance on color-profiles reduces the issue with system colors. For example if system colors is overly uniquely specified, then fingerprinting and security attacks increase. But if users are encouraged to choose from a standard set of color-profiles to fulfill their needs, eg accessibility, dark mode, etc, then they're less likely to come up with entirely unique settings.

[tabatkins]

Color profiles and system colors are completely unrelated, unfortunately. Color profiles are about specifying a colorspace, so you can say color(foo 1 .5 0) and the browser knows how to turn that into a color it can display. It's not a set of colors forming a "profile".

[x-Jake-x]

Here are my thoughts:

As far as color-profiles mentioned here go, they allow for an src. In an "incognito mode", to avoid fingerprinting (I do not completely understand how this is different from tracking), a UA should be sure to request these resources newly with each session rather than rely on a cached resource that could potentially identify a user. As I assume that already happens in icognito mode, I wonder if it even needs to be said, but there it is.

i.e., the draft gives this example:

@color-profile --fogra55beta { src: url('https://example.org/2020_13.003_FOGRA55beta_CL_Profile.icc'); }
.dark_skin { background-color: color(--fogra55beta 0.183596 0.464444 0.461729 0.612490 0.156903 0.000000 0.000000); }

It is entirely possible that example.org/whatever.icc is actually a resource on a remote server that is generated dynamically when this request is made. If a user is expecting privacy, then it seems to me that the correction action would be to request the resource once for each session, which would make the UA say "This user hasn't been here before."

Just going to assume webpages here to make the rest of these thoughts easier, but...
If a dynamic page is loading and the remote server detects that no request was made for the resource, it would be easy enough for it to say "This resources wasn't requested. Perhaps this person has been here before. Let me run this detection algorithm..."

Now, how does this fit in specifically to color profiles rather than this resource being like any other in incognito mode?

color() = color( [ [<ident> | <dashed-ident>]? [ <number-percentage>+ | <string> ] [ / <alpha-value> ]? ]# , <color>? )

We know from the color-profile draft, color() also accepts a string as part of the arguments to reference a color. Specifically saying:

or a <string> giving the name of a color defined by the colorspace.

Assuming that the issue here is indeed privacy and/or security, --fogra55beta as defined by the dynamically generated remote resource ICC profile above could include a series of color keywords and one could reference those keywords on a page. Let's say that it defines the color dark-skin as a keyword in its colorspace definition and that it maps to the aforementioned example values. However, being a dynamically generated resource, one person may have dark-skin mapped to the equivalent of

color(--fogra55beta 0.183596 0.464444 0.461729 0.612490 0.156903 0.000000 0.000000);

in the colorspace, and another may have it mapped to the equivalent of

color(--fogra55beta 0.183597 0.464444 0.461729 0.612490 0.156903 0.000000 0.000000);

(without defining each color specifically in CSS). These differences may not necessarily be visible to the naked eye as an "easy alert".

Now, when the UA goes to display the webpage, if for any reason it uses a cached version of the ICC profile, the page being displayed could technically detect the actual displayed color for an element and map that color to a previous visitor.

For very large numbers of users, this isn't necessarily a huge issue (although it could be combined with a pooled IP to generate larger variations on the detected differences in a geographic location, at which point it becomes a bigger issue...), but for a smaller user base, this tagging could be easily abused.

I don't have a solution for this outside of the use of non-caching in incognito mode. ICC profiles can sometimes be large, from what I hear.

Outside of incognito mode, perhaps vendors could only allow profiles loaded from known good resources (color.org? printer vendors? monitor vendors? seems like a big list to maintain...) and warn a user that an unverified resource request is being made, offering to accept all future requests from that resource.

Or perhaps we could disallow the use of <string> outside of predefined colorspaces, as it appears to me that all other parts of color() are constant or calculated.

On a related note, rather than using a different <string> in a malicious cached ICC definition, the colors in that definition could contain subtle-enough differences that if used on a device that where they are out-of-gamut, the gamut-mapping of the device could map the out-of-gamut colors to different subtle colors in the UA, which could then be read by a page as an identifier, so I guess removing <string> wouldn't be a real solution in that case...

Since IP mapping isn't one-to-one, it does seem to me that this provides a security or privacy concern as it is possibly an additional way to track a user with a finer level of detail from a pool of users.

[svgeesus]

Tab is correct, system colors are likely to resolve to sRGB colors set by the browser or OS (or, rarely, by the user).

Now, when the UA goes to display the webpage, if for any reason it uses a cached version of the ICC profile, the page being displayed could technically detect the actual displayed color for an element and map that color to a previous visitor.

the gamut-mapping of the device could map the out-of-gamut colors to different subtle colors in the UA, which could then be read by a page as an identifier

How would you go about doing that, in script? The computed value, read back from the CSS OM, would be dark-skin in both cases. Could you give an example of cross-site scripting that can read a color from the screen?

[x-Jake-x]

The concern I described isn't from cross-site scripting, but the site itself loading a malicious color profile. In order to read the color from the screen after using a color keyword, something like the following could be employed: https://jsfiddle.net/fcn9jk3z/

However, the draft specifies using a string giving a color name defined by the color space. The only type of color profile loading that is described is loading an ICC profile, so I assume (possibly incorrectly) at the moment that is the only type of color profile that can be loaded. I do not know what other profiles exist besides this format or how those profiles would describe color names using strings.

I have tried to research, and I could not find any data relating to using color keywords from an ICC profile, or whether an ICC profile is even capable of supporting such keywords. I suppose that particular hypothetical vector must be moot in this case, but I'm glad it was at least explored.

The out-of-gamut mapping issue for a remote resource ICC profile is still a possibility, but I suspect that browsers as user agents will only end up mapping to rgb() (per the example in the jsfiddle), so that type of fingerprinting/profiling is also limited in how many people it could track. I won't go so far as to say that it is completely out of the question though.

[tabatkins]

The concern I described isn't from cross-site scripting, but the site itself loading a malicious color profile. In order to read the color from the screen after using a color keyword, something like the following could be employed:

I believe you're describing a persistent-identifier attack, smuggled via the browser's cache for the referenced color-profile file, right? Deliver a detectably-unique ICC file to each user, then later check the results to see if it's a previously-detected user.

Given that this depends on a malicious script and ICC file, tho, how is this different from just sending a unique script file with a user identifier in it? Cache-clearing should wipe out both of these anyway, right?