[css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome) #4497
Comments
|
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? |
r12a
added
the
i18n-tracker
|
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 #4497 (comment) that:
(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.) |
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 The full IRC log of that discussion<dael> Topic: [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)<dael> github: https://github.com//issues/4497 <dael> myles: I can't take this <dael> myles: Not sure I understand the proposal <dael> Rossen_: And Chris is not on. <dael> florian: I think TabAtkins will want to push back so we should wait for him <dael> TabAtkins: I am on now <dael> TabAtkins: For this topic, no comment right now. I didn't see it earlier. I'll talk to our security people and see what our opinion is. <dael> Rossen_: That's on Fonts? <dael> florian: The comment is consistent with Fonts |
|
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.
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.
I do not believe this is not the case for the above reason.
Sure, that'd be great. I'll email now. 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.
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" :) |
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. |
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). |
Yeah, having users choose a set of fonts makes no sense for the purpose of avoiding fingerprinting.
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.
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.
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. In addition to this users could opt-in in their control settings to allow add further locally installed fronts like suggested here. |
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.) |
Aha! This makes more sense now. Sorry for misunderstanding. |
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.
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:
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?
|
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:
I meant the fonts from #1 ("the above set") ⋂ the fonts on the user's machine, but managed to write it in Polish-notation |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)<dael> github: https://github.com//issues/4497 <pes> (howdy :) ) <dael> pes: Right now font fingerprinting by most measurements is highest entropy. Would like to address and solve <dael> pes: Needs standards level b/c will require some degree of PR or author notification or browser changes so everyone moves in tandem. <dael> pes: Couple proposals but in general need to limit types of fonts websites can tickle are those that are useful for users <dael> pes: Most recent prop is let's figure out default font OSs, union those, websites can access those. If users want to opt in other fonts you should be able to do those with a prompt from the browser <dael> astearns: One things about privacy discussions and opting in to exposing information is the concern about messaging to the user what they are doing. Is there possible a way to opt in to that giving a good story to the user what they're doing? <myles> q+ <dael> pes: Two thoughts; if users are doing this they already know somewhat what they want. Convaying some of the functionality without the meaning is easy. If there's the desire to convey why I think that's easy to describe. I could put up text. People usually follow defaults. From examples in GH is moderatly expert users and that's something two steps out of the mean <dael> pes: I think it falls nicely where browsers are doing things users don't expect and taking it from default path is a win and allowing users intentionally installing fonts is doable <astearns> ack myles <dael> myles: A couple points. 1) Fingerprinting based on set of available fonts is real bad and we philosophically should try to solve. <jensimmons> q+ <dael> myles: 2) there's a problem here issue is trying to address which isn't stated yet. Safari already disallows user installed fonts so we're similar to prop but don't ask user to allow. There's a problem with that where for some lesser used scripts there may be no system font that can support so can have unreadable pages <pes> q+ <dael> myles: This proposal has affordances to solve that where for those scripts users can opt in. That's good. But there's a cost which is throwing additional prompts to user they may not understand and adding friction at OS install time is something the entire company tries to minimize <dael> myles: Realistically us adding a screen at OS install time is difficult to do and generally not something we're comportable with <dael> astearns: Clearification on scripts not supported- is Safari not rendering some web pages it might otherwise be able to with the script? <dael> myles: Yes. Logic is it's a better situration for them to have to use web fonts b/c it's better to require that then for every user to install a font with a name b/c less websites then web users <chris> q? <astearns> ack jensimmons <dael> jensimmons: I was never aware Safari doesn't allow user installed fonts. And I've never heard a web diesgner talk about that. I agree it's complicated for users to understand a browser setting. That's the kind of thing webdev can't count on. It may be something to think about but doesn't seem core to solving <chris> q+ to say have seen exactly those notices on web pages <myles> q+ to ask browser developers on macOS if they want OS-level support to allow for the behavior that Safari has about user-installed fonts <florian> q+ <dael> jensimmons: Looking at last part of GH issues I see intersection of fonts vs union. Union is when you have all the fonts on both even if they're only on some OS. Some people are saying to do intersection where Arial is on so it's allowed but Aveneer is only on MAc so no allowed. Intersection would be a massive problem. I don't think it's a problem to limit to what's shipped in OSs <florian> q- <florian> q+ <astearns> ack pes <dael> jensimmons: If we try to limit to intersection it will break millions of websites. I don't think people are counting on some people might have fancypants font. But they are counting on some people have Aventeer but others Roboto <dael> pes: Clarifying the proposal: Uniion of all fonts shipped by default by all OSs that an be resonably compliled. And the ones fed to the website are intersection of installed and system fonts. That is one option on Android, another on OSX, etc. <dael> pes: Proposal isn't to say at install time let these fonts be accessed. Proposal is for small set of users who expect these fonts to be available b/c region of website allow user to go into advanced and have a drop down of additional fonts. Expectation is relatively few people do this, but communities that needs this alreayd install extra font so this additional step isn't infeasible <astearns> ack chris <Zakim> chris, you wanted to say have seen exactly those notices on web pages <dael> chris: I wanted to say contrary to jensimmons not seeing it done, I have seen this on some sites, particuarly when Indian was worse. South Indian it's common to install locally used fonts. It could be there's a pack that installs a bunch of fonts. I don't want to break web experience for those that have been using it successfully <jensimmons> +1 <dael> astearns: Is there a way to survey scripts and say these aren't by default but everybody in that region installs these fonts <dael> chris: It would be a valuable addition <astearns> ack myles <Zakim> myles, you wanted to ask browser developers on macOS if they want OS-level support to allow for the behavior that Safari has about user-installed fonts <dael> myles: one other small things. Mechanically ability to discern between fonts is not a public API on OS. I would love it if a browser programmer wanted this exposed; I'd love to know that <astearns> ack florian <myles> s/I would love it if a browser programmer wanted this exposed/I would love to hear if any browser programmers wanted this exposed/ <pes> https://github.com/Valve/fingerprintjs2/blob/master/fingerprint2.js#L557 <— example of fingerprinting via fonts <dael> florian: I don't see TabAtkins on and I'd like to bring up a point from him. this seems less drastic then others discussed so down side not that bad. If we do the intersection of what's installed it has a fair bit of variability. Besides font fingerprint there are other means. The question to ask is does it actually help. If we don't reduce it enough then we haven't achieved anything even though we decreased it <dael> florian: Downside isn't that bad if we include the language specific common fonts, but there still is some cost. Are we paying it for something or do we not reduce your uniqueness enough <jensimmons> There are many other ways of fingerprinting, but many of us out here are knocking them out one by one. I believe we should also do our best to close such security flaws. (in response to florian's comment) <pes> +1000 for what is being said right now. <jensimmons> +1 from me as well <dael> plinss: Let's not let hte perfect be the enemy of the good. There's a lot of fingerprinting surface and we need to make small steps in every regard. We have to take small steps where we can and get a cumulative effect where we can <dael> florian: TabAtkins point is he doesn't think we can ever get there <astearns> yep, if it makes fingerprinting at all harder, it's progress <dael> plinss: If we never try we won't get there <astearns> ack fantasai <Zakim> fantasai, you wanted to ask about impact on linguistic minority populations <dael> myles: I don't doubt we can get there so we have one vote on either side so worth discussing <astearns> ack dbaron <Zakim> dbaron, you wanted to talk about both exposing Mac OS API and about being willing to expose OS differences rather than intersection or union <astearns> q+ fantasai <dael> dbaron: Two comments. myles asked about the API on Mac. it's not something we planned to work on but if we do get to work on this it would be useful. Lack might cause us to have to do a work around. If it's exposed it would make this sort of thing more practical. But we don't have a concrete plan to use it <pes> +q <dael> dbaron: Other thing is that there's been a bunch of discussion about intersection and union of fonts across OSs. I'm not convinced we want either. There's an argument that we want to allow vary between OSs. There's a set of fingerpritnable information we can hope to obscure but there's bits of entropy we can be okay giving up on and one of those is if a user is on windows or mac. <myles> dbaron++ <dael> dbaron: Either way of addressing it makes the solution worse. Intersection limits designers, Union is a bunch of fingerprinting exposed if users install fonts that are default on a different OS. <astearns> ack pes <dael> pes: Point about fingerprinting nihilism. Ping and those in privacy community are trying to address it in many ways. You chip away as you can. Nature of problem means different wins benefit different people are different times. <myles> pes++ <dael> pes: Chpping off entropy bits is valuable. Different fingerprint endpoints yeild differently as well. So adding noise is an option in some places, but fonts is not one of those places. Figuring out how to reduce problem to a subset seems valuable here. I think every time we take a slice of the problem we're benefiting some people. We're not throwing coins in a well <astearns> ack fantasai <plinss> +1 to pes <dael> fantasai: Two points. 1) If we're going to do this we should document which fonts re allowed on which OSs so all browsers can align with interop. If we're going to do this we should start a registry of allowed fonts so authors and browser vendors can figure it out <dael> astearns: To that I think yes and no. There should be a rule for what's in and maintian it, but have the list generated from rules. If we do a union the set will only ever grow <dael> fantasai: Rule in fonts spec, document of fonts that conform to the rule. In an OS API is nice, but and author won't find it easily <dael> astearns: We aren't saying browsers restricted to this for all time, we're saying here's the set we're aware of and here's the rule to add a new font <dael> myles: There's a bunch of websites that list the fonts. Do we need to maintain if it's out there? <dael> AmeliaBR: Not in reliable up to date fashion <dael> myles: Will ours be? <dael> dbaron: Need something that reflects worldwide usage. Some of that will need to be us. <dael> fantasai: I don't want it in fonts spec. A note or a W3C regitry that's easily maintained and doesn't need our intervention. <dael> fantasai: 2) 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 <pes> +q <dael> astearns: Other points on this topic? <astearns> ack pes <jensimmons> +1 to everything fantasai just said. It would be incredibly helpful to Authors to have such a list. <dael> pes: I'd like to know how Ping or I personally can be most useful to make sure a solution gets into the next part of the spec and get this solved <pes> i can promise to do that :) <dael> astearns: I think being active on GH issues that are open and reviewing spec text is most helpful. Anyone else can chime in? <dael> fantasai: Are we resolving to do this and if yes exactly what. If not, when do we follow up? <dbaron> I think we're a decent distance away from converging on a particular thing to add to the spec. <dael> astearns: I was thinking to draft a solution based on GH thread. I'm not hearing objections to trying to solve this. Coming up with something to put into Fonts spec to limit fonts available to web pages <pes> +q <dael> AmeliaBR: Have text saying browsers may limit what fonts are exposed. Is the agreement at this point to increase the normative standard of that or be more specific abou which you might want to limit or be specific about which fonts are safe? <dael> AmeliaBR: Have it defined tht if a font meets these criterias the browser should make it available and may block access to all others <pes> -q <dael> astearns: It would be yes on your first two. Increase to a must requirements and more concretely define the restriction. But we're not trying to come up with list of web safe fonts, we're defining what browser should make available in terms of locally installed fonts. <dael> astearns: Registry we have won't have all safe, but might be available <dael> AmeliaBR: Using safe from privacy PoV not author guarantee <dael> astearns: Yeah. Like dbaron said in IRC we don't have a thing for the spec yet. Just an intent to solve the problem <dael> myles: One point, I don't think can make a must b/c involves non-CSS pieces of browser. <fantasai> +1 to myles, this would have to be a SHOULD <pes> +q <dael> astearns: Must would be font matching algo. Not about browser that might make it less restricitve <gsnedders> do some OSes still conditionally install fonts based on locale? what should the behaviour be then? <dael> fantasai: Should still be a should. There's CSS UAs that don't want to limited in this way. Like a PDF renderer which is trying to print local documents. This will have to be a should. <dael> fantasai: Browsers will probably follow b/c it makes sense to them <astearns> ack pes <dael> chris: Agree it should be a should for that reason. They might have to opt in but we shouldn't block it. <dael> pes: In general a should doesn't mean too much when doing privacy review. We're looking to see if a browser properly implements will they be protected. Point taken where there are places where privacy doesn't apply and those should be carefully detailed out. <dael> pes: The case discussed where needs to be a way to opt in is handled in GH issue <fantasai> RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there <fantasai> may exist valid reasons in particular circumstances to ignore a <fantasai> particular item, but the full implications must be understood and <fantasai> carefully weighed before choosing a different course. <dael> pes: I've not written specs but I know in many places functionality is described that hooks into browser chrome so might consider examples like that <dael> fantasai: I want to point out a couple things. One is we as a WG don't know all UAs that exist or will exist and we shouldn't make a UA non-conformant just b/c satisifes a non-browser use case. <dael> fantasai: Technical definition of should is [reads] <dael> fantasai: I think that's appropriate in this case <chris> +1 to the RFC2119 definition <dael> astearns: I think we should go back to GH and hammer out exact proposal and level of requirements. I think there's quite a bit of work before there's something to put in spec, but we should get to that. Maybe checkpoint in a month <dbaron> "a month" is the face-to-face, btw <dael> AmeliaBR: Sample spec text drafts would be helpful so we can start comparing <dael> astearns: dbaron reminds me we have the F2F to hammer out the last details and get it into spec <dael> chris: Sounds good way forward. <pes> (terrific :) ) <dael> chris: pes you should keep watching issue and we update EDs daily so you can see evolution of text <dael> astearns: Anything else on this? <dael> astearns: Thanks everyone |
|
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. |
|
See also: #5421 (which directly contradicts the OP of this thread). |
|
The current proposals start by defining (through various methods) sets of "safe" fonts that don't leak additional information beyond what can be already found out through other means (OS, language, etc.). For fonts that are installed but outside of the user's "safe" set, I think that @r12a's idea (mentioned in #5421) might be on the right track: the browser could prompt the user to enable those local fonts (for the current domain or for all pages) at the point where they are requested. This UI flow could be similar to the ones already used when a page requests additional permissions, and would include a preview of the requested font. This would provide the user with the necessary context to evaluate whether the request is reasonable. From the point of view of the Web developer, the initial effect would be as if the font is unavailable. The font might become available at some indeterminate point in the future, triggering a style and layout update, but until that happens there would be no way of knowing whether it is not installed or its use has been declined by the user. Font fingerprinting scripts typically create a bunch of nodes with different Of course, newer fingerprinting scripts could wait for a while before testing the presence of a font. However, the UI would still reflect that this fingerprinting effort is taking place. Whereas benevolent pages would trigger a message of "this page wants to use fonts ABC and XYZ", for a malevolent one the message would become a more alarming "this page wants to use 51 fonts". The UI may even change when a page requests an unreasonable number of fonts, nudging the user towards declining the request. As is the case with other permissions, there would be a section in the Preferences where the user could review and revoke the fonts that had been made available to particular domains or to all of them. What do you think about this approach? |
|
Related issue in Timed Text w3c/ttml2#1202 |
pes10k
added
the
privacy-needs-resolution
Fwiw, this is indeed what i was thinking would provide a good solution, for all the reasons that @felipeerias mentions. |
w3cbot
removed
the
privacy-tracker
|
@litherum do you have an opinion on @felipeerias suggestions? |
|
The CSS Working Group just discussed The full IRC log of that discussion<fantasai> Topic: Local Font Access Limitations<fantasai> github: https://github.com//issues/4497 <fantasai> astearns: Topic is about local fonts needed for i18n particularly <fantasai> [side discussion about positioning of Agenda Item 9] <fantasai> smfr: Myles isn't here <fantasai> s/here/here, probably should be here/ <fantasai> astearns: Other browsers than Safari probably need to sign on for whatever local font access we decide on here <fantasai> s/here/here also/ <fantasai> chris: It would be good to get some movement on this. <fantasai> chris: Felipe made a good suggestion, and thumbs up in thread <fantasai> chris: Richard confirmed he liked the suggestion <fantasai> chris: Maybe we can resolve to accept the suggestion, and then work out the details in the spec <fantasai> chris: The general principle seems sound <fantasai> Felipe's suggestion at https://github.com//issues/4497#issuecomment-763459971 <fantasai> astearns: Summary is having some sort of permission interface, where if a web page tries to use a local font and browser notices local font is in system, UI would come up <fantasai> astearns: timed to make fingerprinting more difficult <jfkthame> q+ <fantasai> astearns: allows user to enable font access <smfr> q+ <fantasai> r12a: Then can have a checkbox for "don't ask me about this font again" <chris> q+ <fantasai> jfkthame: Interested in Gecko <astearns> ack jfkthame <fantasai> jfkthame: Doing some foundational work towards potentially restricting font access <fantasai> jfkthame: One aspect not directly talked about, seems there are several senses in which a website could want to use a locally-installed font <fantasai> jfkthame: worth highlighting the distinction <fantasai> jfkthame: might be font name is given in font-family property <fantasai> jfkthame: so that specific font family is specifically requested, and page would like to use, and might or might not be allowed <fantasai> jfkthame: But what about font fallback? Character that is not in other fonts <fantasai> jfkthame: Would that trigger requests like this? <fantasai> jfkthame: Should there be a user request for fallback, when the character is not available in other fonts? <chris> qq+ to answer <fantasai> jfkthame: I think the fingerprinting implications are different <fantasai> jfkthame: I think for fallback, I think it's particularly concerning for minority languages <astearns> ack chris <Zakim> chris, you wanted to react to jfkthame to answer <fantasai> jfkthame: For such users, any font that supports the language would be helpful <fantasai> chris: For fallback case, script can know that fallback was used, but doesn't know which one <fantasai> chris: so imo shouldn't require a user permissions font <astearns> ack smfr <fantasai> jfkthame: well, you are exposing the fact that the user has *a* font that supports these characters <fantasai> smfr: In general, we don't believe permission prompts are useful solution to this kind of problem <fantasai> smfr: one reason is user fatigue; users don't read the dialog, just want it out of the way <fantasai> smfr: Then it's really impossible to explain to users what fingerprinting means and implications <r12a> q+ <fantasai> smfr: .... <fantasai> smfr: Then users don't understand whether web page or browseris showing the dialog <fantasai> smfr: long-term approach should be that system fonts have support for these minority languages <fantasai> smfr: so that we don't need to run into this problem in the first place <astearns> ack chris <tantek> +1 smfr, permission prompts are not a reasonable answer to this (users can't be expected to make informed consent) <fantasai> chris: the page gets laid out without the font, the dialog box pops up asking permission to allow this, so that next time come to that site (per origin) not bothered by it <fantasai> chris: so rapidly not going to run into this problem <astearns> ack chris <fantasai> chris: a font on system that covers the charset vs specific font that gives the right design is different <fantasai> chris: .... <fantasai> r12a: There is somewhere a long post on one of these issues where I addressed the question of system fonts being able to display the text <fantasai> r12a: there are certain scripts and orthographies where not only does it not look good, but it actually causes problems in representing semantics <fantasai> r12a: Might end up with wrong kind of glyphs, doesn't look the way you expect as a user of tye script <fantasai> r12a: Don't see any way to rely on system fonts here <chris> suspect r12a is referring to this: https://github.com//issues/4497#issuecomment-594521142 <fantasai> r12a: Also people like font designers have a problem, they can't check their fonts if they can't see them <chris> with Western Syriac example <fantasai> r12a: Noto fonts are not a panacea <fantasai> r12a: They are often in need of significant repair to do the job <fantasai> r12a: Sometimes missing for certain minority scripts <fantasai> r12a: Not coverage of characters, sometimes not the right glyph shapes <fantasai> r12a: A dialog box in front of the user is not great <fantasai> r12a: But it's better than not being able to get the font that you want <fantasai> r12a: I couldn't think of any better solution to it <fantasai> r12a: It will probably help if we have the ability to say "don't remind me, about this particular font" <fantasai> r12a: I don't think there's a good solution here <fantasai> r12a: If you're creating web pages, you are checking your page using localhost <fantasai> r12a: and in that situation, there's not going to be any phishing <fantasai> r12a: major pain in the butt if you can't spin up the page with the font you'd like to see <chris> localhost is just one example of an origin <fantasai> r12a: So I'd like to argue that if you're working on localhost, then that should not prevent you from seeing fonts <fantasai> astearns: My current take is that we're not ready to resolve on anything <fantasai> astearns: but encouraged by the fact that Gecko is interested in figuring out <fantasai> astearns: Sounds to me that there are some valid concerns about permission interfaces <fantasai> astearns: but also valid concerns about not doing anything and just relying on system fonts <fantasai> astearns: so I hope that people engage on the issue, because this is something that we need to solive <fantasai> astearns: Thanks, r12a, for joining us |
|
I added the suggestion from @felipeerias , which @r12a also liked, to the spec. |
|
The i18n WG considers this to be a duplicate/precursor to #5421 and that we should continue the discussion there and close this issue. Would that be acceptable? |
|
I’m not sure I follow, that issue is suggesting something incompatible (and opposite) from this issue |
|
I don't see incompatible solutions being proposed but I do see that:
I'm fine to leave both issues open until we have consensus wording that satisfies all interested parties. |
|
I think I18N's concern is that these appear to be tracking the same thing (if starting from opposite positions). All we're suggesting is that having a single thread to follow discussion might be simpler than two threads to track? |
|
OK but in that case I think an edit of the remaining issue title is justified, if one issue is closed. |
|
okie, im fine merging the issues if the WG prefers, though PING side we'll keep our tracking issue open to keep track of the concern. Like @svgeesus suggested though, i think it'd be important to edit the title of whichever issue ends up being the remaining issue |
|
Closed, further discussion should be here: |
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 #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 #4055 (comment), this would dramatically improve privacy for users in groups
1, 2, 32 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 #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.
The text was updated successfully, but these errors were encountered: