Re: [csswg-drafts] [CSS-COLOR-4] Security/Privacy: Incognito mode (#5553)

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('');
.dark_skin {
  color(--fogra55beta 0.183596 0.464444 0.461729 0.612490 0.156903 0.000000 0.000000);

It is entirely possible that 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 ( 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.

GitHub Notification of comment by x-Jake-x
Please view or discuss this issue at using your GitHub account

Sent via github-notify-ml as configured in

Received on Tuesday, 29 September 2020 12:19:34 UTC