Closed pes10k closed 8 months ago
Canʼt we simply put a limit on the number of (local) fonts a single site may use?
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.
(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:
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.
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
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.
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.
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:
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:
(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.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 accessThis 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
I18N discussed this in our most recent teleconference and I was actioned to write this.
In general our thoughts are as follows:
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.
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
Adding a link to latest proposals:
Font Anti-Fingerprinting Font Fingerprinting Protection Through Better Defaults and Measurement Hinting
Also related: https://github.com/tabatkins/proposal-local-font-access
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.
@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.
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.
@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!
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.
See also: https://github.com/w3c/csswg-drafts/issues/5421 (which directly contradicts the OP of this thread).
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?
Related issue in Timed Text https://github.com/w3c/ttml2/issues/1202
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.
@litherum do you have an opinion on @felipeerias suggestions?
The CSS Working Group just discussed Local Font Access Limitations
.
I added the suggestion from @felipeerias , which @r12a also liked, to the spec.
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?
I’m not sure I follow, that issue is suggesting something incompatible (and opposite) from this issue
I don't see incompatible solutions being proposed but I do see that:
I'm fine to leave both issues open until we have consensus wording that satisfies all interested parties.
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?
OK but in that case I think an edit of the remaining issue title is justified, if one issue is closed.
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
Closed, further discussion should be here:
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.