- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Oct 2019 16:16:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Prevent fingerprinting with deprecated system colors`, and agreed to the following: * `RESOLVED: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests for them` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Prevent fingerprinting with deprecated system colors<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/3873<br> <dael> AmeliaBR: Already in fonts 4 there's a vague warning about how system colors have some fingerprinting potential b/c they review user settings<br> <dbaron> I'm getting basically unusable audio via WebEx<br> <dael> AmeliaBR: I think browsers haven't followed up with changes. I suggest now that we have a decision on which system colors are useful for a11y and which are legacy we go one step further and say UI should not expose any fingerprintable data in the deprecated ones<br> <dael> AmeliaBR: Esp true b/c some deprecated ones are so vague that hte data from browsers can't be used in a useful way.<br> <dael> AmeliaBR: CHange from vague wording to normative requirement. These colors would still have to result in a reasonable value, but that should be determined by nothing more than the combo of UA and OS. It shouldn't have any individualized colors.<br> <dael> fantasai: Not quite<br> <dael> fantasai: Also consideration in cases where can map toa user color they should do that<br> <dael> fantasai: If you map all background to canvas that seems reasonable<br> <dael> AmeliaBR: Okay.<br> <dael> AmeliaBR: You suggest that the deprecated ones could be consistently mapped to one of the theme colors we are undeprecating. As long as UA is consistent not addtional fp<br> <dael> dbaron: One notes is there was comment about how not defined well. We do know how to define them well. I tried to propose the defintions ~17 years ago. WG wasn't interested in better definitions<br> <dael> TabAtkins: WE accepted the definitions at least 6 years ago. They're in spec<br> <dael> dbaron: I think some, not sure if all<br> <dael> TabAtkins: All ones in email we found when we transferred to github are in the spec. If you've got more, great, we're glad to take them<br> <dael> AmeliaBR: Might not be definitions, but that no one updated implementations. There are one sentence definitions, not sure when added<br> <dael> AmeliaBR: Background is one I brought up with different results between browsers about which OS theme was exposed<br> <dael> TabAtkins: Chrome is nonsensical on background.<br> <dael> TabAtkins: I'm hapy with this sort of change. We mandate deprecated system colors most not be more user specific then good colors. THey must map to good colors or is not user specific. I'd be happy to do that and spec in more detail how they work and what should look like.<br> <dael> TabAtkins: Given current lack of interop it's not like anyone is depending on them so might as well give reasonable definition for browsers.<br> <dael> TabAtkins: Sounds good to me all around<br> <dael> chris: Sounds good if browsers will do it<br> <dael> TabAtkins: No one uses the colors because no one can use them so they're not high to work on. But they're good first blood for someone to work on a browser. So I'm happy to give definitions so that it can be done<br> <dael> myles: web platforms need motivation<br> <dael> AmeliaBR: Making this normative and with tests are the keys to get browsers to change<br> <dael> TabAtkins: Unless we mandate what the colors or mappings are I don't see how to test besides run this on 2 machines and see if it's different and that's not something test engine can do<br> <dael> AmeliaBR: Good point. Testing isn't set for you to control OS settings. And even then we don't know which expose the fingerprint<br> <dael> AmeliaBR: If we normatively say these colors must not be certain values or must match a non-dprecated keyword we can test. Might get false passes on a default install that doesn't have user customizations<br> <dael> chris: [missed]<br> <dael> TabAtkins: I'm fine with specific colors. I want one for light and one for dark<br> <dael> chris: White and black!<br> <dbaron> clearly the default set of colors should be whatever those colors were in the default theme of Windows XP :-)<br> <dael> Rossen_: This was stated as something used for FP for people with a11y needs?<br> <dael> AmeliaBR: Not jsut a11y. Certain system colors have a11y needs but that's separated. We have list of undeprecated ones with use cases. THis is ones still deprecated. Some expose user theme settings<br> <dael> TabAtkins: Not a11y. It's a fingerprinting vector with no gain<br> <dael> Rossen_: I want to separate and make sure rest [missed]<br> <dael> TabAtkins: She's saying previously mix of used for a11y and just legacy. a11y ones are separated out. The remaining only exist for backwards compat. We can remove fingerprinting there because there's no value to them. THey have no reason to be user dependent<br> <dael> AmeliaBR: THey are FP risk for everyone. Ones we're keeping for a11y benefits they still have a FP risk but enough benefit to justify the risk. These have no benefit to jsutify the risk<br> <dael> Rossen_: That's fine. I think we're still abusing user a11y here but keep going<br> <dael> TabAtkins: Prop: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests<br> <dael> many: sounds good<br> <dael> Rossen_: Objections?<br> <dael> RESOLVED: We come up with a set of mandated color mappings for deprecated system colors, put in spec, and write tests for them<br> <dbaron> Worth noting that some UAs might want to make different fingerprinting tradeoffs for the nondeprecated ones.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3873#issuecomment-547988167 using your GitHub account
Received on Wednesday, 30 October 2019 16:16:36 UTC