Closed pes10k closed 9 months ago
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 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 (for Firefox) @tabatkins (for Chrome) @litherum (for Safari) any thoughts on the desirability and implementability of the proposal by @snyderp ?
The statement in https://github.com/w3c/csswg-drafts/issues/4497#issue-519535119 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)
.
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 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.
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:
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).
I'm also concerned this proposal would make fingerprinting worse because users would unintentionally select random different subsets of fonts.
Yeah, having users choose a set of fonts makes no sense for the purpose of avoiding fingerprinting.
I suspect that on macOS, iOS, and Android, it's pretty clear.
Sadly, as @jfkthame pointer out, it's not that clear on macOS. However, having the browser block the optionally-downloaded macOS-bundled fonts is likely to be feasible in terms of the resulting user experience. That is, blocking the optional fonts of macOS is probably less likely to result in complaints from users than blocking the Windows 10 and Ubuntu fonts that aren't part of the base set but get installed as a side effect of certain languages.
browsers would have to maintain their own per distribution list, which isn't scalable.
It's not scalable, but it could work for most users to cover Fedora, Ubuntu, and potentially openSUSE (I haven't looked at the openSUSE font situation). Even though Debian is a major distro, the Debian approach of leaving so much of the configuration to the user makes it infeasible for the browser to try to normalize the configuration as it's visible to the Web.
AFAICT, the situation with Fedora is clearer than with Mac: There one pretty good set of fonts: enough to cover the stylistic needs of what the Web uses generically without offering too much to take too much disk space. Ubuntu has the same problem as Windows 10, though: The base set is stylistically a little bit too narrow for some major languages, and "Adding a language" installs fonts such that the set of added languages serves as a fingerprint.
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
Do any remove any fonts from the set that one would get on a Pixel or Android One phone?
What about - for the sake of privacy - getting vendors, aka Mozilla, Google, Apple, Microsoft, Opera, together and just ship a standard set of fonts where every vendor can 'donate' some fonts so they are available cross plattform as well. These fonts would come from a standard repository and be always the same, even on binary level.
Edit: License wise these fonts would go with the browser, not being installed into the OS. Each vendor 'donating' a font would be responsible for licensing to be compatible for this use case. Each vendor 'donating' a font would enable them to ship their corporate identity much easier say shipping Droid Font group, San Franciso Font group etc. So there'd be some benefits.
In addition to this users could opt-in in their control settings to allow add further locally installed fronts like suggested here.
What about - for the sake of privacy - getting vendors, aka Mozilla, Google, Apple, Microsoft, Opera, together and just ship a standard set of fonts where every vendor can 'donate' some fonts so they are available cross plattform as well.
The disk space footprint of such a set is relatively large: 550 MB unhinted and uncompressed. Unless you can convince Microsoft to adopt an Apple-like font-rendering aesthetic (which would be awesome achievement regardless of privacy), you need the fonts to be hinted in order for them not to look awful on Windows.
That kind of data size is problematic for browsers that aren't bundled with the OS. As for browsers that are bundled with the OS, it would be equivalent to getting the OS vendor to accept that kind of disk footprint for the default install, since the OS-bundled browser is part of the default install. If you could get Microsoft and Canonical to install a Mac/Fedora/Android/Chrome OS-like set by default, the font set wouldn't need to be for the Web but could be the OS default font set.
(There are so many ways to fingerprint the OS that trying to standardize the set across OSs isn't a particular privacy benefit. However, getting Microsoft and Canonical to install more fonts, even if mutually different, by default would be.)
The proposal would only affect the user-installed fonts
Aha! This makes more sense now. Sorry for misunderstanding.
What about - for the sake of privacy - getting vendors, aka Mozilla, Google, Apple, Microsoft, Opera, together and just ship a standard set of fonts
Putting aside licensing concerns, I wish we could do this, but alas, one of the goals Apple has is to minimize the size of the image that users have to download in order to upgrade their OS. Fonts have been a target for minimization of this image. Indeed, we avoid shipping some large fonts with the OS image to users which are unlikely to ever need those fonts. Realistically, we wouldn't increase the size of our OS image because some other browser, unrelated to us, wanted to include some font. Any such font would, by definition, be a font which we had previously judged as unnecessary for the OS, and which we had already made a decision to omit.
it's not that clear on macOS
Indeed; @frivoal is incorrect in his assumption that all users who buy a particular version of macOS get the same set of preinstalled fonts. As mentioned in the previous paragraph, we will customize the set of preinstalled fonts depending on a user's locale. However, the set of possible buckets a user could be in is quite small - way, way smaller than the amount of entropy that would be exposed to the web if we had not implemented Safari's behavior.
I wrote a "font taxonomy" in fonts level 4, which defined a user-installed font as:
installed by an explicit action by the user, such as clicking an "Install" button or copying a file into a particular directory on their device.
I believe this definition offers one unambiguous way to discern between user-installed fonts or not. (I'm not trying to say that this definition is the best possible definition to be used for the purpose of this GitHub issue; I'm just trying to make an existence proof that it is possible to come up with an unambiguous definition which could be used here.)
I should also make the point that, in order to implement Safari's behavior, Safari has to use non-public SPI to determine whether or not a font is user-installed or not. If other browsers are interested in using this mechanism, we can start the process of exposing this functionality publicly.
I wonder if this conversation (and the proposal) isn't letting the perfect be the enemy of the good. If the proposal was amended like the following, would that address some of the "there isn't such a clear line between default and system installed fonts" concerns?
- Build lists of default fonts shipping on windows, Mac and popular linux OSs.
- define OS-installed-fonts fonts as the intersection of the above set, and fonts on the user's machine
Indeed, this would be the most realistic way forward if for step 1 you take the intersection of sets that can be installed by default depending on the install-time language on macOS and on Windows 10 and Ubuntu you take the union of such sets. (On macOS, the intersection is already good but the user can install the rest potentially one-by-one, so the union would leave a lot of fingerprinting surface as long as the mechanism mentioned two comments up is private. On Windows 10, the intersection isn't good enough, but the fonts not in the intersection get installed in bundles, which still leaves a large number of combinations, but not as large as installing fonts one-by-one. On Ubuntu, the user could go install fonts that are in the union but not in the intersection one-by-one, but the intersection isn't good enough, so what can you do.)
To improve privacy compared to that on Windows 10 and Ubuntu would involve those systems making their intersection set more Mac/Fedora-like, which is not something that browsers can do for them, but would then allow switching to the intersection instead of the union.
Sorry, i phrased that poorly; By:
define OS-installed-fonts fonts as the intersection of the above set, and fonts on the user's machine
I meant the fonts from #1 ("the above set") ⋂ the fonts on the user's machine, but managed to write it in Polish-notation ¯\_(ツ)_/¯
. I think @hsivonen managed to (heroically) tease out what was intended, but wanted to restate to make clear :)
The CSS Working Group just discussed [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)
.
It was mentioned in the minutes above that some UAs (like print formatters) will likely want to continue to match all installed fonts. I expect non-browser applications built on things like Electron will want to be able to act like a native app and build a full font list as well.
Uniion of all fonts shipped by default by all OSs that an be resonably compliled.
I think that's not a reasonable fingerprinting protection. That way, you could fingerprint a Mac that has Microsoft apps that install fonts from the Windows set.
In my previous comment about intersections and unions, I meant that the Mac-specific allow-list would be the intersection of the macOS locale-specific configurations and the Windows 10-specific allow-list would the an union of the Windows 10 locale-specific configurations. (This assumes that you can fingerprint macOS vs. Windows 10 regardless of fonts anyway.)
I want to emphasize we need to address impact on minority language population and limiting to default fonts won't cut it. Need to not harm those communities. You can't use web fonts for things like this. Places with minority language are also where downloads are slower and more costly. need to make sure we address that head on
This indeed needs a solution. Sadly, logically you can't have both unconditional font fingerprinting protection and support for scripts whose fonts aren't covered by the OS bundled set (either not covered at all or not covered to the satisfaction of the users).
Is there data about what those scripts are these days?
South Indian it's common to install locally used fonts.
Is there up-to-date data about this? (I'm aware of pre-iOS/Android-era windows-1252 fonts with Tamil glyphs was common, but I have been unable to get even Twitter anecdata about whether that's still a relevant issue for sites browsed only from desktop of if the difficulty of installing fonts on phones has forced sites to adapt not to being able to expect users to install such fonts.)
I think that's not a reasonable fingerprinting protection. That way, you could fingerprint a Mac that has Microsoft apps that install fonts from the Windows set.
Sure, if the group is game to split these groups up by OS, that'd be even better. I made my suggestion because it'd be 1) a significant improvement over the status quo, even if far from ideal, and 2) it seemed the group was hesitant to break things up by OS. But I 100% agree, making these lists per-OS would be even better.
Is there data about what those scripts are these days?
Is there up-to-date data about this?
My understanding from the call was that the current idea was:
My understanding from the call was that the current idea was:
- Put the algo for deciding what fonts are often loaded in which locals into the spec
- Crawl or telemetry or similar measurements for which fonts the above algo gives
What would the crawl or telemetry measure specifically so that existing font fingerprinting scripts don't confuse the measurement?
The Windows 10 font bundles are documented at https://docs.microsoft.com/en-us/typography/fonts/windows_10_font_list . (Note that the "Pan-European Supplemental Fonts" bundle is not autoinstalled as a side effect of adding an applicable language to Windows. The rest of the bundles are autoinstalled when an applicable language is added to Windows.)
The fonts bundled with macOS Catalina are documented at https://support.apple.com/en-us/HT210192 . You want the first section and the parts of the last section that are in the hidden language support folder (practically the Noto fonts in the last section). (The last section also lists iWork fonts.)
You can find the default font list for a given Linux distro by running fc-list --verbose
after doing a clean install. Fedora 31 beta, Ubuntu 19.10 beta English, Ubuntu 19.10 English with all languages added after install.
The base set for Windows 10 is 343 MB and the full set appears to be "Size: 3.73 GB, Size on disk: 3.39 GB".
What would the crawl or telemetry measure specifically so that existing font fingerprinting scripts don't confuse the measurement?
It seems like we could distinguish "real font use" from fingerprinting, by either (easy mode) discarding from the crawl any site requesting a large number of fonts, or (slightly less easy) only looking for fonts that are applied to the document in a way that exceeds some threshold (e.g. X amount of text that persists for Y amount of time). Seems like a solve-able problem :)
Hi all, hope everyone is having a good new year. Was very happy and encouraged by the call we had last month. Wanted to get a sense of where things stand after that call, how i can help move things forward, and if there is another call for this month I could attend to continue progress on this.
@snyderp we have a face-to-face meeting next week Wed-Fri. Would you be available on any of those days to call in to a 10:00-19:00 Central European Time meeting?
@astearns sure, that would be no problem. I'm be in London time next week anyway, so availability is pretty flexible during the times you mentioned
If I understand things correctly this proposal (1) prevents finger printing for users that go with default browser settings which would only provide access to default system fonts and (2) provides a way for users to give access to additional locally installed fonts they might need for their use cases inside the browser. When going for (2), users consciously drop the safety provided by (1) and become exposed to fingerprinting.
Given the fact that most of the protection provided by the default browser settings are lost when users decide to give access to additional fonts, I was wondering if that couldn't be achieved through a mechanism that is less tedious for users than manually picking the fonts they might be needing in the browser. For example, what if local font access could be granted per application (domain) and applications could explicitly require that permission through a builtin browser dialog. The dialog would explain to the users the risk they are exposing to. IMHO, the fact that users grant access to local fonts only to the applications they trust, brings more safety than adding access to a subset of fonts which any application can access.
The reason I mentioned a mechanism through which users could grant access to all their local fonts to specific applications rather than manually selecting the fonts they want access to is because there are applications that might need this functionality. For example applications that provide advanced text styling, like word processors or design applications.
The CSS Working Group just discussed limit local fonts
.
Thank you for having me this morning and for making time on the agenda.
I want to make sure the other action item we discussed wasn't dropped. @tabatkins and others mentioned their teams are working on solutions. It would be very valuable to know more about those too
@tabatkins can probably provide better links/info, but I do see there are some considerations on restricting local font access here https://github.com/inexorabletash/font-table-access/
@astearns thank you for the link. PING is concerned about that proposal. Any information about how that proposal would address current fingerprint-ability (rather than maintain current fingerprint-ability, but try and restrict additional surface behind a permission) would also be useful
Jeffrey Yaskin and Brad Lassey are both on the PING, and are the people I was referring to when I was talking about people representing our privacy team.
@tabatkins I'm not sure I understand. Last time I asked them about font fingerprinting plans, you and they pointed me at the privacy budget document, which doesn't have any specifics in it and hasn't been updated since it was first published.
Are you saying thats the current latest information, or that I should talk to them about Chrome font plans instead of / in addition to Chrome reps on CSS Fonts?
Not arguing, just trying to figure out whats knowable and who to ask
You should talk to them for further details, yes. They'll either have appropriate information, or can directly refer you to other engineers who will. This is all still under active development, mind; we might not have further details beyond explainers of our newer experiments.
In reference to the meeting log: Clearly, a spec could at most describe qualitatively what kind of installation provenance a font should have to be visible to the Web and possibly provide lists for some well-known systems (but linking to Microsoft's and Apple's own docs seems easier). The allow-list necessarily needs to be a per-OS thing, and the W3C can't say that this is the closed list of operating systems that will ever exist. Also, this whole concept won't make sense for such Linux distros that don't have a broad installed-by-default font set.
@snyderp FYI: https://github.com/jyasskin/font-anti-fingerprinting
One of the things that the repo above made me think of is that we might be able to roll out an anti-fingerprinting response locale-by-locale.
In order to avoid breaking content, we could decide to limit local font access for particular locales where we have researched and vetted that this does not cause a content problem.
For locales where we are not yet sure whether particular local fonts are required to successfully view content, we could continue to allow local font access until sufficient research has been done. The research result should either allow us to limit local font access entirely or identify particular locally-installed fonts that need to be allowed.
I'm worried about the impact of this on minority language users, and also specialists such as egyptologists, and other script researchers. If users can opt to allow certain fonts which are never likely to appear in the browser defaults, it sounds like they expose themselves to fingerprinting, which doesn't make this a great solution for large numbers of people.
If i understand correctly, the problem arises because people serving web pages are able to inspect which fonts are available on a users system.
Could someone explain for me (in simple terms) why users and implementers need to jump through all the hoops described above rather than simply preventing the web browser from communicating back what fonts are available on the user's system?
@r12a I do not think it is practical to prevent this information leak, if the fonts can be used to lay out web content. As I understand it, the attack is to lay out some text, measure it, change the font, measure again. If the measurement changes then the font is available on the user's system. Repeat these steps 100-10000 times and you get some useful information about their installed font set. We would have to disallow measuring of laid-out content to prevent the leak, which would break a lot of the web.
One thing I have wondered is whether browsers could continue to allow locally-installed fonts to be used for font fallback purposes, even when they're not exposed as family names that font-family
can match.
This would mean that if the user has installed a local font to support a Unicode block that the default OS fonts don't cover, content using those Unicode characters would remain readable rather than being rendered as blank boxes or whatever.
A site wanting to fingerprint users would presumably be able to tell that the user has some font that supports the given Unicode block, by detecting a difference in metrics from what "tofu" rendering would give, but would not be able to directly test for specific font-family names.
ISTM this would increase the effort involved in font fingerprinting (it would now require researching the specific Unicode ranges that might be relevant, not just a list of thousands of potential fonts), while at the same time greatly reducing the amount of information that could be gleaned (only the presence of a font for an otherwise-unsupported Unicode range, not a long list of general-purpose font names), which makes the whole area a much less attractive target for would-be trackers.
@r12a wrote
If i understand correctly, the problem arises because people serving web pages are able to inspect which fonts are available on a users system.
Not directly, and not in so flagrant a way as was possible with Flash (which returned a complete list of all installed fonts, with a single function call). Instead there needs to be text (possibly hidden) styled with a specific font name, and that text is tested to see if the font loaded. In other words, each possible font is tested, one by one, and each test introduces some small delay to overall page rendering. So in practice, privacy testers such as the EFF one test a couple of hundred common fonts.
@r12a wrote:
I'm worried about the impact of this on minority language users, and also specialists such as egyptologists, and other script researchers.
It helps to look at the taxonomy of users suggested by @hsivonen; the egyptologists would fall into group 6
If users can opt to allow certain fonts which are never likely to appear in the browser defaults, it sounds like they expose themselves to fingerprinting, which doesn't make this a great solution for large numbers of people.
Only if some web page has
<p class="foo">𓆓𓂧𓆑𓆓𓂧𓀀𓈖𓏏𓈖𓏥𓂋𓍿𓀀</p>
.foo {font-family: Segoe UI Historic};
and then tests to see that Segoe UI Historic in fact loads. Any other font covering Egyptian would not be tested here.
For example, I ave several fonts which are very unusual and should make me uniquely identifiable, if a list of all installed fonts was available. But it isn't; an attack page would need to specifically test, by name, for oddities like:
Sure. I wasn't very specific about what i meant by 'this'. What i'm most concerned about is whether those users will be prevented from using the local fonts, like they are in Safari. Taking egyptologists as an example (of a specialist group), fonts like JSesh are widely used (by egyptologists), and new fonts are in development for support of the new Unicode characters that create quadrants. These fonts are relatively large, due to the nature of the script (so not great if you have to download several as webfonts to use on a single page), and i assume are unlikely to be added to any lists. I'm hoping that we find a solution that ensures that egyptologists can continue to use these fonts from their local system, and a solution that's not overly technical or complicated.
Similar concerns arise for users of 'minority' languages or scripts, especially if there's a backlog of existing content out there that relies on system-based fonts.
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 https://github.com/w3c/csswg-drafts/issues/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 https://github.com/w3c/csswg-drafts/issues/4055#issuecomment-536169515, 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 https://github.com/w3c/csswg-drafts/issues/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.