[meta][css-fonts-4] Index of local font issues: fingerprinting, I18n, privacy

[svgeesus]

From oldest to most recent, including closed issues.

• [css-fonts] incorporate mitigations for font based fingerprinting #4055
• [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome) #4497
• [css-fonts][css-fonts-4] CSS Fonts 4 needs a proper Security and Privacy Considerations section #4697
• [css-fonts-4] I18n self-review checklist #5030
• [css-fonts-4] Privacy and I18n issues around user-installed fonts, and user selection of them #5421
• [css-fonts] JS-free probing of Unicode support of fonts #5578
• [css-fonts-4] Installed font aliasing #5819
• [css-fonts] Clarify parsing of <font-face-name> for the src: local(...) function #8187
• [css-fonts] Reference font subsets without privacy leaks #11092
• [css-fonts] Exploring better ways to balance privacy, i18n, design tradeoffs for local fonts #11571
• [css-fonts] Detection-prevention approach to the local font privacy issue #11648
• [css-fonts] Making the font matching algorithm more prescriptive for local fonts #11753

And also the fonts 4 wide review issue, started April 2020:

• Wide Review of CSS Fonts 4 #4944

@pes10k @r12a @drott @jfkthame @astearns

[svgeesus]

@noamr @LeaVerou @hsivonen

[svgeesus]

This is on the agenda for the Weds, 5 March 2025 call.

[kbabbitt]

In recent conversations, I've identified an additional existing use case for local fonts that I wanted to bring to the group's attention.

A document editing application has both platform-native and web-based implementations. User A begins work on a document in the platform-native application. They apply formatting using fonts installed on their device. They save the document to cloud-based storage and close the application.

Later, User A resumes work on the same document, on the same device, using the web-based application. They should see the same use of fonts they previously applied in the platform-native application. They make further changes to font styling and save the document again.

User A shares the document with User B, who opens the document in the web-based application. To the extent User B has the same fonts installed on their device, they should see the use of fonts applied by User A in either the platform-native or web-based application.

[css-meeting-bot]

The CSS Working Group just discussed [meta][css-fonts-4] Index of local font issues: fingerprinting, I18n, privacy.

The full IRC log of that discussion

<fantasai> hober notes that Metafont is an actual thing
<fantasai> ChrisL: I created this meta-issue ... to organize the discussion
<fantasai> ChrisL: Sometimes we solve certain aspects and close an issue, so this is why closed issues are included
<fantasai> ChrisL: Want to show where we are, what we've solved / not solved, etc.
<fantasai> ChrisL: Some recent discussions around treating local fonts like webfonts
<fantasai> ChrisL: But we need to solve this in some way, and we need to not break the Web, and to not disadvantage users who use languages other than English
<fantasai> ChrisL: For example Chinese often relies on local fonts
<fantasai> ChrisL: Another use case was a word processor type application, where users expect the browser to access all the local fonts
<fantasai> ChrisL: Point of agenda item is to ask, who is interested in this topic? Who plans to work on it? If we come up with solutions, who will prototype them?
<fantasai> astearns: Looking for volunteers to look at the possible solutions, try to make progress up to and including prototyping, to see what we can do to make this a better situation across all browsers.
<fantasai> noamr: I'm personally interested in it, but don't have the bandwidth atm. I can try to find ppl in Google internally, but that's the most I can commit to.
<fantasai> ChrisL: That's still helpful, thanks!
<fantasai> astearns: As we work on solutions and get closer to something that seems viable, it may be a little easier to convince others to take the time to prototype things.
<emilio> (not with a mic r/n), but I'm interested, and there's people at Moz that also are, but whether but whether we're the right people to prototype depends on what solutions we're talking about :)
<fantasai> astearns: I will say that I got 5 private responses to my query that was meant to prompt public reply-all of ppl interested in this issue.
<fantasai> astearns: People expressed their opinions on what most likely possibilities were on the issue, but just private replies and not sure what ppl are comfortable with me making public.
<fantasai> ChrisL: I sent a private reply. First I had increased time in CSSWG by 10% and plh was ok with it.
<fantasai> ChrisL: I also commented on what I thought were the most practical directions, but as the editor I want to be neutral.
<fantasai> ChrisL: so that's why private reply
<fantasai> astearns: I will commit more time to looking through these issues and replying with problems that I see, or avenues that seem promising.
<fantasai> astearns: I may not be quite the level of ChrisL, might be more 5% increase. :)
<Zakim> astearns, you wanted to read emilio's comment
<fantasai> astearns: [reads emilio's comment]
<fantasai> jfkthame: I'm in a fairly similar position to noamr, I'm interested, but I have very little bandwidth atm
<fantasai> jfkthame: at the same time, if/when we coalesce around ideas worth prototyping, I'm happy to advocate for them and try to find resources to work on it
<kbabbitt> q+
<fantasai> kbabbitt: Encourage incubating ideas
<astearns> ack kbabbitt
<fantasai> kbabbitt: Since I brought up word processing idea, I can discuss with those stakeholders
<fantasai> kbabbitt: Will try to produce data necessary
<fantasai> astearns: So maybe we take this back to the issues and get some more work done, unless anyone else wants to add to the conversation?
<fantasai> astearns: OK, done for now. Expect these issues to return!

[drott]

An alternative approach, rather than filtering or constraining to a set of vanilla OS system fonts:

Run the browser with its own font environment -
In ChromeOS and Android we use a set of open-source fonts, a collection of fonts from the set of Noto fonts and others from the open-source set of Google fonts as the font environment.
Create a font environment based on these existing corpuses for the browser independent of the system fonts and update this with the browser. Serve font matching and fallback requests from this set of fonts.
If done right, in my understanding this would then lead to very little entropy being gained from this font environment, probably not much other than: "this is browser x, version y".
It has challenges in terms of distribution - the font environment, decompressed is probably around 200-400MB depending on locale support.

[uazo]

Run the browser with its own font environment

seems the most logical choice to me and is what I have implemented in cromite for android uazo/cromite#1829

decompressed is probably around 200-400MB depending on locale support.

approximately 60 mb for a complete font set

[svgeesus]

Also relevant, being incubated in WICG: Local Font Access API. It has a Privacy Section which notes fingerprinting risk from not only the font names but also detailed data such as font version.