[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 hat use, for example, locally installed Ahem to fail) but the second is hard to test in an automated way.