[css-fonts] Exploring better ways to balance privacy, i18n, design tradeoffs for local fonts

[LeaVerou]

Background

Apple has restricted access to non-system local fonts in WebKit (this includes both font names in font-family as well as the local() function in @font-face) and does not wish to go back on this. While this is effective for curbing font-based fingerprinting (see #4055), it has raised several concerns:

• i18n: Users of certain languages are dependent on local fonts to access website content in their language. These fonts are too large to be included as web fonts.
• This unfairly privileges certain scripts with few characters and effectively restricts web design in certain locales to system fonts, as web fonts are not a tractable solution for many languages, including several East Asian languages. Double-keyed caching has made that even less of a viable option.
• In many cases, web fonts are not a valid solution due to font licensing (if I have a legal copy of Adobe Caslon Pro, I should be able to view content using it without the website author or me needing a web font permitting license)
• Even for cases where web fonts are a viable solution, the carbon footprint of all these pointless repeated downloads is not negligible and in many developing countries bandwidth is very expensive, so this also privileges Western locales.

To sum up, the current solution goes against the following Ethical Web Principles:

• "The Web is for all people"
• "The Web is an environmentally sustainable platform"

I’m not suggesting we should just accept font-based fingerprinting, but I'm hoping we can find a better balance of tradeoffs than throwing out the baby with the bathwater.

Proposal: Limiting local font access per origin

What if, instead of entirely cutting off access to local fonts we only allow N fonts per origin (with a reasonably small N, e.g. 8)? It seems that for most use cases this would be sufficient, and still minimize or even eliminate font-based fingerprinting.

It is often argued that for certain fonts (the ones necessary for the i18n cases) simply the presence of a single font can narrow down the user quite a lot. But it seems to me that in that case, the user's locale and HTTP headers would narrow things down just as much.

Should misses count towards the limit?

Font access would only "register" when the font is actually used, e.g. if I specify a font stack like Adobe Caslon Pro, Adobe Garamond, Hoefler Text, serif; this doesn't use up 3 fonts from that origin, but only one (the one actually applied).

It could be argued that then we have more bits of entropy, because if we can detect that it's Hoefler Text that is being applied we also know that Adobe Caslon Pro and Adobe Garamond are not installed. But given that the set of fonts that exist is huge, and most fingerprinting depends on which fonts you do have, it may be an acceptable tradeoff. If misses also count towards the limit, we'd need a larger limit (around 3x larger I'd suggest).

System fonts would not count towards the limit since they do not add bits of entropy anyway. Also, this would count families, not faces. I.e. using ten weights from a font does not use up 10 fonts from the limit. This is important for websites to display properly, and only uses up a small bit of additional entropy.

Who manages this data and for how long?

The UA would manage which local fonts have been accessed for each origin, and this would expire after a certain period (a month? a year? more research needed about what's the shortest period that still curbs fingerprinting) so that websites don't have to be locked in to their
original font choices until the end of time. It is also cleared when the user clears local data.

What about incognito mode? Same as other private data: the browser can still enforce the limit, and just delete the data after the session.

Contexts allowed to obtain local font access

What about iframes? With a naive implementation of this proposal, fingerprinting could just be split across multiple collaborating origins. There could even be a fingerprinting-as-a-service SaaS: a service that sets up hundreds of origins, each detecting 8 additional fonts, and combines the results to identify users. Websites would then just include a page from this company in an iframe, and that would in turn iframe all other origins.

To prevent this scenario, I propose differentiating when an origin can obtain access to a local font and when it can just use local fonts already accessed, without accessing new ones. A website would need to be accessed at the top-level to obtain access to a local font. Iframes can only use local fonts the origin has already obtained access to. We may want to restrict this further, making additional contexts use-only (canvas? dynamically inserted CSS?).

[Crissov]

#5421 is still open.

[jfkthame]

Regarding this point:

* It could be argued that for certain fonts (the ones necessary for the i18n cases) simply the presence of a single font can narrow down the user quite a lot, but it seems to me that in that case, the user's locale would narrow things down just as much.

I'm not sure that's a very strong counter-argument, because of the possibility that "the user's locale" (as far as the site can determine it) will still be a major-language/region locale, not one that reflects their interest in a particular language. Identifying which minority-language fonts I have installed would provide much more fingerprinting entropy than simply knowing my locale.

[kbabbitt]

It could be argued that then we have more bits of entropy, because if we can detect that it's Hoefler Text that is being applied we also know that Adobe Caslon Pro and Adobe Garamond are not installed. However, I think it would be pretty hard to detect this in the general case without actually accessing the first two fonts (i.e. apply them without a fallback).

I think it might be possible using <canvas>. Call CanvasRenderingContext2D.font = '<long-list-of-fonts>', draw a distinguishing glyph, then use getImageData() to read back the result and compare to known renders. Once the applied font has been identified, trim the front of the list up to and including that font, then repeat to find the next installed font.

[svgeesus]

FWIW, heres another suggestion you all may have already considered and discarded (but maybe not!): discarding the OS vs installed distinction, and instead limiting the number of font-faces that an site / eTLD+1 can reference within the lifetime a storage partition. Like i said, maybe you all have considered and discarded the idea, but this kind of "budgeting approach" might be successful for fonts in a way I dont think its practical for addressing fingerprinting concerns in general (for example, benign font-face selection might be consistent in a way that a sites overall "set of Web APIs used" is not).

Originally posted by @pes10k in #5421

[LeaVerou]

I'm not sure that's a very strong counter-argument, because of the possibility that "the user's locale" (as far as the site can determine it) will still be a major-language/region locale, not one that reflects their interest in a particular language. Identifying which minority-language fonts I have installed would provide much more fingerprinting entropy than simply knowing my locale.

I was referring to the HTTP headers too, updated the OP to make that more clear.

I think it might be possible using <canvas>. Call CanvasRenderingContext2D.font = '<long-list-of-fonts>', draw a distinguishing glyph, then use getImageData() to read back the result and compare to known renders. Once the applied font has been identified, trim the front of the list up to and including that font, then repeat to find the next installed font.

Ooh, that's a good point. Although most fingerprinting is about the fonts you have, and you'd eventually hit the limit (though you could start from the rarest fonts, and then you only need to identify a few). I updated the OP with a concept of "contexts that can obtain access" vs "contexts that can only use (already obtained) local fonts, perhaps that could be a solution. Or just a (significantly) larger limit, and having misses count too.

[css-meeting-bot]

The CSS Working Group just discussed [css-fonts] Exploring better ways to balance privacy, i18n, design tradeoffs for local fonts.

The full IRC log of that discussion

<emilio> lea: for background we've been discussing this in #5421, but the issue is not only i18n, but there's also issues for authors on regular locales
<emilio> ... web fonts are not always viable for type settings
<emilio> ... even in locales where they are, it increases bandwidth
<emilio> ... so it some sense it also privileges western locales
<emilio> ... so proposal is 'what if we cap the access to a very small number of local fonts per origin'
<emilio> ... that'd also mitigate fingerprinting, which depends on a small number of fonts
<emilio> s/small/large
<emilio> ... it's been brought up that for some minority languages a single font can pinpoint a user a lot
<emilio> ... but the accept-language header does the narrowing already in those cases
<emilio> ... so what counts as font access?
<emilio> ... ideally system font access doesn't count
<emilio> ... fonts after the used font don't count
<emilio> ... but if I have font 1, font 2, font 3 and we use 2, does 1 count?
<emilio> ... we could go either way but if we make them count
<emilio> ... then the limit needs to be bigger
<emilio> ... the data should be managed by the UA
<emilio> ... much like cookies or what not
<emilio> ... the other question is what about iframes?
<emilio> ... in theory there could be even fingerprinting as a service, where it loads tons of iframes of different origins that detect ~8 fonts
<emilio> ... I think only toplevels could get access to fonts, and other contexts would only have access if the top has access
<astearns> q+ to ask about other context’s ability to ask the top-level context for access
<r12a> q+
<emilio> ... which means if you're iframe google login, google would have access to fonts it obtained as a toplevel
<emilio> ... I think that's basically all
<jfkthame> q+
<emilio> astearns: I like the idea of only allowing the toplevel context
<emilio> ... is it possible for an iframe/canvas to request for the toplevel frame to get a font?
<astearns> ack astearns
<Zakim> astearns, you wanted to ask about other context’s ability to ask the top-level context for access
<emilio> lea: haven't thought of it before but ideally you want to limit permission prompts
<emilio> ... if you genuinely allow this you provide a link with `target="parent"`
<astearns> ack r12a
<emilio> ... that still prevents the malicious iframe case
<emilio> r12a: I think the less the user needs to be involved the better
<r12a> Felipe's proposal: https://github.com//issues/4497#issuecomment-763459971
<emilio> ... but I think there are some exceptions
<florian> q?
<astearns> ack jfkthame
<emilio> ... felipe's proposal could be useful
<lea> q?
<emilio> jfkthame: one concern I have with this proposal of a per-site budget is that it seems it could lead to situations where the site ends up behaving differently depending on the particular path the user gets to the page
<florian> q+
<lea> q+
<astearns> ack florian
<emilio> ... that can be very confusing and difficult to understand and diagnose
<emilio> florian: re. whether we should count misses, I think we need to
<emilio> ... otherwise it'd be pretty effective to build a giant font list
<emilio> ... where you have one hit but 300 very specific misses
<emilio> lea: I think you're right
<astearns> ack lea
<dbaron> s/giant font list/giant font list and go through starting from the rarest/
<emilio> ... the idea is that most fingerprinting is about the ones you do have rather than not
<emilio> ... but if you get access to 8 narrow / niche fonts that gives you ton of behavior
<emilio> lea: re. jfkthame's question, the website shouldn't behave differently because the site manages the data
<emilio> q+
<smfr> q+
<kbabbitt> q+
<bramus> scribe+
<astearns> ack emilio
<emilio> ... the idea is that fingerprinting needs a lot of fonts and websites would not hit the limit
<bramus> emilio: i dont agree that users would sually hid that, even manageed by the browser
<bramus> … eg pages with things which happen to have glypsh that I dont ahve installed
<bramus> … now the 6th page or 8th page that I visit hits that limit, and i would not see it
<ydaniv> s/hid/hit/
<bramus> … which i think is what jonathan is concerned about
<bramus> … disagree that its an unrealistic situation
<bramus> … imagine i visit one of richards pages and hit the limit, and then it suddenly stops working when i hit the limit
<lea> s/ the idea is that fingerprinting needs a lot of fonts and websites would not hit the limit/ I tend to agree with florian. The idea was that fingerprinting is more around which fonts you _do_ have, but indeed, knowing about 8 niche fonts does give you a lot of bits of entropy. To reply to jfkthame's concern, the idea is that the limit is designed is such a way that the vast majority of legit websites would not hit the limit
<bramus> … seems relatively common
<lea> s/ the idea is that fingerprinting needs a lot of fonts and websites would not hit the limit/ I tend to agree with florian. The idea was that fingerprinting is more around which fonts you _do_ have, but indeed, knowing about 8 niche fonts does give you a lot of bits of entropy. To reply to jfkthame's concern, the idea is that the limit is designed is such a way that the vast majority of legit websites would not hit the limit/
<bramus> … also, q about the persistence thing
<bramus> … reason is to avoid case where page navigates and you hit differen tnumer of fonts –annoying
<bramus> … making the budget persistent feels …
<bramus> astearns: you make it persistent over a certain time frame
<lea> q+
<bramus> … so dipping into a list takes too long
<bramus> emilio: leads to less determinism
<bramus> … do they rememember that i visited the page x months ago?
<astearns> ack smfr
<emilio> smfr: I disagree that you need a lot of user installed fonts to get a fingerprint
<emilio> ... fonts are a very high signal vector
<kbabbitt> q-
<astearns> ack dbaron
<florian> q+
<emilio> ... so a single font might identify it as a minority user that might be very high value signal for some people
<lea> qq+ to reply to dbaron
<emilio> dbaron: two comments, wasn't clear to me how much this proposal is targetting font stacks or values of font-family vs. fonts you actually use even if you use them by last-resort-fallback when you fail to find stuff in the font-family list
<emilio> ... I think it's worth being clear about that
<emilio> ... the other comments is it's not clear how a privacy mitigation imposing specific limits interacts with things like bounce tracking
<emilio> ... and whether it's been solved at this poing
<emilio> s/poing/pont
<astearns> ack lea
<Zakim> lea, you wanted to react to dbaron to reply to dbaron
<emilio> s/pont/point
<emilio> lea: a font would only count only when accessed
<emilio> ... so only when the font is being queried
<emilio> ... if you have a stack of 5 fonts and you use font # you've used 3 fonts not 5
<emilio> ... same with font-face, each local() lookup
<emilio> dbaron: I think it's worth noting font fallback is per char
<emilio> ... but one character might go through the whole list and then fall back to a system search
<bramus> emilio: except you want it to be a user font
<emilio> lea: yeah a system fallback is usually a system font
<emilio> ... I think these would be handled fine with a well defined limit
<astearns> ack lea
<emilio> lea: I didn't quite understand the wikipedia argument from emilio
<emilio> ... what about a website that has a lot of languages
<emilio> ... is kind of the same argument
<emilio> ... you usually get one or two languages
<dbaron> I think displaying a language selector may be a common case.
<emilio> ... I don't think going through all languages is common
<emilio> r12a: some of us do that
<emilio> q+
<bramus> emilio: yeah, wikipedia hits a lot of font fallback because of their sidebar with all fonts
<bramus> … the characters are there on the page, even if i dont speak it
<bramus> … wikipedia would hit the reasonable limit
<dholbert> (^in the choose-your-language dropdown in particular)
<bramus> lea: webfonts dont count in this case
<bramus> emilio: i dont think they use that
<lea> q?
<bramus> … using the webfont is what they not want to happen
<bramus> … a lang selector is a use case where you may have chars from many langs
<bramus> … even when reading wikipedia in your language, there can be names with other chars
<bramus> lea: are you sure wikipedia is not using system installed fonts?
<bramus> emilio: i think its easy to hit the case that jonathan mentioned
<bramus> florian: lets refocus on trying to solve the i18n problem
<bramus> s/florian/fantasai
<astearns> ack florian
<bramus> … lets try and solve the worst part of the problem
<emilio> florian: in a way I agree and in a way I don't
<emilio> ... we want a mandatory solution
<r12a> q+
<emilio> ... so we need to make it work not only for the i18n use case
<emilio> ... if it's mandatory and breaks other use cases is not good enough
<emilio> ... we need to keep the web functional
<emilio> fantasai: I don't think loading ?? is a requirement to keep the web functional
<bramus> s/??/hoefler
<fantasai> s/??/a local copy of Hoefler/
<bramus> q+
<emilio> florian: if we make it work for minority languages but the wikipedia language selector doesn't work that's wrong
<emilio> ... re smfr comment, yeah minority communities are easy to target
<emilio> ... but it goes both ways
<emilio> ... the best way to preserve their privacy would be to not get websites in their language, which would be unfortunate
<ChrisL> Exactly
<astearns> unacceptable, not unfortunate
<emilio> jensimmons: it feels a large part of this is debating whether fingerprinting or i18n is more important
<r12a> qq+
<emilio> ... I think we should just discuss about solutions instead
<emilio> florian: was not my intent
<lea> jensimmons: I thought that's exactly what we were doing?
<emilio> florian: but current solutions favor one over other
<emilio> ... agreed we need to fix both
<astearns> ack r12a
<Zakim> r12a, you wanted to react to florian
<emilio> r12a: re. jensimmons's comment I don't think anybody is framing things in those terms
<emilio> ... that sets up the principle that we should have both
<emilio> ... I think we've established that on the spec already
<emilio> ... and I'm wondering why we're discussing these solutions... are we going to put them in the spec?
<emilio> astearns: I think the idea is to put them in the spec
<ChrisL> q+
<florian> s/the best way to preserve their privacy would be to not get websites in their language, which would be unfortunate/A very effective way to preserve privacy for a minority group would be to let them use the web at all, which is effectively what happens when their language doesn't work, but that's not a real solution
<r12a> q-
<noamr> I wonder if we can do something about limiting this on the measuring side
<astearns> ack ChrisL
<emilio> ChrisL: yeah we're specifically looking for things that are going to be in the spec because what we have right now is too vague and too optional
<florian> s/would be to let them use /would be to not let them use
<astearns> ack fantasai
<emilio> fantasai: before we continue, do we agree that allowing user installed fonts is necessary to solving i18n?
<ChrisL> qq+
<emilio> ... because maybe the solution is for the OS to ship more fonts
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to react to fantasai
<fantasai> s/maybe/I've heard people assert/
<emilio> ChrisL: it cannot be solved by shipping good fonts, it's not just char coverage
<emilio> ... it's also rendering and per script differences
<r12a> qq+
<emilio> ... one good font to rule them all is not going to solve it
<weinig> q+
<emilio> fantasai: that's your position, is that the working group position?
<emilio> ... are there people that this is solved by the OS shipping the correct amount of fonts?
<fantasai> s/that this/that believe this/
<emilio> astearns: I think I've been convinced by the examples that we need local font access in some cases
<emilio> smfr: there are no user installed fonts on many mobile OSes
<emilio> ... e.g. iOS doesn't have the concept of user installed fonts
<ChrisL> qq+
<emilio> ... not sure what the situation is on android
<astearns> ack r12a
<Zakim> r12a, you wanted to react to ChrisL
<emilio> r12a: the long list on IRC earlier list situations where you might not be able to get away with the fallback to system fonts
<emilio> ... the browsers currently don't support the need of users around the world
<emilio> ... maybe because there's no system fonts, or because they're not diverse enough
<noamr> q+
<romain> Would it be sufficient to place severe limits on local fonts on offscreen content?
<romain> Seems that any finger printing technique would prefer to do this without the user noticing and will use non-visible text.
<romain> Only allowing local fonts for visible and in viewport content might be an acceptable compromise?
<emilio> ... e.g. safari with the kashmiri font is not present, and if you downloaded the noto font
<emilio> ... you can still don't have access to the right script
<emilio> ... I work with minority scripts a lot and I don't think system fonts cover the long tail
<florian> q+
<astearns> ack ChrisL
<Zakim> ChrisL, you wanted to react to ChrisL
<ChrisL> q?
<emilio> ChrisL: responding to simon, the point is not that some have user fonts, on the platforms that do users shouldn't be penalyzed by not using them
<emilio> ... for OSes that don't have user fonts we need some other solution
<astearns> ack florian
<emilio> ChrisL: Is it worth putting a question of whether local font access is the group position?
<emilio> florian: to me what safari does should not be forbidden
<emilio> ... but it can't be required of everyone
<emilio> ... but do we want to require that all browsers must give access to local fonts? I don't think so
<emilio> ... can we mandate that nobody does?
<emilio> ... probably not either
<emilio> ... it's a UA tradeoff, the web as a whole can't choose for which users you prioritize
<florian> s/browsers must give access /browsers must deny access
<emilio> ChrisL: seems to weak to be actionable. My preferred solution I would rather peek one or the other that seems very exclusionary
<emilio> ... implementations that do that should be non-compliant with the spec
<emilio> astearns: I think we table this because the exact framing is important
<astearns> ack emilio
<bramus> emilio: i dont think this framing is ???
<noamr> exclusionary
<bramus> … lets say we dont want to give access to random fonts
<astearns> s/???/necessarily exclusionary/
<bramus> … firefox bundles emoji fonts
<bramus> … so could bundle fonts for minority scripts and langs
<bramus> … agree to not exclude users by restricinting thing
<noamr> I think I have an actionable direction idea, hope I get an opportunity
<bramus> … but there might be other solutions
<bramus> … in the apple case they can install a bunch of fonts in the OS but would not fix every page ever but that would be a decent tradefoff
<astearns> ack bramus
<ChrisL> s/rather peek/rather not pick/
<emilio> bramus: one of the things I like about iOS is that whenever an app needs the camera roll I can choose which photos
<dbaron> (Android does that too)
<emilio> ... could we do something like that for fonts?
<florian> +1
<emilio> ... where basic fonts are fine but you don't over share, and you can handle r12a's use case
<romain> +1
<emilio> iank_: there's problems with that apparoach
<r12a> qq+
<emilio> ... [missed]
<emilio> astearns: the design of an opt in is a different feature from a budget
<emilio> bramus: it could be an alternative for a magic budget number
<emilio> astearns: or it could be both
<emilio> florian: details can be discussed or not
<astearns> ack dbaron
<emilio> ... but the existance of opt in changes the equation of whether budget needs to deal with all sites
<ChrisL> q?
<emilio> dbaron: florian made a list of requirements of a solution should be
<florian> s/discussed or not/discussed separately
<emilio> ... wanted to add one
<emilio> ... if we're going to have a solution in the spec we need to do enough analysis that it's really blocking some amount of entropy that's real
<emilio> ... and not just making it harder to get those bits
<emilio> ... this requires some detailed analysis
<emilio> ... the concern is that we say we found an answer and we don't do that analysis
<emilio> ... we're asking implementors to spend time implementing something that doesn't meet the goals
<bramus> s/where basic fonts are fine but you don't over share, and you can handle r12a's use case/where basic fonts are fine but you don't over share, and you can handle r12a's use case. sharing fonts could even be limited to a per-site or per-origin basis.
<ChrisL> dbaron ++
<astearns> ack r12a
<Zakim> r12a, you wanted to react to bramus
<emilio> ... we should make sure that this solution meets the privacy goals in addition to the i18n requirements
<emilio> r12a: I want to be wary about the "this is probably good enough" approach
<emilio> ... we are discussing scripts for which they are not system fonts
<emilio> ... people would be designing fonts and see how they look like on the browser
<emilio> ... can't use safari anymore for that sort of work
<astearns> ack weinig
<emilio> weinig: This seems like litigating thigns that are not usually what the WG works on. Wonder if there's similar privacy issues that have been solved in similar ways
<emilio> ... we don't even define past the UA so I wonder if there's a good parallel to take inspiration
<bramus> emilio: the ?? mitigation stuff comes to mind, where all browsers implement an interoperable pricacy mitigations, like :visited where we all lie in gCS
<kbabbitt> s/??/:visited/
<emilio> florian: we also allow but not require the browser to lie about window / screen / position
<emilio> weinig: that'd be in favor of the current status quo
<emilio> astearns: a number of features that impact privacy that we rely on wide review
<emilio> ... we don't have that much privacy expertise
<emilio> ... but we run into these issue and deal with them with the privacy groups that do
<emilio> ... while you're right that the OS bits are not our usual domain, fonts are
<emilio> weinig: would be good to set bounds on what potential solutions would look loike
<emilio> ... lots of options from prompting on any use to budget to UI in browser preferences
<emilio> ... setting those bounds would help
<astearns> q?
<r12a> s/we are discussing scripts for which they are not system fonts /for example, in the Unicode committee meeting i will be attending in a few minutes we are discussing scripts for which we are a long way from having pre-installed fonts
<emilio> ... e.g. would be an issue if safari allowed the user to explicitly use these fonts in an advanced preference
<emilio> ... would that be a solution that's reasonable?
<smfr> q+
<r12a> s/people would be designing fonts /also people would be designing fonts /
<astearns> ack noamr
<emilio> noamr: Another mitigation could be to treat local font as if they were webfonts but still allow them to load would work perhaps
<emilio> ... delaying the local font availability or what not, the tracking page can't tell if it was downloaded as a web font vs it was a local font
<emilio> ... maybe the issue is that this is explicitly a local font that might not need to be?
<emilio> astearns: that might have merit
<emilio> ... would be good to discuss in a different issue
<ChrisL> and we already have, in the spec "Web Fonts shadow Installed Fonts, so if an Installed Font has the same family name as a Web Font, the Installed Font is not accessible." which would cover that case
<astearns> ack smfr
<emilio> ... I don't think this would be sufficient because the page knows if it has requested a @font-face
<florian> s/it's a UA tradeoff, the web as a whole can't choose for which users you prioritize/it's OK as a UA tradeoff to prioritize the experience of some users at the expense of not serving everyone, but the web as a whole cannot, it has to serve everyone
<emilio> smfr: imagine we fix this by having the ua download a web font when it sees glyphs in a particular unicode range
<emilio> ... maybe there are solutions that aren't about user installed fonts
<noamr> I think we suggested a similar thing smfr :)
<emilio> ... but UAs solving it in creative ways
<emilio> astearns: I think separate issues for separate proposals would be good
<emilio> ... anything else?

[pes10k]

Im encouraged by the ongoing discussion here! However, I do not think think this approach would address the privacy concern, for several reasons:

• allowing sites to access 8 (or even << 8) system fonts is a tremendous amount of fingerprinting surface
• as the proposal partially notes, this proposal, in its initial form, provides an unbounded amount of fingerprinting surface. If the limit is "you can load up to N system fonts", then presumably this means websites are able to check for for fonts until they've found N fonts the user has installed (which would mean a potentially infinite number of checks). No/0 fingerprinting "bits" can be just as identifying as yes/1 bits. The assumption that "most fingerprinting depends on which fonts you do have" is not correct.
• tying which fonts a site can access in a 3p/iframe/etc context to what fonts the sites previously accessed in the 1p/top-level-frame context opens up all sorts of third-party tracking vectors, and undoes the protections that dual-keying storage imposes.

[pes10k]

here are some suggestions to the group, for addressing the privacy risk here without harming the i18n use cases (which I agree are critical). The details would matter here, and one of these alone might not be enough to address the problem in isolation, or they might have other issues im not anticipating that would prevent them from being useful privacy protections, but theres are directions I don't see being discussed and I hope might help.

• A permission model: Straw-wording, but something along the lines of:

    [ ] block font access
    [ ] allow for this page
    [ ] allow for all pages.

You could even try framing the above differently, not even mentioning fonts, but just asking if the page looks rendered oddly.

• Only allowing font access if it would apply to a significant amount of rendered, visible page text, and put a non-trivial delay on changing the font applied to rendered text.

(I also think the list-based approach would be very effective, and im skeptical of the practicality issues that have been raised. I know this approach has been discussed elsewhere, but im just adding it here for completeness)

[pes10k]

re-sharing an idea from email with @astearns (w/ minor clarity and concision edits)

Heres an idea: allow the browser to access an unlimited number local fonts until a look up failed, after which all subsequent look ups would fail. You’d need to tie that “just one fail” check to the current storage area’s lifetime (otherwise you’d be able to check another font on each page load / session / whatever) and that’d reintroduce the problem over time (since previous checks could be stored in storage).

I wonder what you all think of this idea. I’ve just thought about it now, so im not confident on it. But it has the appealing property of allowing sites to access fonts that are truely necessary to access the page, while preventing fishing for other fonts. I wonder what you think of this idea?