[css-fonts-4] Detection-prevention approach to the local font privacy issue

[noamr]

Looking at #5421 and #11571, as well as the F2F, 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
• Remove tha <span> so that it's not visible to the user (this is crucial)
• 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 such as the above, a solution along these lines would make that style of fingerprinting very expensive and much less utilizable, and can we tweaked further for the more difficult cases in the future.

• (I'm not set on the particulars of this solution, but I believe that a solution in that direction can be tweaked to something that works)

[noamr]

/cc @astearns @svgeesus @pes10k @r12a

[svgeesus]

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?

That would be ideal, of course.

I agree that (largely as a consequence of the extensive discussion between the two horizontal groups) this is currently framed as an inherently at-odds situation which is solved by users adjusting a single slider on a privacy-I18n axis.

@drott @jfkthame @hober @fantasai for additional input.

Thanks so much @noamr for suggesting this new option to explore!

[svgeesus]

• We can either mandate that those web-font alternatives are specified in the descriptor, or have some stock list of local->web font mapping

This strikes me as the part that needs the most fleshing-out before it could be experimentally tested. The rest of it looks straightforward, and likely to work.

[jfkthame]

• Every local font has to have an equivalent web-font URL
  ...
• We can either mandate that those web-font alternatives are specified in the descriptor, or have some stock list of local->web font mapping

Given that one of the important use-cases for local fonts is to allow users access to fonts that support uncommon languages and writing systems, including perhaps those that are under ongoing development, I don't think we can realistically handle this by just providing a predefined list of local->webfont mappings. Web authors and users need to be able to specify and use fonts that we as standards authors and browser developers have never heard of; that perhaps did not even exist at the time we created our "stock list".

So that suggests the "equivalent web-font" needs to be specified by the author. This is exactly what an author can already do using src:local(...) in an @font-face rule, followed by a fallback src: url(...) alternative; the only difference seems to be the proposal that access to the local font should be made asynchronous, with similar timing to what a cached webfont resource would have.

However, I don't think this works to prevent fingerprinting, because a malicious site that wants to use local fonts as a fingerprinting vector can simply provide the wrong URL for the webfont source. (How would the browser know?) Then the page will trivially be able to tell whether a local font or the (completely different) webfont was used.

[noamr]

• Every local font has to have an equivalent web-font URL
  ...
• We can either mandate that those web-font alternatives are specified in the descriptor, or have some stock list of local->web font mapping

Given that one of the important use-cases for local fonts is to allow users access to fonts that support uncommon languages and writing systems, including perhaps those that are under ongoing development, I don't think we can realistically handle this by just providing a predefined list of local->webfont mappings. Web authors and users need to be able to specify and use fonts that we as standards authors and browser developers have never heard of; that perhaps did not even exist at the time we created our "stock list".

Agreed, but those uncommon fonts are also less likely to be useful for fingerprinting at scale.
With the async approach to loading fonts, "trying" all the possible uncommon fonts on an invisible span is something that can be made to take a very long time, rendering this fingerprinting technique less compelling.

So that suggests the "equivalent web-font" needs to be specified by the author. This is exactly what an author can already do using src:local(...) in an @font-face rule, followed by a fallback src: url(...) alternative; the only difference seems to be the proposal that access to the local font should be made asynchronous, with similar timing to what a cached webfont resource would have.

We could use that "wrong" font as the local font next time for that origin, or do something like quickly download some of the metrics for the font to compare, or avoid rendering this local font for this origin going forward? Origins that use valid URLs for their font won't suffer from this. I'm sure we can come up with solutions to some of these problems.

[astearns]

Web authors and users need to be able to specify and use fonts that we as standards authors and browser developers have never heard of; that perhaps did not even exist at the time we created our "stock list".

Agreed, but those uncommon fonts are also less likely to be useful for fingerprinting at scale.

Also, the list could be improved over time. Once we had the feature in place to make use of an initial list, it would be very easy to add new entries to make this mechanism that more effective.