[css-fonts-4] Privacy and I18n issues around user-installed fonts, and user selection of them

[r12a]

10.3. Preinstalled Fonts and User-Installed Fonts
https://drafts.csswg.org/css-fonts-4/#preinstalled-and-user-installed-fonts

User Agents may choose to ignore User-Installed Fonts for the purpose of the Font Matching Algorithm.

!!!! This will create consternation for a great many international users around the world. A huge number of people use languages which are not supported, or are not supported well, by preinstalled fonts. The almost universal approach, currently, for people who use less common or endangered languages on the Web is to find a page where someone has created a font (and often keyboard) that you are expected to download in order to see or create content. (Those fonts are often used by applications other than browsers, too.)

Furthermore, quite often there are also particular font styles that content authors want to see used, often contrastively, and there's a likelihood that a user will have installed additional fonts (such as using a Kano font for Nigerian ajami text, or a Mool font style to distinguish Khmer headings, etc.) in order to make the text readable/locally relevant. For many languages, the system may provide a Noto font, but usually only the one (and generally the Noto fonts don't reflect the design users would want to see for their text, since it focuses on producing Noto-harmonised, large, sans-serif, monoline glyphs).

Of course, this plays into the issues related to privacy, but if the motivation for the sentence is that, it should say so, at least. But that discussion is not yet concluded, so in the meantime the i18n WG would like to see that sentence removed.

[xfq]

If I remember correctly, the font based fingerprinting discussions started last year, but this text has been in the spec for at least 2 years. Perhaps it's for another reason?

[astearns]

@litherum knows better, but my understanding is that this sentence was added mostly to describe reality - in that Safari had already implemented this behavior and continues to behave this way. The subsequent fingerprinting discussion has happened in part to figure out how to address problems with this behavior.

Two of the suggestions we have considered are:

1. Allow some User-Installed Fonts to match for particular languages where many web pages depend on them
2. User agents that have this font-matching behavior MUST provide UI to let the user opt-in to User-Installed Font matching

Would either or both of these requirements make the behavior more acceptable to the i18n WG?

[r12a]

Safari had already implemented this behavior

But Safari is only one of the 3 main browser engines, so i don't believe the spec should reflect that approach yet, because it doesn't represent reality. (And btw, i am no longer able to use or recommend Safari for a deal of multilingual content for this reason, esp. when it concerns support for endangered scripts or scripts that people are promoting for wider use. Which is a nuisance, since it writes off use on iPads and iPhones as well as desktop.)

(1) above sounds problematic because i don't believe it's possible to create and maintain in a timely fashion a centralised list that will respond to the needs of the content developers, especially for endangered and long-tail scripts. Installing fonts currently avoids that problem, of course.

(2) Is a given, to my mind, if any restrictions are to be placed on ability to render user-installed fonts, but it adds complications for non-computer-literate users that it must be easy for them to understand how to work around.

However, both of those are solutions to a problem that we don't yet have, since the majority of major browser engines do not restrict visibility of user-installed fonts. So if we are to describe reality, we should remove that sentence. If we are to describe some future possibility, which to my mind is not yet certain enough to include in the spec, then such a statement must be accompanied by another that says that users must be able to work around the restriction when needed.

[astearns]

One argument that (2) could be an acceptable workaround is that someone who can figure out how to install a font can likely figure out how to change a browser preference.

And one of the options we have discussed for (1) is to flip the maintenance requirement. So we would allow a UA to ignore user-installed fonts ONLY for languages where it can be demonstrated that available OS fonts are adequate for displaying web content.

[litherum]

Web fonts are the only sure way for a web author to use these less-supported languages. Naming a specific font and hoping the user has it installed is less likely to work than using web fonts.

There’s a trade-off here. International support is clearly important, but privacy is also definitely important. Different UA’s policies have different implications for different users. I chose the word “may” here on purpose, simply to describe the trade-off. There are many different points on the spectrum between blocking fonts for privacy and allowing fonts for internationalization, and all of those points have reasonable arguments for them, based on the specific considerations of the UA and their users.

The sentence “User Agents may choose to ignore User-Installed Fonts” is true (de facto). We shouldn’t remove it from the spec.

[svgeesus]

Web fonts are the only sure way for a web author to use these less-supported languages.

In general, using a Web font is more reliable provided the license allows such use. This is not the case for all fonts, including some which are "free to use" but are required to be distributed in an intact zip file with a readme and license, for example.

Naming a specific font and hoping the user has it installed is less likely to work than using web fonts.

It is a very poor approach for Latin, agreed.

It is the standard approach in some linguistic communities, because they came onto the Web well before Web fonts were a realistic thing to use. Thus, user-agents which suddenly stop working on content which has worked for one or two decades will simply be seen as broken.

[r12a]

we would allow a UA to ignore user-installed fonts ONLY for languages where it can be demonstrated that available OS fonts are adequate for displaying web content.

What is the criterion against which you'd measure adequacy? I'm not sure how that would work.

Here are some additional thoughts about things that concern me...

Web fonts are the only sure way for a web author to use these less-supported languages.

I'm curious about how you reached that conclusion. Do you base this on experience, or is it a logical deduction based on the assumption in the sentence "Naming a specific font and hoping the user has it installed is less likely to work than using web fonts."? I ask because, as someone who has worked with a wide range of less-supported languages on a daily basis for several years, it doesn't match the reality that i experience. In fact, it appears to be the opposite.

Less-supported languages typically have only a small number of freely available Unicode fonts, and those are often obtained by users from the Web. Users expect to use them with applications such as text editors or for texting, as well as for Web pages, and they are therefore often packaged along with keyboards. Webfonts are not useful for those scenarios. It's very rare for such packages or download locations to serve the user with a webfont. Webfonts are a tool for content authors, not for users.

It may be possible to persuade content authors to create and use webfonts for new content, but they aren't going to help with the content that's currently out there.

Not that webfonts are a panacea, anyway. They require additional bandwidth, when people using less-supported languages may find that a problem. And for documents containing multiple languages that can sometimes mount up.

Access to user-installed fonts can also give the user the flexibility to set preferred fonts as the default. For example, i've just been writing about the Javanese script as used for the Javanese language. There is a Noto font for Javanese, although it has some bugs still, but it also uses a noto-harmonised style that doesn't look like normal Javanese book fonts (although a recent redesign now at least makes it possible to actually read the letters). Otherwise, there is very little to choose from wrt Javanese fonts. That I know of, the only font that actually works well and looks the way i'd expect is Yogyakarta. It's all rights reserved, so i can't as a content author create a webfont for it. I can, however, prepend it to my CSS font-family values so that those who also happen to have it can also obtain the benefits of a well designed font, rather that having to settle for an alternative system font.

At the very least, browsers shouldn't block content authors from trying out different fonts they have installed while developing their content. Even if they are going to send the content out with a single webfont, they need to be able to experiment quickly with alternatives in order to choose that font. Compiling system fonts into webfonts and incorporating into the content for testing out the effect is way too slow. Localhost and file URLs should be exempt from these restrictions, since there is no privacy risk there anyway.

[css-meeting-bot]

The CSS Working Group just discussed Spec should not allow UAs to ignore user-installed fonts, and agreed to the following:

• RESOLVED: Add explanatory text about tradeoffs on blocking local fonts, particularly wrt i18n considerations

The full IRC log of that discussion

<fantasai> Topic: Spec should not allow UAs to ignore user-installed fonts
<r12a> https://github.com//issues/5421
<fantasai> github: https://github.com//issues/5421
<fantasai> r12a: Chris says I'm arguing quite well, not sure I am, but I do have this bad feeling about not allowing people to use system fonts at all
<fantasai> r12a: And that feeling gets worse when dealing with minority scripts, which I do every day
<chris> locally installed fonts
<fantasai> r12a: If there's a mechanism to allow people to use particular system fonts, that's not so bad
<myles> q+
<fantasai> r12a: But it's coming across as a blanket refusal to allow any system fonts, and that worries me
<fantasai> r12a: Similar topic in severa threads at the moment
<fantasai> r12a: Also worried people might assume that, e.g. if you have a Noto font on your system, then you're fine for Javanese or Tai Tam, or whatever, and that's not the case.
<fantasai> r12a: ? very substantially changed the font as of this September
<chris> s/?/Google
<Rossen_> q?
<florian> s/?/adlam/
<fantasai> r12a: These things happen, people need access to fonts immediately, even if not system fonts
<fantasai> r12a: Particularly for people developing stuff in localhost or file-based URIs
<fantasai> r12a: Having to create a webfont just to test the font and see what it looks like is very awkward
<fantasai> r12a: I don't think local files should be covered
<fantasai> r12a: So those are some of my thoughts
<Rossen_> ack myles
<fantasai> s/allow any system fonts/any local non-system fonts/
<fantasai> myles: I think we're more in agreement than not, actually
<fantasai> s/particular system/particular local/
<fantasai> myles: I want to bring up some subtlety
<fantasai> myles: Allowing user-installed fonts is good in some cases and bad in others
<fantasai> myles: Spectrum, you could allow all fonts all the time, or disallow all user-installed fonts all the time
<fantasai> myles: But examples
<chris> xfq not exactly, by local fonts we mean both
<fantasai> myles: Maybe you're in a locale, and there's a font users install, everyone has that font and it's what allows that script to be rendered
<fantasai> myles: That's not a case where fingerprinting is such a big problem
<r12a> q+
<fantasai> myles: What places are fonts allowed vs not allowed?
<fantasai> myles: User agents and users can have the ability to pick where in the middle of those things they want to fall
<chris> see https://drafts.csswg.org/css-fonts-4/#preinstalled-and-user-installed-fonts
<fantasai> myles: Right now Safari has picked a place in that specture. Other browsers have picked other places along that spectrum.
<fantasai> myles: What I think spec should say isn't that one extreme is right or other is right
<fantasai> myles: Spec should say there are pros and cons to places on this spectrum, and UA has to pick the best place it can
<fantasai> myles: That's why I picked the word "may", which indicates UA-discretion
<fantasai> myles: Wanted to bring up two other points
<chris> local() is a way to access local fonts so that a) you can add descriptors and b) you can rename them and c) add them into composite fonts
<fantasai> myles: Earlier this week, Open UI meeting where I brought up idea of a font picker that would explicitly allow users to punch through this policy
<chris> q+
<fantasai> myles: allow particular user font on the web page, user can pick the font and it becomes available to the web page
<xfq> https://www.w3.org/TR/2020/NOTE-PFE-evaluation-20201015/
<fantasai> myles: Also workin W3C Web Fonts WG, want to allow fonts to download only the parts of the font the browser needs
<fantasai> myles: So makes the web fonts more usable in more contexts
<fantasai> myles: There are other efforts in the user-installed fonts world, trying to find more specific places on the spectrum, different from allow everything vs disallow everythng
<fantasai> myles: This is a place where users and UAs can pick what makes sense for them
<Rossen_> ack myles
<fantasai> r12a: Maybe part of the problem is that we're not discussing things in the middle much, so this is interesting
<fantasai> r12a: I also wanted to say that, you'd mentioned if there's only one font available, then that's not a problem for fingerprinting
<fantasai> r12a: There was a key proposal
<fantasai> r12a: One key issue, if you are localized in Burma and using Ryohinga font and that's the only on your system
<fantasai> r12a: You are more identifiable
<myles> q++
<chris> yes, identification of ethnic minorities
<myles> qq+
<fantasai> r12a: than you were before when you had a larger list of fonts available
<Rossen_> ack r12a
<Rossen_> ack +
<fantasai> r12a: Big problem for me remains though, Safari, I can't use it anymore for the stuff that I do
<fantasai> r12a: I can't use my iPad or my iPhone either
<fantasai> r12a: Because there's no escape hatch at the moment
<fantasai> r12a: That's why I'm worried about this "may".
<fantasai> r12a: You can stop everyone from using user-defined fonts if you want to, seems a bit dangerous to me
<fantasai> r12a: People likely to do that without understanding the consequences
<Rossen_> ack myles
<Zakim> myles, you wanted to react to myles
<fantasai> myles: Everybody may, "everybody" doesn't appear in the spec
<fantasai> myles: Maybe we can solve the issue by putting more explanatory text
<fantasai> myles: Instructions helping UAs pick a good place for themselves on the spectrum
<fantasai> myles: Want to address case of user with only one font intstalled on the system
<fantasai> myles: case was actually, only one font for a script, and all users of that script have that font installed
<florian> q+
<fantasai> myles: For that user, things like Accent-Language header would already expose info
<fantasai> myles: Main point is, anyway, there's a spectrum
<chris> https://drafts.csswg.org/css-fonts-4/#font-taxonomy
<fantasai> chris: First, since confusion of terms
<fantasai> chris: system font vs local font
<Rossen_> ack chris
<fantasai> chris: I hear r12a saying shouldn't do something unless understand the consequences, and myles saying ...
<fantasai> chris: What about saying SHOULD NOT
<addison> q+
<fantasai> myles: SHOULD NOT implies directionality, and we should not use SHOULD NOT because one side of this spectrum isn't objectively better than the other
<Rossen_> ack florian
<fantasai> florian: I'm hearing Myles's point.
<astearns> q+
<fantasai> florian: I'm a bit uncomfortable
<myles> q+
<fantasai> florian: When Safari stopped supporting local fonts, it stopped passing a large part of WPT tests, because used local version of Ahem
<fantasai> florian: We have access to the source, so we fixed that
<fantasai> florian: but for awhile everyone using "Ahemese" could not read any pages
<chris> Yes there is a lot of existing, old content that will break
<fantasai> florian: r12a couldn't work on stuff
<addison> q-
<fantasai> florian: ..
<Rossen_> ack myles
<fantasai> florian: If r12a can't work, minority groups can't use the internet
<fantasai> myles: Safari isn't done with this problem
<fantasai> myles: If you want to use a user-installed font in Safari, it's possible. You turn the font into a base-64 URL and put it into your user style sheet
<fantasai> r12a: That works if you're a content developer, but not as a user
<chris> qq+
<fantasai> myles: It does work for users, it's in the Safari preferences
<Rossen_> ack chris
<Zakim> chris, you wanted to react to myles
<fantasai> chris: Myles, they could also download the source of every web page and edit it, but that's not a real solution
<fantasai> astearns: One thing that comes to mind is, we had this one line in the spec
<fantasai> astearns: And it raised concerns about its effects
<Rossen_> ack astearns
<fantasai> astearns: We've discussed ways of ameliorating those effects, by having a font picker, by having some way to opt in
<fantasai> astearns: Can we agree that line of text, without a way to work around it, was premature?
<fantasai> astearns: From standards perspective we should opt-in scenarios before allowing this
<fantasai> astearns: You MAY do this IF you allow these other ways of opting back in
<chris> that would work for me
<addison> +1 for alan's comment
<Rossen_> ack fantasai
<fantasai> fantasai: Couldn't Safari have a UI that allows the user to opt into a font or set of fonts?
<fantasai> fantasai: Because that would solve the minority scripts problem
<fantasai> fantasai: It's unlikely that Safari would know all the fonts that are critical in such a way, but the user could know
<fantasai> myles: That's a possibility
<fantasai> myles: Responding to Alan's point, if MAY was premature, if we take it out, it would be undefined
<fantasai> myles: Because this is such an open-ended space, I don't think we can say "you should do this if XYZ", because many places in the spectrum
<fantasai> myles: Maybe come to happy medium by adding explanatory text, and allow UAs to pick for themselves
<chris> User agents that wish to prioritize privacy over internationalization may choose to ... provided they provide a means to ...
<florian> q+
<fantasai> astearns: If we have this, shoudl have some language saying that "UAs may do this, but there must be a method to opt back into loading local fonts"
<fantasai> r12a: plus pros and cons
<fantasai> Rossen_: Can we resolve anything ?
<fantasai> myles: Can probably resolve on adding explanatory text
<fantasai> RESOLVED: Add explanatory text about tradeoffs on blocking local fonts, particularly wrt i18n considerations
<fantasai> florian: I would like this to be normative in the "you may ignore these things as long as you provide an opt-out"
<fantasai> florian: UAs are user agents, and could pick a different "agent"
<fantasai> florian: But on some operating systems, you don't actually have a choice
<fantasai> florian: of user agent
<fantasai> florian: And if that UA doesn't want to allow an opt-out, then you're stuck
<fantasai> florian: Can't force anybody's hand, but I think it would be a better balance
<fantasai> chris: I agree
<fantasai> +1 from fantasai
<Rossen_> ack florian
<r12a> +1 too
<Rossen_> ack fantasai
<addison> +1 from me;
<chris> Some of this can go in the security & privacy appendic. and some in the internationalization considerations section
<fantasai> fantasai: Agree to require an opt-out, so that the user can opt into using a font on a website so that they can read it
<chris> but the normative part needs to be in the main body of the spec
<fantasai> myles: We have the user agent stylesheet hack
<fantasai> florian: It counts, you're not blatantly violating the spec, but clearly not in line with the spirit
<myles> s/hack/option/
<fantasai> Rossen_: If this is something we need more time on, maybe we can find another slot for the joint group?
<fantasai> Rossen_: a few more font issues as well

[astearns]

@litherum the only way I personally would consider your user stylesheet hack to be sufficient is if the user agent automated it for the user. It would be fine to have it as the mechanism for opting in, but there would need to be relatively-simple UI presented to the user.