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