- From: pes10k via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Dec 2023 23:54:04 +0000
- To: public-css-archive@w3.org
This text does not address the privacy concern. Unless im looking at the wrong version, this text just makes the existing privacy problem more explicit; that the defined behavior could be used to harm user privacy and its up to vendors to figure out how to implement the spec w/o the privacy harm. In order for the privacy concern to be addressed, it it should be the case that a correct and complete implementation of the standard ensures that the defined functionality is privacy preserving; not just that a vendor could implement it in such a way that it could be privacy preserving. I appreciate the importance of the I18n issues here, but I think its critical to find a way to address those concerns _without_ risking user privacy. FWIW, heres another suggestion you all may have already considered and discarded (but maybe not!): discarding the OS vs installed distinction, and instead limiting the number of font-faces that an site / eTLD+1 can reference within the lifetime a storage partition. Like i said, maybe you all have considered and discarded the idea, but this kind of "budgeting approach" might be successful for fonts in a way I dont think its practical for addressing fingerprinting concerns in general (for example, benign font-face selection might be consistent in a way that a sites overall "set of Web APIs used" is not). -- GitHub Notification of comment by pes10k Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5421#issuecomment-1871630599 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 December 2023 23:54:06 UTC