Skip to content
This repository has been archived by the owner on Nov 7, 2024. It is now read-only.

Address issues around reliance on locally installed fonts #2

Open
asankah opened this issue Feb 15, 2020 · 15 comments
Open

Address issues around reliance on locally installed fonts #2

asankah opened this issue Feb 15, 2020 · 15 comments

Comments

@asankah
Copy link

asankah commented Feb 15, 2020

We should consider the existence of legacy websites that ask users to install a font in order to display their content correctly. These sites may not migrate to web fonts anytime soon. At the same time we don't want to break them.

While their prevalence is being measured, we should acknowledge their existence and propose mitigations that smudge the identifiability of such fonts. E.g. by having the UA know about popular fonts that are typically only installed locally, and map them to equivalent web fonts.

@astearns
Copy link

When we discover situations like this, why not allow those particular local fonts to be used? I don't understand the value of mapping to 'equivalent' web fonts here.

@tabatkins
Copy link
Collaborator

Yeah, to the extent that we can discover these and don't expect a webfont migration, I expect these can be considered for inclusion in the cross-browser "allowed local fonts" list (which is then auto-installed by browsers).

@astearns
Copy link

If that's the case, then we're back to maintaining a list. So at that point the main difference between this proposal and what's being discussed in w3c/csswg-drafts#4497 is the caching strategy?

@tabatkins
Copy link
Collaborator

Not quite. I think we hope that licensing issues can be ironed out to allow browsers to install the same set of local fonts across OSes, so they're actually dependable to web authors.

@Crissov
Copy link

Crissov commented Feb 19, 2020

As far as I understand the current text, e. g. this part:

Browsers will only allow use of pre-installed fonts in places like the @font-face src: local() function and the font-family property

this would disable users from manually caching fonts, which they encounter either frequently or rarely but then are a huge WOFF download, by installing the respective OTF/TTF to their local OS, because they would now be considered second-class citizens, being labeled as “user-installed” which currently is not distinguished from “pre-installed” (at least not on the app level where the browser lives).

@tabatkins
Copy link
Collaborator

This is correct.

@jyasskin
Copy link
Member

As @asankah alluded to, we will have to measure how many users manually cache fonts in the way @Crissov says. @Crissov, do you have a sense for how many users you'd be willing to break?

@astearns
Copy link

I think there are (at least) two separate classes of users to consider here.

The first (and likely most important) is a set who use websites with content that requires particular fonts, where there's a pre-webfont workflow established with local font installs. Hopefully we can identify most/all of the sites and scripts in this set and merely add these local fonts to the allowed list.

A second set are people who find and install local fonts in order to avoid WOFF downloads. For these people, I expect a browser pref that lets them opt-in to using all of their local fonts for some or all of the domains they visit will suffice.

@jyasskin
Copy link
Member

I agree with the two classes of users. We'll still need to pick a threshold number of users it's ok to break. For the first set, there are likely to be some locally-installed fonts that we can't add to the allowed set, either because we can't find them at all or because we can't get licenses to auto-install them. For the second set, not all users will find the browser pref.

@astearns
Copy link

I'm not sure what you mean by "can't add to the allowed set."

If (for example) the Klingon community has a mass of websites that expect people to have the "pIqaD" font installed, and those sites currently work fine for those users (and would fail without the local font), then user agents should continue to allow access to local "pIqaD" fonts.

@jyasskin
Copy link
Member

Ah, so, if there are some people who have "plqaD" installed, and some who don't, and the browser allows more than one site to detect that, that's at least a bit of fingerprinting information. Right now, this explainer plans to eliminate all fingerprinting information beyond the (locale/browser/OS) triple. We could instead plan to allow N bits, where N<<log2(sizeof(locale/browser/OS)), which probably only allows 1 to several fonts per triple, depending on those fonts' arrangement in users' clients. If there are 20 fonts in a locale that have a mass of websites that depend on them, we'll have to break some of those users.

Maybe we'll get lucky, and the measurement @asankah's team is working on will discover that each locale only has 1 critical font, in which case I'd argue it's reasonable to allow it. I'm not expecting us to get that lucky.

@astearns
Copy link

I guess I have been thinking of this work as being harm reduction more than harm elimination.

I also think we are not going to be lucky for all locale/browser/OS combinations, and that we'll find some combinations where we will not be able to avoid allowing some font fingerprinting leakage. But most locale/browser/OS combinations should be OK with a strict ban on local fonts. Being able to eliminate font fingerprinting for most is worthwhile, and can be done while we work on a more complete fix.

@Crissov
Copy link

Crissov commented Feb 21, 2020

I assume that the part of the print industry that uses X/HTML+CSS to PDF/ebook/image converters relies on support for arbitrary local fonts. If such converters use existing browser engines under the hood – and some do – care must be taken that they can still use any OTFs/TTFs they want. CSS authors may not have the knowledge or license privileges to copy fonts from the global font folder into their project folder, where they could be used without local().

@jyasskin
Copy link
Member

@Crissov I think that use case will need a new API. https://github.com/inexorabletash/font-enumeration/blob/master/README.md starts discussing it, but I think we should also consider something more like <input type=font> or https://github.com/WICG/contact-api.

@tabatkins
Copy link
Collaborator

In comments from Richard Ishida (w3c/csswg-drafts#4497 (comment), w3c/csswg-drafts#4497 (comment), w3c/csswg-drafts#4497 (comment)), he lays out some reasonable arguments for allowing people to purposely opt in to exposing particular local fonts they want a page to be able to use.

Something like the Contact Picker API could work: it lets us scope the exposure to particular origins that request it, rather than increasing their fingerprinting surface for all sites.

We should make sure to capture this as a goal, I think.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants