- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Nov 2020 17:17:18 +0000
- To: public-css-archive@w3.org
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> <dael> Topic: [css-color-4][css-color-adjust-1] Shielding system colors to avoid fingerprinting<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5710<br> <dael> fantasai: We were going over the privacy considerations for color adjust<br> <dael> fantasai: main issue was way system colors were exposed through systemColor keywords or when we force b/c gCS returns used value rather than computed<br> <leaverou> q+<br> <dael> fantasai: Three options. 1) can't fix. 2) computed value gets returned not the used. Not sure webcompat implications. 3) return a value to gCS which is not nec the value actually used<br> <chris> q+<br> <Rossen_> q?<br> <leaverou> q-<br> <dael> fantasai: Could return the same standard values. For forced colors return the color that would have been the color before we forced<br> <astearns> s/CSS Contain/CSS Scoping/<br> <dael> fantasai: Question is do we want to do something like that? Upside is reduce fingerprinting. Down is if author wants to do something based on system colors they can't do calculation based on that<br> <dael> chris: I fairly recently added something for deprecated system colors which was mandatory mapping to non-deprecated. I'm not sure if that helps but it would mean used color would be same as a non-derecated colors<br> <Rossen_> q?<br> <dael> fantasai: This is about non-deprecated. It reduces number of keywords but problem still exists<br> <fantasai> s/It/That/<br> <emilio> ack chris<br> <leaverou> if you're interested in web compat, system colors are only used in 0.2% of pages (any system color)<br> <dael> Rossen_: With options 2 & 3 I'm curious if system colors will be that useful at that point. Lot of guidance on how to use system colors, esp in settings of forced colors where people encouraged to use system colors elsewhere if they take colors in their own hands<br> <emilio> q+<br> <dael> Rossen_: With that in mind I'm not sure how attainable 2 and 3 will be from author capability<br> <dael> fantasai: Can still use system color, just can't use a variation on the system color. You can't compute a value based on actual value<br> <dael> Rossen_: That was my point<br> <dael> chris: I think that's reasonable. I don't see call to modify system colors. Point is they're semi-standard. If you change no benefit over spec directly<br> <dael> leaverou: I checked web compat and system colors are only in 0.2% of pages in http archive<br> <dael> Rossen_: That's quite a bit<br> <Rossen_> ack emilio<br> <dael> emilio: I was going to point out opposite. Probably we cannot change. We need to return an actual color. Even though not used explicitly they're used by default in UA. Pretty sure people look at gCS on a select and expect a color back<br> <smfr> q+<br> <iank_> q+<br> <leaverou> There is also data per color here: https://docs.google.com/spreadsheets/d/1sMWXWjMujqfAREYxNbG_t1fOJKYCA6ASLwtz4pBQVTw/edit#gid=279222916<br> <dael> Rossen_: Related, if we restrict system colors to keywords only would using them as part of a color function still function?<br> <dael> TabAtkins: Yeah. Exposing actual color to scripts is the thing. Using them is fine<br> <Rossen_> ack smfr<br> <chris> system colors only used for links now, https://drafts.csswg.org/css-color-4/#sample<br> <dael> smfr: If you ahev special behavior for system colors you have to track through color modifications like lighter and darker. You'd have to mask it all the way through<br> <dael> TabAtkins: Yep. Similar to :visited which is tricky<br> <dael> chris: We changed user stylesheet for light/dark. Only three uses remain ^<br> <Rossen_> ack iank_<br> <chris> q?<br> <dael> iank_: I wanted to say I'm a little concerned about compat situation of changing gCS. As a webdev I did see code which would explicitly read out the color from gCS to determine if a11y mode is on. Some investigation would have to check if major web properties broke under a11y modes with this change<br> <dael> TabAtkins: Ultimately if we say no it's okay. It just needs to be doc as a fingerprinting risk. If we're okay with it we can leave as is. It's the only fingerprinting surface in the spec<br> <dael> iank_: Not saying no, saying compat risk<br> <dael> florian: Given these are maintained they could switch. If they are not there's something you need<br> <florian> s/something you need/a risk indeed/<br> <dael> Rossen_: Sounds like there's go with option 1 which is say no and document the fingerprinting or take another option based on additional research and experimentation<br> <dael> Rossen_: As a group are we comfortable with option 1? Objections to say no change on this and we'll document the fingerprinting exposure?<br> <dael> smfr: I need to talk to privacy people before I agree<br> <dael> Rossen_: In that case we'll leave it open as is. In both cases we need more data before we resolve<br> <dael> Rossen_: smfr can you follow up and we bring it back next week?<br> <dael> smfr: Sure.<br> <dael> Rossen_: Let's do that. We'll give the Apple folks a week and depending on how things go we may pick option 1<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-725549630 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 17:17:20 UTC