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

The CSS Working Group just discussed `[css-color-4][css-color-adjust-1] Shielding system colors to avoid fingerprinting?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-color-4][css-color-adjust-1] Shielding system colors to avoid fingerprinting?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5710<br>
&lt;dael> chris: Looks like nobody is in favor of close as is<br>
&lt;dael> chris: Other options are lie in the OM. If you've got another color scheme OM will say it's the standard. Preserves privacy but means you can't do anything clever if someone has a pallate and you want to do some coloring. If you need adaptations those won't work<br>
&lt;dael> florian: Was there another option?<br>
&lt;dael> chris: There were 3 but I've forgotten the middle one.<br>
&lt;dael> chris: Can someone read fantasai's second option?<br>
&lt;dael> TabAtkins: 1 is don't fix, 2 is we return computed value not used value. 3 is just lie<br>
&lt;dael> chris: Keyword seems fine. I don't know how compat that is with deployed content<br>
&lt;dael> TabAtkins: Problem is canvas bg color is a system color across browsers. Text too. Behavior change in any default colored text. Without fixing that this is a no go. Most text would show as canvas not blakc<br>
&lt;dael> chris: Yes<br>
&lt;dael> chris: What is impact of lie in OM?<br>
&lt;dael> TabAtkins: Existing visited tags are bad. I don't know if they get more bad.<br>
&lt;dael> chris: We have something that says all others deprecated get you an undeprecated one. That's a type of lying<br>
&lt;dael> fantasai: Sort of but not liying about color used. Difference between them is in general links are viisted or unvisited. When we're lying we're saying it's unvisited color. That doesn't end in author trying to calculate a contrasting color<br>
&lt;dael> fantasai: Generally slight change in color. If author calc against visited color they won't come up with one that won't work. Here if page syas I'm black text on white background and system comes up with white text, balck BG you get an unreadable page<br>
&lt;fremy> ^ I strongly agree with fantasai here<br>
&lt;dael> chris: Given everything comes doesn to canvas bg and text those are supposed to react to dark/light mode changes.<br>
&lt;dael> fantasai: It might not be exactly those colors<br>
&lt;dael> fantasai: And while light/dark mode will tell you canvas text vs canvas it won't tell you button colors. You won't know if they're inverted.<br>
&lt;dael> TabAtkins: I think fantasai makes a great point. Lying is more technically difficult and when it comes up will be worse UX. I suspect we want to do something fancy for root and otherwise go with returning system color. That will let people know there is a system color and they can use color modifications instead of calc directly<br>
&lt;smfr> q+<br>
&lt;dael> TabAtkins: Worse case code falls over b/c gets a string instead of rgb. That's better than black text balck bg<br>
&lt;dael> fremy: Then you have to keep track. If you have a color function. you have to keep track of it. You'd need to pass flag everywhere<br>
&lt;dael> smfr: Can't you detect color by using it as fill in canvas and reading back? Or do you have to take canvas as well<br>
&lt;dael> leaverou: Sounds messy<br>
&lt;smfr> s/take canvas/taint the canvas/<br>
&lt;dael> TabAtkins: We lie throughout the thing and render colors worthless for almost everything or we close no change. Doesn't sound like anything in middle is a useful result<br>
&lt;dael> chris: Some objections to close no change from privacy but they weren't aware of ramifications of others<br>
&lt;dael> TabAtkins: If they think there's something smart on the table this is worth solving. But it's not solvable w/o breaking the feature<br>
&lt;dael> chris: TabAtkins you mentioned somethign smart with canvas text and bg? What was that?<br>
&lt;dael> TabAtkins: Tracking and returning sytem color keywords which is complicated on canvas. If it was from root canavs or canvas text return black or white. Even that's not correct. Still exposes some colors. I could see a slight fancy way but it's patching over issues and the attempted solution is bad<br>
&lt;fantasai> It was a web-copat mitigation for returning keywords from gCS<br>
&lt;dael> astearns: Sounds to me like we're down to lying in gCS is the way to avoid privacy risks, but we don't want that.<br>
&lt;dael> TabAtkins: And by don't want, it would give users bad results and be very complicated to impl<br>
&lt;dael> astearns: What if chris or TabAtkins put a comment in this issue outlining the problems we see with lying in gCS and as for privacy to re-review as to if the drawbacks to the solution are worth mitigation<br>
&lt;dael> chris: Sounds good<br>
&lt;dael> fantasai: Also worth talking to a11y folks b/c they're the ones effected<br>
&lt;dael> astearns: Outline options and drawbacks, submit for re-review<br>
</details>


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


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

Received on Wednesday, 27 January 2021 17:16:28 UTC