Re: [csswg-drafts] [css-fonts] incorporate mitigations for font based fingerprinting (#4055)

So I just had a discussion with @jschuh to figure out some further details beyond what I discussed during TPAC. Here's our (Chrome's) current thoughts on the matter:

1. For the [explicit enumeration of local fonts API](https://github.com/w3c/css-houdini-drafts/issues/951), we want to **only expose system fonts** by default.
 * If the user has given explicit signals that they've trusted the site with their identity, such as installing the site as a PWA or the browser detecting that the user has logged into the site, we intend to allow enumeration of all local fonts by default; you can't identify the user much *more* at that point. Exactly what triggers this condition is up for revision as time goes on.

2. To support the middle ground of non-trusted sites that still want [font data](https://github.com/w3c/css-houdini-drafts/issues/950) from local fonts, we want an API (`<input type=font>`, or a DOM API call that pops up a font chooser) that lets the user explicitly choose a single font to expose. (This is akin to `<input type=file>`; enumerating the user's filesystem is clearly terrible, but letting the user affirmatively provide a single file is clearly totally OK.) We'll pursue this separately as another spec proposal.

3. For more general font usage, such as in 'font-family', we are **not** interested in locking down access to only webfonts and local system fonts; there are important usability and a11y concerns, as expressed in this thread and in the TPAC discussions, for allowing pages to use local fonts beyond the system ones.

    However, to deal with bad actors using this access as a back-door for font enumeration/fingerprinting, we're actively working on a [Privacy Budget](https://github.com/bslassey/privacy-budget) system, in which "how many fonts is this page accessing" will be counted (among many other things). A page cycling thru a large number of fonts will burn thru their budget quickly, at which point further fingerprintable APIs will stop working (or become very noisy/generic) until the user gives explicit permission to continue. 

Privacy Budget satisfies my concerns, expressed during TPAC, that trying to solve privacy issues with one-off restrictions won't work, and even with coordinated efforts across the web platform you'd need harmfully-draconian restrictions to have even a chance of protecting privacy. We believe the Privacy Budget framework is the correct way to address fingerprinting concerns going forward.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4055#issuecomment-535727663 using your GitHub account

Received on Thursday, 26 September 2019 23:57:04 UTC