Add the install-your-fonts proposal as an option

[pes10k]

I haven't fully integrated the proposal into the text (e.g. if we go this route, text further down doesn't make sense), but wanted to write the proposal down.

TL;DR;

• The problem is the long tail fonts on the system users don't want browsers to know about
• Font people want sites to know about are much less likely to be identifying. For example, they'll be in overlapping anonymity sets with locale
• Building lists is difficult and makes the web crusty and ossified (though lists are better than nothing)
• Building mega caches is expensive and doesn't solve all use cases
• Users who intentionally want certain fonts in the browser are likely to already be taking extra steps (seeking and installing the language specific font(s), installing a font for local dev work, etc)

We can solve all the above by removing ambiguity about which fonts users want browsers to know about.

[jyasskin]

@pes10k Sorry for the long delay getting back to this. I've updated it to present this as one of several options that we haven't decided between. I think I want to describe pros and cons here too, eventually, but it'd be good to have all the options listed before we write that.

What do you think about this text?

[pes10k]

Thanks for these changes @jyasskin . To comments:

1. I think this text should be removed:

   * Web users who have been installing web fonts over cheap connections to avoid
   spending money or time downloading them on expensive or slow connections,
   shouldn't now have to use the expensive or slow connections.

The problem of how to prevent people from being fingerprinted based on fonts, and web perf issues, are not-un-related, but pretty distinct. I'd prefer to remove this perf-improvement as a goal of the proposal / issue, and just treat it as a constraint (e.g. the solution arrived to shouldn't foreclose future per improvements).

2. I don't know if the text belongs here, or in another PR, but I want to propose another option, kind of a middle ground between "each user agent does its own thing" and "user agents by default do just OS fonts, with users responsible for making more fonts available".

That proposal is:

1. browsers have a global, user configurable setting, called (something like) Fonts / Web Fonts / Web Available Fonts, etc. It is specifically not labeled as privacy feature, to match the constraints given by some vendors
2. the setting has two options, default and custom
3. default is semi-undefined, and up to the user agent, but MUST include all OS provided fonts, and MUST be less than all fonts the OS / browser knows about. How the user agent decides on that set is up to the user agent (more below). default is… of course… the initially configured option.
4. custom is whatever the user selects (e.g like the initial PR here, the user is presented with all the fonts the browser knows about LESS the OS fonts, and users can opt the additional fonts in)
5. vendors can work together to build possible lists for default, either through a venue like CSSWG, or externally a la public suffix list. These lists are sets of additional fonts users are expected to want, per os, default local tuple, built through a system undefined by the spec, but expected to be through crawls identifying fonts needed to fulfill the Websites that depend on a font that's commonly installed among their visitors but uncommon on the web, should have a way to continue working use case. Vendors MAY use this list when determining the default configuration.

I would volunteer to, alone or with other members of PING / CSSWG / PrivacyCG / etc, work on the infrastructure for this list.

[jyasskin]

1. I don't see a difference between treating "don't regress performance too much" as a "goal" vs a "constraint". My understanding is that that's one of the reasons the CSS folks objected to the solution of just restricting to OS-provided fonts, so I think it does belong here, unless one the CSS folks (@astearns?) says my understanding is wrong. That doesn't mean we're trying to improve performance with this change, just avoid regressing it.

2. This proposal looks the same as the text here? There's some initial list, here described as the "Allowed system fonts", and then users can add fonts manually. Is the problem that my description of "Allowed system fonts" is bad or doesn't say that they should be allowed in addition to the other sets? If that's it, let's do it in another PR to avoid cluttering this one.

[pes10k]

re 1. yes that would be good to have clarity on, that was not my understanding from the call. My understanding from the call was the "absolutely cannot break" cases were (i) sites that expect but don't request a font, and (ii) don't break uses like PDF renderers

2. the difference here is that this proposal allows for a default broader than OS fonts, but narrower than everything. The current "Allowed system fonts" in the current text, if im reading it correctly, seems to only include OS-provided fonts

[tabatkins]

Yes, solutions that require minority-language users to switch to webfonts while letting majority languages rely on installed fonts are an unacceptable a11y/i18n regression. That's the reason for all the additional stuff around tracking font usage/etc.

[pes10k]

Sure, but i think thats answering a similar-but-unrelated question.

All the stuff about "tracking font usage" can be captured in the default font allowed list in my proposal above.

The question is is perf-loss for reasons unrelated to minority languages a deal breaker. (the above proposal would prevent the perf loss for minority languages through the default configuration / list building)

[pes10k]

or, even more subtle, i guess the question scrapes down to, is perf loss in cases (i) unrelated to minority language status, (ii) limited to default configuration, acceptable.

Advanced users can still opt in their only-for-perf-improving fonts through the above proposal

[tabatkins]

No, outside of minority langs it's fine; people installing fonts locally just for themselves is an acceptable loss.

[jyasskin]

@pes10k

2. the difference here is that this proposal allows for a default broader than OS fonts, but narrower than everything. The current "Allowed system fonts" in the current text, if im reading it correctly, seems to only include OS-provided fonts

My intent there was that the browser could also provide "system" fonts, but that's not clear enough. I think we should fix that in another PR.

[pes10k]

@jyasskin im happy to write up another PR, but the organization of this is getting difficult. What I'm proposing is an alternative to "solve the problem with a mega cache" proposal in master. Where would you like me to put this PR: off master, or a PR to this PR?

[jyasskin]

@jyasskin im happy to write up another PR, but the organization of this is getting difficult. What I'm proposing is an alternative to "solve the problem with a mega cache" proposal in master. Where would you like me to put this PR: off master, or a PR to this PR?

For editing the "Allowed system fonts" section to be clear that the browser is allowed or encouraged to add fonts, it should be a PR against main, since that's an improvement even without this PR, and it doesn't conflict with this PR.

[pes10k]

@jyasskin hmm, i'm not sure I understand. Right now there seem to be there proposals under discussion:

1. sites can access OS fonts, or lazy-load some set of known-but-not-loaded fonts from central font registry (master)
2. sites can only use OS-provided fonts by default, users intentionally choose additional fonts they want the browser to use (this PR)
3. sites can use intersection of OS fonts + "unspecified vendor defined set of fonts" by default, with user opt in for additional fonts (https://github.com/w3cping/font-anti-fingerprinting/pull/6#issuecomment-599359211)

I only mean for additions to "allowed system fonts" to apply for 3 and 2. I don't yet have an understanding of how it'd interact with 1.

[svgeesus]

I would prefer to see this merged and discussions to continue as needed, because keeping the diff in my head as I read the main document is confusing

[pes10k]

I don't think there is anything waiting on me to merge the above (I think i've addressed all the outstanding questions), but if thats not the case, and I'm the blocker for merging things, please let me know.

If it'd be easier, we could also just replace most of this PR with a pointer to the Brave proposal too