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

@hsivonen

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 #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 #4055 (comment), 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 #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.

Thanks for proposing this.

I like that this opt-in behavior doesn't harm the people in group 7, while strongly helping those in groups 1-3.

@r12a

@r12a ok adding i18n-tracking to this?

Sure. That label is also for you to use to bring our attention to a discussion that you think we should be aware of. So no worries.

@dbaron

@dbaron (for Firefox) @tabatkins (for Chrome) @litherum (for Safari) any thoughts on the desirability and implementability of the proposal by @snyderp ?

The statement in #4497 (comment) that:

(edit: no change to users in group 1, of course)

(where group 1 is "Users who never install fonts.") makes me think that an implicit part of the proposal is that browsers are supposed to default to the set of fonts that are installed by default with the OS (rather than defaulting to the empty set as they would if interpreting the proposal literally). That, on its own, isn't trivial -- it requires knowing what that default is across all combinations of OS / OS version / locale / language packs / etc.

If that assumption is correct, and if that somehow takes into account variation across languages in a reasonable way, and it's doable across OSes, then I think it seems like a reasonable suggestion. But I think there are still a bunch of unclear issues related to how to handle users who have support for multiple languages, etc.

I'd be a little hesitant to put it in a spec until it had been demonstrated to be viable in the market, though (i.e., shown that it's shippable without breaking a ton of users).

(On the flip side, it should be entirely allowable for an implementation to do this if it wants. I'd think the spec allows it today, although if that's not the case it should be fixed.)

required local fonts to be specifically, intentionally loaded into the browser

It’s a little unclear to me what exactly this means. What happens if a user doesn’t select any fonts? Does this mean that no text shows up anywhere on the entire web? Presumably “no user action” should be considered the default, and it’s a pretty bad default to break all text on all webpages.

Are you proposing that the installation process of a browser should include font picker UI asking the user which fonts they would like to use? This doesn’t really work for browsers like Safari which are included with the OS, and are not individually installed.

Mitigating fingerprinting in fonts is a good idea, but forcing every user to make decisions they don’t understand or care about before they get to use the product they just bought, would be an unfortunate design.

The CSS Working Group just discussed [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome).

The full IRC log of that discussion

<dael> Topic: [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)
<dael> github: https://github.com//issues/4497
<dael> myles: I can't take this
<dael> myles: Not sure I understand the proposal
<dael> Rossen_: And Chris is not on.
<dael> florian: I think TabAtkins will want to push back so we should wait for him
<dael> TabAtkins: I am on now
<dael> TabAtkins: For this topic, no comment right now. I didn't see it earlier. I'll talk to our security people and see what our opinion is.
<dael> Rossen_: That's on Fonts?
<dael> florian: The comment is consistent with Fonts

I'm also concerned this proposal would make fingerprinting worse because users would unintentionally select random different subsets of fonts. At least today, all* people buying a new Mac appear to be in the same bucket. This proposal breaks that.

*for some definition of "all"

@snyderp

@snyderp this topic was on the CSSWG call agenda for this week, but we didn't discuss it because no one on the call was comfortable enough to lead a discussion of this topic. I'd like to invite you to attend the next call where we can discuss this. I'm happy to share the details of the call if you email me at mmaxfield@apple.com.

@litherum

General

It looks like either im using the wrong terminology here, or the terms have changed since I last read the specs. (i'm betting the first). Using the terms as defined in Section 10, the proposal would not affect web fonts or pre-installed fonts. The proposal would only affect the user-installed fonts, and would require users tell the browser which user fonts to make accessible to the browser.

@litherum

What happens if a user doesn’t select any fonts? Does this mean that no text shows up anywhere on the entire web?

If no fonts were selected, than the set of fonts available to websites would be only the pre-installed fonts, and the web fonts. The only thing that user-selection affects is which user-installed fonts sites can access.

…this proposal would make fingerprinting worse

I do not believe this is not the case for the above reason.

I'd like to invite you to attend the next call where we can discuss this…

Sure, that'd be great. I'll email now.

@dbaron

Yes, the proposal would require the browser to distinguish between system-installed fonts and user-installed fonts. I agree its not trivial, but it sure seems like browsers and standards have solved more difficult problems in the past ;) If its really just this practical problem, and then figuring out how to standardize behavior, I am sure the WG and PING could work together to solve the problem.

I'd be a little hesitant to put it in a spec until it had been demonstrated to be viable in the market
and
it should be entirely allowable for an implementation to do this if it wants

It seems like Safari has basically shown this to be viable, since their current shipping strategy is even more restrictive than whats proposed above.

More broadly, the goal of the proposal isn't to give privacy-preserving parties a "this is standards compliant" stamp of approval; its to solve the collective action problem of "how to coordinate many privacy-concerned parties (presumably everyone on this thread) to act in tandem to solve a webscale serious problem, without leaving one vendor / platform to hold the webcompat bag" :)

the proposal would not affect [...] pre-installed fonts. The proposal would only affect the user-installed fonts

Even though it is a conceptually useful distinction when discussing things and can inform some degree of best practices, I am not convinced there is actually a clear enough distinction between user-installed fonts and pre-installed fonts in a way that can be used in normative text. How sharp or fuzzy that boundary is varies per OS.

I suspect that on macOS, iOS, and Android, it's pretty clear. The OSes have one set of built-in fonts (which does vary per version though), and anything else is user-installed.

On Windows 10, the OS has a core set of fonts that are always installed. But there are also various international fonts which are installed by default only if you install windows in a particular language. If you installed Windows in a locale where they're not included by default, they can be added by the user by requesting optional Windows components. And so, is "Yu Mincho" to be considered pre-installed on Windows 10 or not? No, because it's optional and some users lack it? Yes, because they're components of Windows, not third party software, and is share by all Japanese installs, and is needed to display Japanese properly? Yes on Japanese windows but no on English Windows? How about on my English language account in a Japanese version of Windows, or the other way around?

Also, many/most Windows computers are sold come with some version of MS Office, and the user took no step in putting it on the device. Are fonts bundled with Office pre-installed or user-installed?

And then you have Linux, where it completely falls apart:

There are hundreds or thousands of different linux distributions, all of which ship different sets of fonts by default. With no API to ask what's pre-installed and what's not, browsers would have to maintain their own per distribution list, which isn't scalable.
Many distributions do not even distinguish between the OS itself and user installed software: everything is installed through the same package manager, pre-installed things can be removed the same way additional software can be added, and there isn't even always such a thing as pre-installed software. If you look at Debian, which is one of the most influential distributions, a bare-bones installation doesn't even have a graphical environment, and how much of a grapical environment you want is a user's decision. So arguably any present in the system is a user-installed font. (And Debian isn't unique in that).

All in all, I feel that this something that some user agents on their own initiative could do on some platforms, based on their own definition of what should be auto-exposed and what should be opt-in, but I don't think this is something we can specify or mandate with any degree of interoperability.

I suspect that on macOS, iOS, and Android, it's pretty clear. The OSes have one set of built-in fonts (which does vary per version though), and anything else is user-installed.

Even on macOS, I'm not sure this is quite so clear. There are a number of fonts that are shipped with macOS but are not exposed in the standard collection seen when applications request "the list of available font families" from the OS. Some of these are associated with particular applications (iWork, iLife), and can probably be ignored here, but there are also a bunch of fonts for "language support" (basically a collection of Noto fonts); should these be auto-exposed? (FWIW, Firefox currently does make the "language support" fonts available in the browser, even though they don't appear in other applications' font lists.)

And then there are downloadable fonts: there are a number of font families (mostly, though not exclusively, CJK fonts) that are not installed by default (at least on my US English configuration), but are known to the OS and can be "enabled" (downloaded) directly within Font Book, without following the usual font installation route. Are these considered "system" or "user"-installed?

On Android, it's also less than clear, I think: in my experience, many device manufacturers or distributors customize the collection of fonts they ship, so that there is not a uniform set of fonts per Android version (unless we interpret "version" here to encompass not only the Android version number but also the specific device on which it's running).

@litherum

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

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//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//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//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

[css-fonts-4] Add suggested user prompting to make local fonts availa…

@felipeerias

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

The i18n WG considers this to be a duplicate/precursor to #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:

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.

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.

@svgeesus

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:

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

Navigation Menu

Repository navigation

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

67 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

svgeesus commented on Nov 11, 2019

svgeesus commented on Nov 11, 2019

r12a commented on Nov 11, 2019

svgeesus commented on Dec 3, 2019

dbaron commented on Dec 11, 2019

litherum commented on Dec 11, 2019

css-meeting-bot commented on Dec 11, 2019

litherum commented on Dec 11, 2019

litherum commented on Dec 11, 2019

pes10k commented on Dec 11, 2019

frivoal commented on Dec 12, 2019

jfkthame commented on Dec 12, 2019

67 remaining items

astearns commented on Nov 16, 2021

css-meeting-bot commented on Nov 17, 2021

svgeesus commented on Jan 19, 2023

r12a commented on Dec 7, 2023

pes10k commented on Dec 7, 2023

svgeesus commented on Dec 7, 2023

aphillips commented on Dec 7, 2023

svgeesus commented on Dec 7, 2023

pes10k commented on Dec 11, 2023

svgeesus commented on Dec 11, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions