Address issues around reliance on locally installed fonts

[asankah]

We should consider the existence of legacy websites that ask users to install a font in order to display their content correctly. These sites may not migrate to web fonts anytime soon. At the same time we don't want to break them.

While their prevalence is being measured, we should acknowledge their existence and propose mitigations that smudge the identifiability of such fonts. E.g. by having the UA know about popular fonts that are typically only installed locally, and map them to equivalent web fonts.

[astearns]

When we discover situations like this, why not allow those particular local fonts to be used? I don't understand the value of mapping to 'equivalent' web fonts here.

[tabatkins]

Yeah, to the extent that we can discover these and don't expect a webfont migration, I expect these can be considered for inclusion in the cross-browser "allowed local fonts" list (which is then auto-installed by browsers).

[astearns]

If that's the case, then we're back to maintaining a list. So at that point the main difference between this proposal and what's being discussed in https://github.com/w3c/csswg-drafts/issues/4497 is the caching strategy?

[tabatkins]

Not quite. I think we hope that licensing issues can be ironed out to allow browsers to install the same set of local fonts across OSes, so they're actually dependable to web authors.

[Crissov]

As far as I understand the current text, e. g. this part:

Browsers will only allow use of pre-installed fonts in places like the @font-face src: local() function and the font-family property

this would disable users from manually caching fonts, which they encounter either frequently or rarely but then are a huge WOFF download, by installing the respective OTF/TTF to their local OS, because they would now be considered second-class citizens, being labeled as “user-installed” which currently is not distinguished from “pre-installed” (at least not on the app level where the browser lives).

[tabatkins]

This is correct.

[jyasskin]

As @asankah alluded to, we will have to measure how many users manually cache fonts in the way @Crissov says. @Crissov, do you have a sense for how many users you'd be willing to break?

[astearns]

I think there are (at least) two separate classes of users to consider here.

The first (and likely most important) is a set who use websites with content that requires particular fonts, where there's a pre-webfont workflow established with local font installs. Hopefully we can identify most/all of the sites and scripts in this set and merely add these local fonts to the allowed list.

A second set are people who find and install local fonts in order to avoid WOFF downloads. For these people, I expect a browser pref that lets them opt-in to using all of their local fonts for some or all of the domains they visit will suffice.

[jyasskin]

I agree with the two classes of users. We'll still need to pick a threshold number of users it's ok to break. For the first set, there are likely to be some locally-installed fonts that we can't add to the allowed set, either because we can't find them at all or because we can't get licenses to auto-install them. For the second set, not all users will find the browser pref.

[astearns]

I'm not sure what you mean by "can't add to the allowed set."

If (for example) the Klingon community has a mass of websites that expect people to have the "pIqaD" font installed, and those sites currently work fine for those users (and would fail without the local font), then user agents should continue to allow access to local "pIqaD" fonts.

[jyasskin]

Ah, so, if there are some people who have "plqaD" installed, and some who don't, and the browser allows more than one site to detect that, that's at least a bit of fingerprinting information. Right now, this explainer plans to eliminate all fingerprinting information beyond the (locale/browser/OS) triple. We could instead plan to allow N bits, where N<<log2(sizeof(locale/browser/OS)), which probably only allows 1 to several fonts per triple, depending on those fonts' arrangement in users' clients. If there are 20 fonts in a locale that have a mass of websites that depend on them, we'll have to break some of those users.

Maybe we'll get lucky, and the measurement @asankah's team is working on will discover that each locale only has 1 critical font, in which case I'd argue it's reasonable to allow it. I'm not expecting us to get that lucky.

[astearns]

I guess I have been thinking of this work as being harm reduction more than harm elimination.

I also think we are not going to be lucky for all locale/browser/OS combinations, and that we'll find some combinations where we will not be able to avoid allowing some font fingerprinting leakage. But most locale/browser/OS combinations should be OK with a strict ban on local fonts. Being able to eliminate font fingerprinting for most is worthwhile, and can be done while we work on a more complete fix.

[Crissov]

I assume that the part of the print industry that uses X/HTML+CSS to PDF/ebook/image converters relies on support for arbitrary local fonts. If such converters use existing browser engines under the hood – and some do – care must be taken that they can still use any OTFs/TTFs they want. CSS authors may not have the knowledge or license privileges to copy fonts from the global font folder into their project folder, where they could be used without local().

[jyasskin]

@Crissov I think that use case will need a new API. https://github.com/inexorabletash/font-enumeration/blob/master/README.md starts discussing it, but I think we should also consider something more like <input type=font> or https://github.com/WICG/contact-api.

[tabatkins]

In comments from Richard Ishida (https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594008044, https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594507775, https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594521142), he lays out some reasonable arguments for allowing people to purposely opt in to exposing particular local fonts they want a page to be able to use.

Something like the Contact Picker API could work: it lets us scope the exposure to particular origins that request it, rather than increasing their fingerprinting surface for all sites.

We should make sure to capture this as a goal, I think.