[css-fonts] Making the font matching algorithm more prescriptive for local fonts

[astearns]

The font matching algorithm currently gives user agents a lot of choices about local fonts:

UAs may choose to expose all installed fonts to the web, regardless of how that font was installed; doing so is likely to have good internationalization properties for users whose primary language is not supported by fonts shipping with their operating system.

UAs may alternatively choose to not initially expose any user-installed fonts to aid privacy on the web; for the set of installed fonts a user has installed is often used as a tracking vector to track users across the web. Users should then be able to add to or remove fonts from that set, according to their needs.

UAs may choose a hybrid approach, where some user-installed fonts are initially exposed for internationalization, but others aren’t. Again, users should be able to customise this starting set.

UAs are expected to make informed decisions on which fonts they expose to the web by default, so as to balance between internationalization and privacy. UAs are expected to also provide a convenient means for users to add and subtract fonts to meet their particular needs.

In addition to the other ways we are looking at to balance internationalization and privacy needs around local fonts, I think we should consider whether we could be more prescriptive and interoperable around local font access.

The current text allows a user agent to not do anything about privacy, or not do anything about giving access to neccessary local fonts. It also has some specifiction about allowing users to opt-in for particular fonts, but as far as I know there are no implementations of this idea.

I’m wondering what it would take to be able to specify something like

UAs MUST NOT initially expose any user-installed fonts, to aid privacy on the web.
UAs MUST provide a convenient means for users to add and subtract fonts to meet their particular needs.

[svgeesus]

I would be in favor of both of those assertions, provided that they get implemented together. The first is easily testable in an automated way (and would also cause all WPT that use, for example, locally installed Ahem to fail) but the second is hard to test in an automated way.

[astearns]

One thing that might make the first requirement easier to accept for all browsers would be to create a new category of user-installed fonts that are known to be necessary (a la #11648 (comment)) and allow those to match. For testing purposes Ahem could be on the list. Then the MUST NOT would only apply to local fonts not on that list.

We would still need to provide the opt-in for other local fonts (the list would never be complete, and users have other reasons for enabling local fonts).

[hober]

UAs MUST provide a convenient means for users to add and subtract fonts to meet their particular needs.

We would object to such a requirement. While it's inappropriate for the CSSWG to mandate UI in general, it's especially inappropriate for the CSSWG to mandate UI that would weaken privacy protections in browsers that have chosen to prioritize it. Even if we already had such a UI ourselves, we would object to a normative requirement to have it.

[astearns]

@hober what about the notion of adding a category of non-system fonts known to be required for people to access content? There must be something we can do to avoid the current situation that amounts to “this is a privacy-focused browser, please use some other browser to access your content”

[svgeesus]

I would also note that

provide a convenient means for users

does not constrain, mandate, or even mention, a UI.

[hober]

I suppose you're welcome to interpret "UAs MUST provide a … means for users to" in some other manner, @svgeesus, but whatever that interpretation may be, it's not the obvious one. I'm afraid my imagination is not up to the task.

[hober]

@hober what about the notion of adding a category of non-system fonts known to be required for people to access content?

Sounds like an idea worth exploring, but it's hard to say how well it would work without seeing it fleshed out more.

[hober]

Another issue with the proposed MUST requirement is that it's impossible to implement on platforms which lack a user-exposed local font installation feature. There are millions of devices in the wild running such platforms. (That is to say, while the strongest RFC 2119 term I would be comfortable with here is MAY, you really ought to be asking for SHOULD, not MUST. MUST is impossible on several platforms.)

[hober]

Taking a step back, I think requiring users to proactively configure something in order to be able to view a website goes against our shared objectives for the web as a platform. Enshrining this particular solution seems like a terrible precedent to set. Any solution needs to be something browsers are comfortable enabling by default, that all users benefit from without them having to take additional steps. In the longer term, we should be looking at enhancements to Unicode, to the fonts bundled with operating systems, to Web Fonts, to Incremental Font Transfer, to the WebExtensions API, etc.

[svgeesus]

Taking a step back, I think requiring users to proactively configure something in order to be able to view a website goes against our shared objectives for the web as a platform.

Absolutely. Especially for pages that have correctly rendered for decades. In general we should avoid this sort of unexpected regression. But when it does happen, at minimum the affected users should have some means to fix it.

Any solution needs to be something browsers are comfortable enabling by default, that all users benefit from without them having to take additional steps.

Agreed. Although "additional steps" is better than "unrecoverable".

In the longer term, we should be looking at enhancements to Unicode, to the fonts bundled with operating systems, to Web Fonts, to Incremental Font Transfer, to the WebExtensions API, etc.

Yes. Unpacking those in order:

• Unicode, which constantly adds new characters. That is a benefit, but it exposes a problem (next item)
• fonts bundled with OS. Where platform-installed fonts are not updated in a timely manner (in some cases, with a decade lag or more). On platforms where users are able to install fonts there is a workaround (user installs newer version) unless the browser chooses to ignore the more recent version.
• Web fonts. In general, new pages should reference webfonts rather than rely on named preinstalled fonts. (Unmaintained legacy content of course won't do that, and still needs to be supported). But for some languages (such as Chinese and Japanese) web fonts have near-zero use because of size. Which leads to
• IFT, where a small subset font is loaded first and then incrementally extended as needed. That copes with the "my Chinese font lacks glyphs for these ten characters that were added to Unicode last year" problem. It also deals with the "this font renders incorrectly for this particular language" problem, when that is caused by static subsetting into multiple fonts.

I'm unaware of how WebExtensions API figures into this, could you elaborate?

[hober]

I'm unaware of how WebExtensions API figures into this, could you elaborate?

For the legacy content case.