W3C home > Mailing lists > Public > public-css-archive@w3.org > October 2020

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

From: x-Jake-x via GitHub <sysbot+gh@w3.org>
Date: Tue, 06 Oct 2020 07:30:29 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-704087200-1601969427-sysbot+gh@w3.org>
> 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?

I think a few things here:

1) Cache-clearing *should* wipe both of those out, but since this is specific to incognito mode, I wonder if it needs to be said explicitly that color profiles loaded in CSS need to be wiped (or loaded fresh) during the session. Just to say that we reviewed it and recognize it. Maybe not though if this is generalized behavior.

2) General OS/browser/anti-malware things ("protection services"?) look for malignant scripts these days if they are configured to do so, but I doubt that a single one of them would understand a malignant color profile. Like you said though, since it is as simple as an identifier, the protection service wouldn't be able to recognize such a thing as malignant anyway. That's why I mentioned using a trusted source for color profiles, but...it'd be terribly autocratic to mandate such a source, so...perhaps that's moot.

3) see below

> It reads the computed value from the DOM.

Thank you for the clarification! As you can see from the (to rephrase) "earlier defined syntactic form", the browser provides a way to get the computed color specifically for the reserved color names. To make an assumption, one might want to read the computed value of a colorspace color in order to manipulate it in some mathematically relevant way. Thinking that the browser wouldn't provide a way to get the mathematical value of "Deep Pink" in the future seems a bit limiting to me, as it would not be easily manipulable.

After reading these, however:

https://github.com/w3c/csswg-drafts/issues/3847 (references fingerprinting)

It is obvious to me that this situation is not unique in its security concerns.

The draft says that:
> color() values: The computed and used value is the color in the specified colorspace, paired with the specified alpha channel (defaulting to opaque if unspecified).

Considering that `hsl` resolves to `rgb`: https://jsfiddle.net/fbwoet3v/

And that the draft also says that:
> system colors: Each <system-color> keyword computes to itself. Its used value is the corresponding color in its color space.

In order to achieve what you are describing @svgeesus, I would think that to maintain consistency in its definitions, the draft would have to be changed to read something like:

> color() values: Each colorspace color() value computes to itself. Its used value is the color in the specified colorspace, paired with the specified alpha channel (defaulting to opaque if unspecified). Its actual value is the gamut-mapped representation appropriate for the output medium upon which it is used.

But considering that the predefined colorspaces currently compute to `rgb`, this would necessarily result in treating custom colorspaces differently than predefined colorspaces as far as their compute values in order to prevent the type of fingerprinting and/or tracking mentioned previously.

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 6 October 2020 07:30:31 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:20 UTC