[css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)

[pes10k]

This issue is lifting a proposal to prevent font fingerprinting that was discussed in PING, but i think go buried in the longer conversation in https://github.com/w3c/csswg-drafts/issues/4055

What if the standard didn't put any limitations on the fonts that could appear in the set of local fonts, but required local fonts to be specifically, intentionally loaded into the browser, instead of defaulting to any and all fonts the browser and find on the OS. Browsers would then implement chrome / settings / something to allow users to load fonts into the browser (independent of the fonts the user has added to the OS), and only these fonts would be included in the "local fonts" part of the current algorithm.

To use the helpful taxonomy / organization given by @hsivonen in https://github.com/w3c/csswg-drafts/issues/4055#issuecomment-536169515, this would dramatically improve privacy for users in groups ~1, 2, 3~ 2 and 3, moderately improve [1] privacy for users in groups 4, 5, 6 w/o harming their use cases, and preserve what people in group 7 are trying to do. (edit: no change to users in group 1, of course)

I believe this proposal would cut the knot in issue https://github.com/w3c/csswg-drafts/issues/4055 by completely removing the fingerprinting surface for many (most?) users and improve privacy for remaining users (w/o impacting their goals and needs).

[1] I say moderately because it would reduce the number of fonts identifiable by fingerprinters, and so increase the size of these users' anonymity sets.

[Crissov]

Canʼt we simply put a limit on the number of (local) fonts a single site may use?

[hsivonen]

I'm worried about the impact of this on minority language users, and also specialists such as egyptologists, and other script researchers.

(Non-Linux-using) egyptologists will be fine. macOS, Windows 10, Android, and Chrome OS ship with font support for Egyptian hieroglyphs by default.

Unfortunately, Ubuntu and Fedora don't install font support for Egyptian hieroglyphs by default. I think the correct way forward is convincing them that they should.

If egyptologists want JSesh specifically, the options are including it as a Web font or opting out of privacy protection.

If users can opt to allow certain fonts which are never likely to appear in the browser defaults, it sounds like they expose themselves to fingerprinting,

The alternative seems to be leaving everyone exposed to fingerprinting.

which doesn't make this a great solution for large numbers of people.

I believe the number of people is much smaller than it appears considering that the most popular systems already have even long-dead scripts covered.

Canʼt we simply put a limit on the number of fonts a single site may use?

How would that work? Scripting can change the page over time, and trying to maintain quota state over time make the quota maintenance state itself fingerprintable local state.

[hsivonen]

Unfortunately, Ubuntu and Fedora don't install font support for Egyptian hieroglyphs by default. I think the correct way forward is convincing them that they should.

Filed Ubuntu and Fedora bugs.

[r12a]

(Non-Linux-using) egyptologists will be fine. macOS, Windows 10, Android, and Chrome OS ship with font support for Egyptian hieroglyphs by default.

I can't see limiting people to a single font, and one that they have no control over, is going to work, either for specialised communities or for minority languages. Note for example that:

1. the repertoire for Egyptian hieroglyphs is expected to expand from time to time, is there a guarantee that available system fonts will promptly deliver changes?
2. does the system font you have in mind provide the coloured glyphs that egyptologists sometimes need, or the alternate styles they sometimes use?
3. do those fonts support the new Unicode formatting characters for arranging egyptian glyphs in quadrats?

I'm willing to bet that the answer to all of those questions is no, and that adding support is a hit and miss affair with long lead times, whereas the community has developed or is developing its own fonts in a much more timely manner.

As for using webfonts, the fonts used by egyptologists are large, ranging in size from around 0.5Mb to almost 6 Mb in size (and they will grow with the repertoire). It's not always ideal bandwidth-wise to require them to be used as webfonts only, especially if you want to use more than one font per page.

I'm not arguing against addressing the fingerprinting issue, i'm just saying please provide an easy opt out when people want to work with certain local fonts. Don't take the Safari route and make it impossible to use anything but what the system offers.

Serving fonts as webfonts may work more easily for many languages/scripts than for egyptian, but it does still add complications. For instance, if you are experimenting to find the right font for your content it will become tedious to have to create webfonts before you can test any font. And I'm hoping that, as someone previously mentioned, it would at least be fine to use local fonts through localhost.

[r12a]

I believe the number of people is much smaller than it appears considering that the most popular systems already have even long-dead scripts covered.

I think that's over-optimistic. So here's some data. This is a list of whole script blocks (rather than languages or new or missing characters, etc) that are not supported by system fonts on my Mac: for Europe, Caucasian Albanian, Cyrillic extended-c, Elbasan, Glagolitic supplement, Linear A, Old Hungarian, Latin extended-D & E, Linear A, Old Hungarian, Old Permic, Phaistos Disk; for Africa, Adlam, Bassah Vah, Egyptian format controls, Medefaidrin, Mende Kikakui, Meroitic Cursive, Meroitic Hieroglyphs; for West Asia, Arabic Extended A, Chorasmian, Elymaic, Hatran, Nabataean, Old North Arabian, Palmyrene, Psalter Pahlavi, Syriac Supplement, Yezidi;
for Central Asia, Manichaean, Marchen, Mongolian Supplement, Sogdian, Old Sogdian, Soyombo, Zanabazar Square; for South Asia, Ahom, Bhaiksuki, Devanagari extended, Dives Akuru, Dogra, Grantha, Gunjala Gondi, Khojki, Khudawadi, Mahajani, Masaram Gondi, Modi, Mro, Multani, Nandinagari, Newa, Sharada, Siddham, Sora Sompeng, Takri, Tamil Supplement, Tirhua, Vedic Extensions, Wancho, Warang Citi; for Southeast Asia, Hanifi Rohingya, Pahawh Hmong, Pau Cin Hau; for Indonesia & Oceania, Makasar for East Asia, Bopomofo Extended, CJK Compatbility Ideographs Supplement, Ideograph Symbols & Punctuation, Hangul Jamo (large proportion of), Hangul Jamo Extended A & B, Kana Extended A, Kana Supplement, Small Kana Extension, Khitan Small Script, Miao, Nushu, Tangut for the Americas, Mayan Numerals, Nyiakeng Puachue Hmong, Osage, UCAS Extended.

I'll stop there, rather than continuing with categories such as Notational systems, Alphanumeric Symbols, Technical Symbols, Numbers & Digits, Arrows, Mathematical Symbols, Emoji & Pictographs, Game Symbols, and Other Symbols, each of which i expect to include at least one block without coverage.

Some of the above are for archaic languages, but others are for minority languages that have finally been given a way to put their content online.

I'm also concerned, however, that your comment implies that as long as there is some font available, then that's fine. I'd argue that that's not usually the case. For example, this morning i was working on Syriac. Sure you can see characters in Syriac using a system font, but for the Mac that appears to mean the Noto Sans Syriac Eastern font only. That is not helpful if you are writing in a Western Syriac language, or working with religious or archaic content that needs the Estrangela font. I tried changing the language tag, but it didn't help. But even then, the Noto font doesn't really provide what people would expect to see. Here's a sentence in the 3 Noto fonts, Estrangela, Eastern, and Western:

And here's the same text using 3 fonts that are much closer to what you'd normally see when writing these 3 varieties of Syriac, each with their own distinctive characteristics, rather than with the harmonisation applied by Noto.

I'm not saying that you can't get around this by using webfonts, or for the time being local fonts, in your CSS. I'm just trying to make the point that a one-size-fits-all font, like Noto, is likely to strip out important local cultural aspects of the text, and if it's the only game in town, can cause significant problems in languages where there are writing style variants, such as the 3 syriac varieties just mentioned, or looped vs unlooped Thai letters, or Naskh vs Nastaliq vs Kano vs Magrebi etc styles in Arabic, slanted vs upright vs rounded in Khmer and other scripts, etc.

hth

[hsivonen]

I'm not arguing against addressing the fingerprinting issue, i'm just saying please provide an easy opt out when people want to work with certain local fonts.

Clearly, there needs to be an opt-out of protection to address the needs of users whose scripts don't have a system-bundled font.

Don't take the Safari route and make it impossible to use anything but what the system offers.

FWIW, I'm not aware of anyone advocating that kind of outcome for Firefox.

I believe the number of people is much smaller than it appears considering that the most popular systems already have even long-dead scripts covered.

I think that's over-optimistic. So here's some data.

My point was that already the system-bundled font coverage is so broad that in fact egyptology isn't in the category of wholly-unsupported use cases. I.e. if it appeared that egyptologists would have to opt out of protection, it's not necessarily so, hence "smaller than it appears". (I'm not claiming that no one would need to opt out. It seems well established that there's existence proof of cases that would need an opt-out.)

I'm also concerned, however, that your comment implies that as long as there is some font available, then that's fine.

There are different levels of adequacy. If there's no font at all, nothing works, and use cases like being able to input text into a global site (e.g. to write a tweet) can't rely on a Web font. However, when the text to be published is known, Web fonts can be relied upon for stylistic variability. Moreover, for user-installed fonts to satisfy stylistic variability, the authors need to know what fonts the users have, which doesn't scale well. For that reason, I don't think the notion that Web publishers want stylistic variability is an argument against (waivable) privacy protection by default.

the repertoire for Egyptian hieroglyphs is expected to expand from time to time, is there a guarantee that available system fonts will promptly deliver changes?

Chances are that the outcome depends on how active the user community is with bug filing.

does the system font you have in mind provide the coloured glyphs that egyptologists sometimes need, or the alternate styles they sometimes use? do those fonts support the new Unicode formatting characters for arranging egyptian glyphs in quadrats?

These seem to be things that can be addressed by Web fonts when publishing documents and that aren't total blockers for usage in the context of systems where the person providing the text doesn't control the fonts of the system that shows the text (e.g. Twitter).

That is not helpful if you are writing in a Western Syriac language, or working with religious or archaic content that needs the Estrangela font

Do users of this language currently have that font installed such that Web authors are presently relying on it being installed?

(In general, with examples like this it's hard understand the severity. That is, I don't know how to map the example to a spectrum from rendering Italian with a fraktur font by default to rendering Polish with a French-typical acute accent angle.)

I'm just trying to make the point that a one-size-fits-all font, like Noto, is likely to strip out important local cultural aspects of the text,

To understand to what extent what's being proposed here would affect this, one would need to know to what extent sites currently rely on the user community having specific non-default fonts installed for expressing these cultural aspects (as opposed to using Web fonts). Considering how hard it is for the user to install fonts on Android, it seems unlikely that in parts of the world where Web access skews very heavily towards mobile devices Web authors could rely on user-installed fonts for this kind of cultural expression at present. That is, it seems that Web fonts are already needed for this level of control.

and if it's the only game in town, can cause significant problems in languages where there are writing style variants, such as the 3 syriac varieties just mentioned, or looped vs unlooped Thai letters, or Naskh vs Nastaliq vs Kano vs Magrebi etc styles in Arabic, slanted vs upright vs rounded in Khmer and other scripts, etc.

There for sure are cases where limiting local fonts to system-bundled ones would restrict stylistic richness along those lines, but loopy vs. non-loopy Thai and Naskh vs. Nastaliq don't appear to be distinctions that limiting local fonts to the installed-by-default system fonts would break.

[r12a]

I think we're mainly thinking along similar lines.

To understand to what extent what's being proposed here would affect this, one would need to know to what extent sites currently rely on the user community having specific non-default fonts installed for expressing these cultural aspects (as opposed to using Web fonts).

I've been wondering the same thing, but i don't have a definitive answer. Anecdotally, however, my interests and work with the Unicode Editorial Committee lead to me, on a very regular basis, hunting down fonts for minority or archaic scripts. The almost universal pattern is that you find a webpage that allows you to download a Unicode font (or if you're lucky more than one) (or for non-Unicode fonts often a package including keyboard). They don't usually provide WOFF fonts, they just expect you to download the font to your system. But there are often only a couple or at most a small handful of viable fonts for many of these scripts (and that situation typically lasts for several years). I imagine this has by now led to the build up of a (relatively speaking) fair amount of legacy content that will break unless the user opts out.

Note also that people download these fonts for use with non-Web applications, too, such as Word, so that's another reason they download the font file to their computer.

Note, btw, that Hanifi Rohingya is one of the scripts that is not supported by a system font per my tests above, and there are currently very few Hanifi Rohingya Unicode fonts. Although Rohingya text probably isn't tested for in the more general fingerprinting patterns, if you actually wanted to identify Rohingya people and targetted your fingerprinting specifically to that, then it sounds like it would be fairly easy. On the one hand, it's worth pushing for system fonts to cover this and other missing minority scripts, but on the other, it's not a great solution for the user if there's only one font available. So i think that actively encouraging a culture that provides webfonts is probably something we should try to do, as well as working on the technical side.

[pes10k]

I'm grateful for the conversation here, and encouraged the by the proposals above. I want to suggest a slightly different approach, that (I hope) will maintain the following use cases:

1. Privacy preserving default (e.g. default should reflect the common case, that most users are well suited by OS + Web fonts)
2. Don't break websites for folks who are not well solved by OS defaults (e.g. folks visiting websites needing fonts not provided by their systems should be strictly no worse off than the current situation. ditto for web devs)
3. Avoid being tied to fragile / freeze-the-web list building
4. Not introduce new privacy harms (e.g. not require building caches that are shared between profiles / storage resets etc, as some proposals would require)
5. Provide an in-standard solution for vendors to differentiate over, but also share resources where possible.

If there are concerns or use cases not covered in the above, please let me know. I'm mostly trying to generalize-w/o-loss over some of the concerns shared above.

My proposal is:

1. By default, sites only access OS-default fonts and web fonts
2. Vendors can also define, however they like, identify (font, local, os) tuples, for additional fonts the browser can load off disk iff they are on the disk (e.g. if they're not on the disk, the browser doesn't magically provide / load them). I dont have a good name for these, so i'll just call them vendor-local-fonts. How vendors create these sets of vendor-local-fonts is up to the vendor, but I imagine this is a place that resources could be shared, and this working group / W3C could be very useful in maintaining a useful set.
3. Vendors implement profile-wide (not per site) settings UI that allows for i. a useful default setting (websites can access OS-provided fonts, web fonts, and vendor-local-fonts) ii. a custom setting, that shows users the fonts the browser knows about on disk that are not OS-provided fonts, and users can opt those in to the set of fonts sites can access

This is similar to the proposal in the issue text at the top of this thread, but provides a) a path for vendors to define better defaults for users per-local, b) still maintains the needed use cases, c) would require no changes for most users

[aphillips]

I18N discussed this in our most recent teleconference and I was actioned to write this.

In general our thoughts are as follows:

1. Fingerprinting users can be used for bad things. This can especially apply to minority language users.
2. Many minority languages are not supported by default system fonts and get little (or occasionally no) support from fallback fonts such as Noto. Special rendering needs such as conjuncts or ligatures or the need for additional styles are often best effected by the installation of fonts. This may be accompanied by other with other language support features (which might also be fingerprinted??) such as keyboards, dictionaries, etc. We believe there needs to be a mechanism to allow user-installed fonts to be rendered into web pages to support these sorts of user requirements. This mechanism should not be super obscure. (We did discuss different mechanisms in our call, but defer to browser makers to design good customer experiences)
3. Other user audiences also benefit. For example, many scholarly works (particularly on ancient languages, but by no means limited to these) depend on custom fonts. Similarly, some consumers want to use different fonts.
4. Webfonts are the future, but some language support communities might find it difficult to provision these in the short term.

So: our tendency is to recommend that CSS guard against fingerprinting by default, but provide clear normative guidance to allow customer-installed fonts to be used, perhaps via some whitelisting mechanism.

[pes10k]

Hi @aphillips Thank you for the update. From reading through the 4 points above, I'd be very curious on your reaction to the proposal in https://github.com/w3cping/font-anti-fingerprinting/pull/6#issuecomment-599359211 which, I believe, satisfies each of the 4 points and the "So: …" summary at the bottom

[svgeesus]

Adding a link to latest proposals:

Font Anti-Fingerprinting Font Fingerprinting Protection Through Better Defaults and Measurement Hinting

[astearns]

Also related: https://github.com/tabatkins/proposal-local-font-access

[svgeesus]

Useful input from I18n

[hfhchan]

Academics studying the Seal Script regularly need to use multiple fonts for getting the exact shape from an exact version of Shuowen Jiezi. Each font is upwards of 10 MB, a collection of the four main books will be upwards of 40MB. This cannot be practically delivered via web font technologies, and it would very inconvenient for every user to have to enable it in the browser through settings. Also, a on/off setting for all sites means forcing researchers to choose between extremely high fingerprintability vs being able to actually do their work.

What if instead the website is responsible for requesting to use a particular local font, limited to e.g. 5 requests (each of 10 font families) per site (eTLD+1)? The user will have to explicitly grant access to a particular font for the specific origin, reducing additional fingerprinting to sites the user trusts.

[pes10k]

@hfhchan Thank you for the comment! I'm not familiar with Seal Script; could you share more information about it if you have links?

Regarding the specific problem you mention though, I think, in a sense, thats the easier problem, where there is an expectation that sites can be updated. @tabatkins had a great suggestion for a way that sites could explicitly requests fonts off disk with user involvement, and I think would cover the use case you describe.

In a sense, all the complexity in the above discussion is mostly about cases where we can't expect sites to update, and how to provide privacy to users of sites that require non-common fonts there.

[hfhchan]

The fonts based on the Tenghuaxie version submitted for ISO10646 standardization of Shuowen Small Seal is 10MB in total.

Only considering the Small Seal in Shuowenjiezi and its different versions, in WG2 N4716 page 6 there are five versions of Shuowen that is of interest. If you look at WG2 N5117 page 8, there are even more versions of Shuowen and commerical adaptations.

Not to mention actual Small Seal carvings are different from those in Shuowenjiezi, illustrated in this article "目前坊间的小篆字体有什么区别？" (What's the difference between the different released small seal fonts?") https://www.zhihu.com/question/41780292. There is still no consensus on how these differences be handled in Unicode, and researchers mainly rely on PUA or putting the glyphs on top of their corresponding CJK Unified Ideographs.

Regarding the specific problem you mention though, I think, in a sense, thats the easier problem, where there is an expectation that sites can be updated. @tabatkins had a great suggestion for a way that sites could explicitly requests fonts off disk with user involvement, and I think would cover the use case you describe.

That sounds great. For the case of legacy sites where content can't be updated, besides having a global setting, it might be easier for users to install a certain WebExtension which dynamically injects the necessary JavaScript to request access to fonts for required sites.

[pes10k]

@hfhchan thanks very much for the above details! I will dig into them!

I think the web extension idea is also neat, though i think requiring a browser extension to visit a site might be prohibitive, especially for users on lower power, older or otherwise not-necessarily-extension-supporting-browsers. But its a neat idea, would be very interested to know what others think too!

[hfhchan]

In the case of CJK-related scripts research where there isn't a standard encoding model yet, the common practice is to use PUA, which entails installing a bunch of fonts and proprietary IMEs. So, comparatively, installing a WebExtension is both easier (no admin rights needed) and safer (code is sandboxed; sites which the extension can access are declared upfront in the manifest), and would be the least problem for researchers.

[litherum]

See also: https://github.com/w3c/csswg-drafts/issues/5421 (which directly contradicts the OP of this thread).

[felipeerias]

The current proposals start by defining (through various methods) sets of "safe" fonts that don't leak additional information beyond what can be already found out through other means (OS, language, etc.).

For fonts that are installed but outside of the user's "safe" set, I think that @r12a's idea (mentioned in #5421) might be on the right track: the browser could prompt the user to enable those local fonts (for the current domain or for all pages) at the point where they are requested.

This UI flow could be similar to the ones already used when a page requests additional permissions, and would include a preview of the requested font. This would provide the user with the necessary context to evaluate whether the request is reasonable.

From the point of view of the Web developer, the initial effect would be as if the font is unavailable. The font might become available at some indeterminate point in the future, triggering a style and layout update, but until that happens there would be no way of knowing whether it is not installed or its use has been declined by the user.

Font fingerprinting scripts typically create a bunch of nodes with different font-family values, add them to the page via appendChild() (which triggers style+layout recalculation), and measure the resulting sizes. Introducing an unpredictable delay would prevent these scripts from detecting fonts beyond those in the "safe" set and those that have been explicitly accepted for the current page.

Of course, newer fingerprinting scripts could wait for a while before testing the presence of a font. However, the UI would still reflect that this fingerprinting effort is taking place. Whereas benevolent pages would trigger a message of "this page wants to use fonts ABC and XYZ", for a malevolent one the message would become a more alarming "this page wants to use 51 fonts".

The UI may even change when a page requests an unreasonable number of fonts, nudging the user towards declining the request.

As is the case with other permissions, there would be a section in the Preferences where the user could review and revoke the fonts that had been made available to particular domains or to all of them.

What do you think about this approach?

[svgeesus]

Related issue in Timed Text https://github.com/w3c/ttml2/issues/1202

[r12a]

What do you think about this approach?

Fwiw, this is indeed what i was thinking would provide a good solution, for all the reasons that @felipeerias mentions.

[astearns]

@litherum do you have an opinion on @felipeerias suggestions?

[css-meeting-bot]

The CSS Working Group just discussed Local Font Access Limitations.

The full IRC log of that discussion

<fantasai> Topic: Local Font Access Limitations
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/4497
<fantasai> astearns: Topic is about local fonts needed for i18n particularly
<fantasai> [side discussion about positioning of Agenda Item 9]
<fantasai> smfr: Myles isn't here
<fantasai> s/here/here, probably should be here/
<fantasai> astearns: Other browsers than Safari probably need to sign on for whatever local font access we decide on here
<fantasai> s/here/here also/
<fantasai> chris: It would be good to get some movement on this.
<fantasai> chris: Felipe made a good suggestion, and thumbs up in thread
<fantasai> chris: Richard confirmed he liked the suggestion
<fantasai> chris: Maybe we can resolve to accept the suggestion, and then work out the details in the spec
<fantasai> chris: The general principle seems sound
<fantasai> Felipe's suggestion at https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-763459971
<fantasai> astearns: Summary is having some sort of permission interface, where if a web page tries to use a local font and browser notices local font is in system, UI would come up
<fantasai> astearns: timed to make fingerprinting more difficult
<jfkthame> q+
<fantasai> astearns: allows user to enable font access
<smfr> q+
<fantasai> r12a: Then can have a checkbox for "don't ask me about this font again"
<chris> q+
<fantasai> jfkthame: Interested in Gecko
<astearns> ack jfkthame
<fantasai> jfkthame: Doing some foundational work towards potentially restricting font access
<fantasai> jfkthame: One aspect not directly talked about, seems there are several senses in which a website could want to use a locally-installed font
<fantasai> jfkthame: worth highlighting the distinction
<fantasai> jfkthame: might be font name is given in font-family property
<fantasai> jfkthame: so that specific font family is specifically requested, and page would like to use, and might or might not be allowed
<fantasai> jfkthame: But what about font fallback? Character that is not in other fonts
<fantasai> jfkthame: Would that trigger requests like this?
<fantasai> jfkthame: Should there be a user request for fallback, when the character is not available in other fonts?
<chris> qq+ to answer
<fantasai> jfkthame: I think the fingerprinting implications are different
<fantasai> jfkthame: I think for fallback, I think it's particularly concerning for minority languages
<astearns> ack chris
<Zakim> chris, you wanted to react to jfkthame to answer
<fantasai> jfkthame: For such users, any font that supports the language would be helpful
<fantasai> chris: For fallback case, script can know that fallback was used, but doesn't know which one
<fantasai> chris: so imo shouldn't require a user permissions font
<astearns> ack smfr
<fantasai> jfkthame: well, you are exposing the fact that the user has *a* font that supports these characters
<fantasai> smfr: In general, we don't believe permission prompts are useful solution to this kind of problem
<fantasai> smfr: one reason is user fatigue; users don't read the dialog, just want it out of the way
<fantasai> smfr: Then it's really impossible to explain to users what fingerprinting means and implications
<r12a> q+
<fantasai> smfr: ....
<fantasai> smfr: Then users don't understand whether web page or browseris showing the dialog
<fantasai> smfr: long-term approach should be that system fonts have support for these minority languages
<fantasai> smfr: so that we don't need to run into this problem in the first place
<astearns> ack chris
<tantek> +1 smfr, permission prompts are not a reasonable answer to this (users can't be expected to make informed consent)
<fantasai> chris: the page gets laid out without the font, the dialog box pops up asking permission to allow this, so that next time come to that site (per origin) not bothered by it
<fantasai> chris: so rapidly not going to run into this problem
<astearns> ack chris
<fantasai> chris: a font on system that covers the charset vs specific font that gives the right design is different
<fantasai> chris: ....
<fantasai> r12a: There is somewhere a long post on one of these issues where I addressed the question of system fonts being able to display the text
<fantasai> r12a: there are certain scripts and orthographies where not only does it not look good, but it actually causes problems in representing semantics
<fantasai> r12a: Might end up with wrong kind of glyphs, doesn't look the way you expect as a user of tye script
<fantasai> r12a: Don't see any way to rely on system fonts here
<chris> suspect r12a is referring to this: https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-594521142
<fantasai> r12a: Also people like font designers have a problem, they can't check their fonts if they can't see them
<chris> with Western Syriac example
<fantasai> r12a: Noto fonts are not a panacea
<fantasai> r12a: They are often in need of significant repair to do the job
<fantasai> r12a: Sometimes missing for certain minority scripts
<fantasai> r12a: Not coverage of characters, sometimes not the right glyph shapes
<fantasai> r12a: A dialog box in front of the user is not great
<fantasai> r12a: But it's better than not being able to get the font that you want
<fantasai> r12a: I couldn't think of any better solution to it
<fantasai> r12a: It will probably help if we have the ability to say "don't remind me, about this particular font"
<fantasai> r12a: I don't think there's a good solution here
<fantasai> r12a: If you're creating web pages, you are checking your page using localhost
<fantasai> r12a: and in that situation, there's not going to be any phishing
<fantasai> r12a: major pain in the butt if you can't spin up the page with the font you'd like to see
<chris> localhost is just one example of an origin
<fantasai> r12a: So I'd like to argue that if you're working on localhost, then that should not prevent you from seeing fonts
<fantasai> astearns: My current take is that we're not ready to resolve on anything
<fantasai> astearns: but encouraged by the fact that Gecko is interested in figuring out
<fantasai> astearns: Sounds to me that there are some valid concerns about permission interfaces
<fantasai> astearns: but also valid concerns about not doing anything and just relying on system fonts
<fantasai> astearns: so I hope that people engage on the issue, because this is something that we need to solive
<fantasai> astearns: Thanks, r12a, for joining us

[svgeesus]

I added the suggestion from @felipeerias , which @r12a also liked, to the spec.

[r12a]

The i18n WG considers this to be a duplicate/precursor to https://github.com/w3c/csswg-drafts/issues/5421 and that we should continue the discussion there and close this issue. Would that be acceptable?

[pes10k]

I’m not sure I follow, that issue is suggesting something incompatible (and opposite) from this issue

[svgeesus]

I don't see incompatible solutions being proposed but I do see that:

• some trade-offs which try to improve privacy have been shown to worsen localization and internationalization
• some trade-offs which try to improve internationalization may worsen privacy (depending on whether the installed fonts are reported, and how)
• it is very clear that users need to be in control and that one size does not fit all.

I'm fine to leave both issues open until we have consensus wording that satisfies all interested parties.

[aphillips]

I think I18N's concern is that these appear to be tracking the same thing (if starting from opposite positions). All we're suggesting is that having a single thread to follow discussion might be simpler than two threads to track?

[svgeesus]

OK but in that case I think an edit of the remaining issue title is justified, if one issue is closed.

[pes10k]

okie, im fine merging the issues if the WG prefers, though PING side we'll keep our tracking issue open to keep track of the concern.

Like @svgeesus suggested though, i think it'd be important to edit the title of whichever issue ends up being the remaining issue

[svgeesus]

Closed, further discussion should be here:

• https://github.com/w3c/csswg-drafts/issues/5421