- From: Noam Rosenthal via GitHub <sysbot+gh@w3.org>
- Date: Tue, 04 Feb 2025 11:43:07 +0000
- To: public-css-archive@w3.org
noamr has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-fonts-4] Detection-prevention approach to the local font privacy issue == Looking at #5421 and #11571, it seems like a lot of the discussion assumes that privacy and i18n needs are a zero-sum game when it comes to local fonts. Perhaps this is not a given, and we can find a win-win solution that doesn't compromise either? The privacy issue around local fonts doesn't come from the fonts being *renderable*, but rather from the local availability of the fonts being *detectable* by the document. See https://github.com/jakesmo/fingerprintjs2/blob/master/fingerprint2.js for how this is used: - iterate over a list of known local fonts - render a `<span>` with that font - compare that span's width with a known width - repeat What if, instead of making those local fonts unavailable altogether, we'd make them indistinguishable from an equivalent cached web font? Something along the lines of the following: - Every local font has to have an equivalent web-font URL - Setting a style to access a local font is *always asynchronous*, and is delayed heuristically to have similar delay to a cached web-font alternative - We can add a heuristic that local fonts required for text drawn below the fold or occluded is delayed significantly if the font is accessed for the first time. - We can either mandate that those web-font alternatives are specified in the descriptor, or have some stock list of local->web font mapping Looking at existing fingerprinting code that uses local fonts (e.g. https://github.com/jakesmo/fingerprintjs2/blob/master/fingerprint2.js), a solution along these lines would make that style of fingerprinting very expensive and feasible in a much smaller number of cases. * This approach might need a lot of fine tuning, and is intended as a starting point for looking at this issue from the detection angle rather than from the availability angle * I'm aware that some local fonts don't have an equivalent web-font alternative, but many do, and perhaps this can solve 80% of the issue and we can go from there? Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11648 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 4 February 2025 11:43:08 UTC