[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.

[litherum]

I'm particularly troubled by @astearns's comment in #5421 (comment) about the original edit being premature.

Previously, the spec said nothing about the set of exposed fonts. Adding the sentence "User Agents may choose to ignore User-Installed Fonts" didn't actually change anything - user agents were already free to ignore these fonts because nothing was defined before. The edit takes something that was entirely undefined and simply calls out the fact that it was undefined. I wouldn't call this "premature." I would call it "toothless."

One valid criticism would be that the original edit doesn't describe the fact that there are many different places in the middle of the spectrum of [forbid all user-installed fonts, allow all user-installed fonts] that UAs can choose, and that these places are (generally) more valuable than either of the extremes. Saying "UAs may pick one extreme" doesn't capture this nuance. Fixing this is an improvement to the spec, and is the resolution the group just agreed on.

[litherum]

I made a pull request with proposed text. Please take a look! #5625

[astearns]

The spec said nothing, but there was (and is) a common understanding that user agents could and would match user-installed fonts. Yes, this was under-specified. But we had rough interoperability on user-installed fonts until WebKit changed. Adding the possibility that user-installed fonts could be ignored was a new thing.

Since the edit was pointed out, we have had lots of discussions about the benefits and drawbacks of what’s in the spec. I think there is consensus that allowing a user agent to ignore user-installed fonts with no usable opt-in is too extreme. I do think the current MAY statement was premature, because it explicitly allows that extreme behavior.

So I support the edit you have made. And I support continuing to discuss usable opt-in scenarios so we can get back to having a normative statement we can all agree on.

[litherum]

@astearns

there is consensus that allowing a user agent to ignore user-installed fonts with no usable opt-in is too extreme.

I don't agree with this. WebKit is certainly interested in refining its balance between internationalization and privacy, but that isn't the same as saying no UA should ever pick either of the extremes. Some UAs have very strong internationalization goals, and other UAs have very strong privacy goals.

I would agree with you if some content was becoming unreadable for no benefit. But there is a benefit here, and so it becomes a cost/benefit analysis problem. All options should be on the table, even if we expect that most UAs won't choose one of the options.

[r12a]

For me, i think it comes down to this: User agents may pick a position along the internationalisation<->privacy tension line to propose to the user by default, but they shouldn't take decisions for the user that the user can't easily change.

And in the case of fonts, although an all-on/all-off switch might be useful too, i think this generally means the user being able to choose which user-installed fonts work on a font-by-font basis.

One problem is that the user is not likely to be aware what font the content author is trying to apply. That's why i had suggested elsewhere an approach like we have for cookies, that warns the user if the page is trying to use a font that is not already enabled by them, and asks then remembers whether they want to enable it for this and future pages.

[svgeesus]

@r12a there was a proposal by @felipeerias did you see it?

#4497 (comment)

It seems to satisfy the "user can easily change" aspect that you mentioned; I particularly liked the per-site/everywhere option. It also makes fingerprinting slower, even if the user has authorized a large number of fonts.

[r12a]

Oh, i thought i had replied to this long ago. The proposal by @felipeerias very much reflects what i had already proposed, and my reasoning in proposing it, so yes i'm interested in further discussion around that. (I did actually say that in the other thread a year ago.)

[litherum]

If I understand correctly, striking that sentence doesn’t affect UA behavior, conformance, or test pass rate. Therefore, it would be an editorial change.

Given that it’s an editorial change, I think it’s valuable to remind the user in different points in the spec document about things they may be interested in. Indeed, readers of specs rarely read every section in the whole document. Therefore, I think it would be better to reword that sentence to better encapsulate the privacy-fidelity tradeoff, rather than strike it entirely.

[svgeesus]

Therefore, I think it would be better to reword that sentence to better encapsulate the privacy-fidelity tradeoff, rather than strike it entirely.

Do you have suggested wording, which @r12a could then review? I feel we could be close to closing this long-running issue.

[litherum]

I think what I'd propose is:

1. It doesn't make any sense to discuss this in the taxonomy section. I think the taxonomy section should just simply describe, well, taxonomy, rather than its implications on other algorithms. Therefore, I think we should replace both "The set of installed fonts available in the Font Matching Algorithm is explicitly undefined" and "User agents may choose to ignore User-Installed Fonts for the purpose of the Font Matching Algorithm" with "Please see Font Matching Algorithm for a description of how user-installed fonts may interact with the font matching algorithm.

2. Add a paragraph to 5. Font Matching Algorithm that describes the tradeoff. Something like:

The set of installed fonts available to the Font Matching Algorithm is explicitly undefined.

Note: 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 expose 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. UAs may choose a hybrid approach, where some user-installed fonts are exposed for internationalization, but others aren't. UAs are expected to make informed decisions on which fonts they expose to the web, so as to balance between internationalization and privacy.

[svgeesus]

I agree about moving much of this from taxonomy, but prefer to use the actual text (currently in taxonomy) which was proposed and agreed; your proposal misses out several points that were important in the discussion and requested by several people.

[svgeesus]

@r12a @xfq could you check the changes made here satisfy the concern raised in this issue?

[r12a]

The large initial change block seems to be heading in a useful direction. However, the 3rd option (hybrid approach) assumes that the UA implementer is able to choose adequate fonts to be exposed for a language on behalf of the user.

UAs are expected to make informed decisions on which fonts they expose to the web, so as to balance between internationalization and privacy.

I don't see how they can possibly do that in a way that meets user's requirements. I still think that if a UA is going to prevent use of installed fonts, then the user needs to be able to unblock those fonts if they wish. The user also needs to be able to view text in fonts that the UA implementer has never even heard of. And it also doesn't address the need i mentioned earlier for content developers to be able to view content in whatever font they want in situations that are not security risks, such as reading a file from their own hard disk or local server while creating content.

(Slightly tangiential, but indicative of the problems we are opening the door for here is that users should also be able to overwrite or delete any font that is pre-installed, too. For example, Kashmiri users can't currently use Safari because they need access to very recent versions of nastaliq fonts like Noto in order to correctly write their language (and fix the non-standardised and ugly hacks that users have resorted to so far), but macOS won't allow a new version to delete or overwrite the pre-installed version. This is really preventing users from creating readable content. See also an example of the problems caused for many writing systems for users of Firefox on the mac, for similar reasons.)

[svgeesus]

Thanks for the detailed feedback @r12a, let's keep working to resolve this.

[svgeesus]

@r12a

I still think that if a UA is going to prevent use of installed fonts, then the user needs to be able to unblock those fonts if they wish.

Please take a look at d7193b9 where this is made explicit.

Slightly tangiential, but indicative of the problems we are opening the door for here is that users should also be able to overwrite or delete any font that is pre-installed, too.

Not that tangential; the wording I just added talks about removing as well as adding fonts from the initial default set provided by the UA. Removing from a set used for rendering seemed a better way to express it than "must allow uninstalling".

[r12a]

LGTM, thanks.

[svgeesus]

@pes10k could you look over

• 5. Font Matching Algorithm
• 10.3. Preinstalled Fonts and User-Installed Fonts

from a privacy perspective?

[pes10k]

This text does not address the privacy concern. Unless im looking at the wrong version, this text just makes the existing privacy problem more explicit; that the defined behavior could be used to harm user privacy and its up to vendors to figure out how to implement the spec w/o the privacy harm.

In order for the privacy concern to be addressed, it it should be the case that a correct and complete implementation of the standard ensures that the defined functionality is privacy preserving; not just that a vendor could implement it in such a way that it could be privacy preserving.

I appreciate the importance of the I18n issues here, but I think its critical to find a way to address those concerns without risking user privacy.

FWIW, heres another suggestion you all may have already considered and discarded (but maybe not!): discarding the OS vs installed distinction, and instead limiting the number of font-faces that an site / eTLD+1 can reference within the lifetime a storage partition. Like i said, maybe you all have considered and discarded the idea, but this kind of "budgeting approach" might be successful for fonts in a way I dont think its practical for addressing fingerprinting concerns in general (for example, benign font-face selection might be consistent in a way that a sites overall "set of Web APIs used" is not).

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts-4] Privacy and I18n issues around user-installed fonts, and user selection of them.

The full IRC log of that discussion

<ChrisL> q+
<ChrisL> https://github.com//issues/4055#issuecomment-536169515
<astearns> ack ChrisL
<emilio> ChrisL: 7 types of users if you follow that line
<emilio> s/line/link
<emilio> [rephrases from linked comment]
<emilio> r12a: do you have that ??? example? Can't find it r/n
<emilio> s/r12a:/ChrisL: r12a
<ChrisL> s/???/Adlam example
<r12a> chris https://typo.social/@webi18n@w3c.social/112530275400316307
<emilio> ChrisL: was talking about Adlam, so ~45 million speakers, and the system font is just completely unreadable
<emilio> ... the correct version
<r12a> oh, no, not that one
<emilio> ... the screenshot is taken on firefox which prefers system fonts
<r12a> this one: https://typo.social/@webi18n@w3c.social/111489082833818738
<emilio> ... we don't want user fonts to be shadowed by system fonts, just wanted to be aware of that category
<emilio> ... at tpac we had some discussion that it became more apparent that in general we don't want to expose every font the user has by default to the web
<emilio> ... as non-technical users are not aware of how much data they're leaking
<r12a> s|chris https://typo.social/@webi18n@w3c.social/112530275400316307||
<r12a> q+
<weinig> q+
<emilio> ... but we don't want to do it at the expense of users that need local fonts to browse the web
<florian> q?
<r12a> s/oh, no, not that one/
<florian> q+
<emilio> ChrisL: so talked about one language family that "only" has 45m users, but let's talk about mandarin
<emilio> ... there are a lot of new characters
<emilio> ... where users need to install fonts because 2yo fonts don't have them
<emilio> ... font-face doesn't work for that
<emilio> ... the font for these characters is like 3 families with 30mb
<emilio> ... so we need to figure out a solution for the privacy issue without breaking the experience of minority (and non-minority) languages
<emilio> ... various existing proposals
<weinig> q-
<emilio> ... lea did some
<emilio> ack r12a
<astearns> ack r12a
<emilio> r12a: I'm aware of the ???, but I'm concerned about... Is peter here?
<emilio> no
<emilio> r12a: so in the recent formal objection says they want users to control what happens
<emilio> ... the spec says roughly that
<emilio> ... so it's unclear what's being objected to
<emilio> ... so I don't know if the spec is not clear enough or what's needed is for implementors to agree on a solution
<emilio> astearns: don't want to speak for peter but my read is that the objection is that the spec only allows browsers to do this, doesn't require it
<emilio> r12a: do you also agree that the intention is that the user should be able to modify the behavior of the browser
<emilio> astearns: not sure about
<ChrisL> this is the correctly rendered Adlam example (with user installed font) https://w3csocial.files.fedi.monster/media_attachments/files/112/530/273/895/812/226/original/9d7c24263466c1d3.png
<emilio> r12a: it's a bit hidden
<emilio> ... would be good to know what the beef is about exactly
<emilio> astearns: I think the objection is asking us to take this seriously, which I think we've been doing, and unfortunately he hasn't been part of the latest discussions
<ChrisL> Couple more links on Adlam that I was trying to find erlier
<ChrisL> https://www.unicodeconference.org/presentations-41/S7T1-Barry-Barry.pdf
<ChrisL> https://unlocked.microsoft.com/adlam-can-an-alphabet-save-a-culture/
<emilio> r12a: I do have a list of issues which rely on pre-installed fonts
<emilio> ... can paste on IRC
<emilio> ... lmk if you want me to expand on any
<emilio> ... one of my worries is that e.g. I don't use safari for my work, but most of the work I do is from my localhost or my local harddrive
<emilio> ... in those situations there's no issue about fingerprinting
<emilio> ... those measures shouldn't be applied to file:// or localhost
<emilio> ... I've said it many times but hasn't be picked up
<ChrisL> Agree that fingerprinting needs to be partitioned by domain
<r12a> Reasons pre-installed fonts don't always work, or why fallback to system fonts may not work:
<r12a> - Fonts are not kept up to date in a timely fashion (many examples of this!)
<r12a> - Many non-supported scripts, even though they are in Unicode (see https://github.com//issues/4497#issuecomment-594521142), eg. all of Unicode 16 scripts
<r12a> - Characters that are not in Unicode yet (eg. Klingon)
<emilio> ... shouldn't be fingerprinting protection for local stuff
<r12a> - No support for fonts during development
<r12a> - No support for scripts being added to Unicode (eg. Tolong Siki, Beria Erfe, etc.)
<r12a> - Not even support for scripts already added to Unicode (eg. Todhri, Garay, Gurung Khema, Kirat Rai, Ol Onal, etc.) and recent additions to existing Unicode blocks (numerous examples)
<r12a> - No support for bleeding edge script work, such as new Unicode submissions
<r12a> - Insufficient support for preferred font styles — eg. Javanese, no ruq'a or kano font styles for Arabic, no Mool fonts for Khmer
<r12a> - Insufficient support for opentype options — eg. Kashmiri
<r12a> - Inability to mediate between or fall back to appropriate font styles for certain scripts — eg. Syriac, Tai Tham, etc.
<astearns> ack florian
<emilio> r12a: You also can't rely on web fonts in many situations either
<emilio> florian: it seems that the dilemma is that we have optional measures that need to be optional because they disrupt stuff too much
<emilio> ... the categorization breaks a bit, depending on the OS, whether a font is system installed or user installed isn't super clear
<emilio> ... this distinction is not always clear
<emilio> ... e.g. on windows the japanese package install fonts... are those user or system fonts
<emilio> ... many linux distros have the same issues
<emilio> ... the way users install packages is the same way the os is built
<emilio> ... e.g. debian
<lea> q?
<emilio> ... the entirety of the OS is made of packages you can or can not install
<ChrisL> qq+
<emilio> ... all or none of the fonts might be user installed
<emilio> ... the more our solution depends on user or system fonts the more we hit this
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to react to florian
<emilio> ChrisL: we had this discussion and we went to try to collect that information and quickly became intractable to maintain
<weinig> q+
<astearns> ack weinig
<emilio> ... so if we can avoid relying on it it'd be nice
<emilio> weinig: you can easily work around that problem by instead considering the browser a closed unit
<emilio> ... the "system fonts" might be bundled with the browser or not
<florian> q?
<emilio> ... you don't need to define the environment in which a browser runs
<emilio> florian: it's a bit more than a terminology problem
<emilio> ... e.g. on macOS all users have helvetica, all users have helvetica
<emilio> ... there's no font that all users of debian have
<emilio> weinig: that sounds like a browser problem
<emilio> ... a browser on debian could come with a bunch of preinstalled fonts
<emilio> ... the dependence on OS is mostly historical
<emilio> florian: to the extent browser rely on the builtin fonts
<r12a> q+
<emilio> weinig: yeah I'm just saying there's a way to describe this in terms of an immutable and a mutable set of fonts
<emilio> ... and not getting into what they come from
<kbabbitt> q+
<emilio> ... and then you don't have that problem
<kbabbitt> q-
<emilio> astearns: suggest we don't spend too much time on this terminology issue of what a system font is
<astearns> ack fantasai
<ChrisL> q?
<emilio> fantasai: wanted to focus back on the main issue
<astearns> ack r12a
<emilio> r12a: great to see the same thing, the issue is not so much what is a system font but the fact that system fonts don't provide a practical solution right now
<ChrisL> s/practical/complete
<r12a> s/system fonts don't provide a practical solution right now/system fonts don't always provide a practical solution right now
<emilio> astearns: ok, let's try to discuss concrete solutions now