- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Dec 2019 17:49:02 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-fonts] limit local fonts to those selected by users in browser settings (or other browser chrome)<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/4497<br> <pes> (howdy :) )<br> <dael> pes: Right now font fingerprinting by most measurements is highest entropy. Would like to address and solve<br> <dael> pes: Needs standards level b/c will require some degree of PR or author notification or browser changes so everyone moves in tandem.<br> <dael> pes: Couple proposals but in general need to limit types of fonts websites can tickle are those that are useful for users<br> <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<br> <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?<br> <myles> q+<br> <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<br> <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<br> <astearns> ack myles<br> <dael> myles: A couple points. 1) Fingerprinting based on set of available fonts is real bad and we philosophically should try to solve.<br> <jensimmons> q+<br> <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<br> <pes> q+<br> <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<br> <dael> myles: Realistically us adding a screen at OS install time is difficult to do and generally not something we're comportable with<br> <dael> astearns: Clearification on scripts not supported- is Safari not rendering some web pages it might otherwise be able to with the script?<br> <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<br> <chris> q?<br> <astearns> ack jensimmons<br> <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<br> <chris> q+ to say have seen exactly those notices on web pages<br> <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<br> <florian> q+<br> <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<br> <florian> q-<br> <florian> q+<br> <astearns> ack pes<br> <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<br> <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.<br> <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<br> <astearns> ack chris<br> <Zakim> chris, you wanted to say have seen exactly those notices on web pages<br> <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<br> <jensimmons> +1<br> <dael> astearns: Is there a way to survey scripts and say these aren't by default but everybody in that region installs these fonts<br> <dael> chris: It would be a valuable addition<br> <astearns> ack myles<br> <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<br> <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<br> <astearns> ack florian<br> <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/<br> <pes> https://github.com/Valve/fingerprintjs2/blob/master/fingerprint2.js#L557 <— example of fingerprinting via fonts<br> <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<br> <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<br> <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)<br> <pes> +1000 for what is being said right now.<br> <jensimmons> +1 from me as well<br> <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<br> <dael> florian: TabAtkins point is he doesn't think we can ever get there<br> <astearns> yep, if it makes fingerprinting at all harder, it's progress<br> <dael> plinss: If we never try we won't get there<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about impact on linguistic minority populations<br> <dael> myles: I don't doubt we can get there so we have one vote on either side so worth discussing<br> <astearns> ack dbaron<br> <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<br> <astearns> q+ fantasai<br> <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<br> <pes> +q<br> <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.<br> <myles> dbaron++<br> <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.<br> <astearns> ack pes<br> <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.<br> <myles> pes++<br> <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<br> <astearns> ack fantasai<br> <plinss> +1 to pes<br> <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<br> <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<br> <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<br> <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<br> <dael> myles: There's a bunch of websites that list the fonts. Do we need to maintain if it's out there?<br> <dael> AmeliaBR: Not in reliable up to date fashion<br> <dael> myles: Will ours be?<br> <dael> dbaron: Need something that reflects worldwide usage. Some of that will need to be us.<br> <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.<br> <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<br> <pes> +q<br> <dael> astearns: Other points on this topic?<br> <astearns> ack pes<br> <jensimmons> +1 to everything fantasai just said. It would be incredibly helpful to Authors to have such a list.<br> <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<br> <pes> i can promise to do that :)<br> <dael> astearns: I think being active on GH issues that are open and reviewing spec text is most helpful. Anyone else can chime in?<br> <dael> fantasai: Are we resolving to do this and if yes exactly what. If not, when do we follow up?<br> <dbaron> I think we're a decent distance away from converging on a particular thing to add to the spec.<br> <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<br> <pes> +q<br> <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?<br> <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<br> <pes> -q<br> <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.<br> <dael> astearns: Registry we have won't have all safe, but might be available<br> <dael> AmeliaBR: Using safe from privacy PoV not author guarantee<br> <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<br> <dael> myles: One point, I don't think can make a must b/c involves non-CSS pieces of browser.<br> <fantasai> +1 to myles, this would have to be a SHOULD<br> <pes> +q<br> <dael> astearns: Must would be font matching algo. Not about browser that might make it less restricitve<br> <gsnedders> do some OSes still conditionally install fonts based on locale? what should the behaviour be then?<br> <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.<br> <dael> fantasai: Browsers will probably follow b/c it makes sense to them<br> <astearns> ack pes<br> <dael> chris: Agree it should be a should for that reason. They might have to opt in but we shouldn't block it.<br> <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.<br> <dael> pes: The case discussed where needs to be a way to opt in is handled in GH issue<br> <fantasai> RFC2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there<br> <fantasai> may exist valid reasons in particular circumstances to ignore a<br> <fantasai> particular item, but the full implications must be understood and<br> <fantasai> carefully weighed before choosing a different course.<br> <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<br> <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.<br> <dael> fantasai: Technical definition of should is [reads]<br> <dael> fantasai: I think that's appropriate in this case<br> <chris> +1 to the RFC2119 definition<br> <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<br> <dbaron> "a month" is the face-to-face, btw<br> <dael> AmeliaBR: Sample spec text drafts would be helpful so we can start comparing<br> <dael> astearns: dbaron reminds me we have the F2F to hammer out the last details and get it into spec<br> <dael> chris: Sounds good way forward.<br> <pes> (terrific :) )<br> <dael> chris: pes you should keep watching issue and we update EDs daily so you can see evolution of text<br> <dael> astearns: Anything else on this?<br> <dael> astearns: Thanks everyone<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-567139357 using your GitHub account
Received on Wednesday, 18 December 2019 17:49:04 UTC