- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Jan 2020 10:01:06 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `limit local fonts`. <details><summary>The full IRC log of that discussion</summary> <astearns> topic: limit local fonts<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4497<br> <faceless> pete: is taling about font fingerprinting by identifying the computer based on which fonts are installed on the computer<br> <faceless> pete on suggestion is to list a document which describes a list of specific onts<br> <faceless> s/onts/fonts<br> <faceless> myles asked about what pete wanted to discuss that wsn't on a previous call<br> <astearns> (from the last discussion: 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> <faceless> dbaron one of the questions was to what extent this would be allowed vs recommended vs mandatory. is comfortable with recommended not sure about mandatory partly because we don't know exactly what we're trying to do. open questions.<br> <faceless> dbaron thinks we should allow this<br> <faceless> myles at already does<br> <faceless> dbaron ... to recommednd this, and work on addding detail to the recommendation. when we're comfortable with the level of detail there, we can mandate this, but there are lots of open questions<br> <faceless> dbaron eg. effects on minorities etc.<br> <fantasai> s/minorities/linguistic minorities, across OSes,/<br> <faceless> myles if we don't make mandatory but do make recommended, would be good to hear from all present if we should change behaviour<br> <faceless> pete webkit is even safer than this, webkit won't load some fonts off disk<br> <Rossen__> q?<br> <chris> q?<br> <faceless> dbaron maybe jonathon can speak more authoritively on this but thinks maybe this might be more difficult to do on some platforms than others<br> <Rossen__> ack faceless<br> <Rossen__> ack fantasai<br> <Zakim> fantasai, you wanted to mention CSS2PDF renderers<br> <faceless> fantasai wanted to say there are classes of user agents where this makes no sense. eg css-pdf renderers, which need to access all fonts on the system<br> <fantasai> chrisL: localhost could have access to all of thm<br> <faceless> svgeesus css to pdf renderers have the ability to opt in to lists of fonts per site, which makes it more possible to opt out<br> <faceless> (as in opt out of fonts per domain)<br> <Rossen__> s/dbaron maybe/dbaron: maybe/<br> <pes> +q<br> <chris> although I wasn't just speaking of css to pdf renderers<br> <faceless> myles: as an engineer I am always thinking about how we can test this, but if there's going to be no changes to the file system this will be untestable<br> <dbaron> s/thinks maybe this might/we support a larger number of platforms and on some of those this might/<br> <Rossen__> ack pes<br> <faceless> pete: initial proposal was all this should be dealt with by the browser opting in<br> <faceless> pete: if the takeway is that the idea is useful but nothing is required at this point, I don't think that's any change from the status quo<br> <faceless> fantasai: a should requirement is not a no-op<br> <faceless> fantasi: it recommends action and it may be appropriate in this case.<br> <faceless> myles: but if no-one acts on that recommendation what's the point of it?<br> <faceless> fantasai: users agents don't always act on hard recommendations either.<br> <Rossen__> q?<br> <TabAtkins> If necessary I can state this at some point, but I believe Chrome's position is that we extremely want to stop fingerprinting as an identification vector, but I don't think that designing a solution in a committee with this skill set is appropriate. (There are groups in W3C (or elsewhere?) that are more appropriate and contain people with the right set of skills.)<br> <chris> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.<br> <fantasai> https://tools.ietf.org/html/rfc2119<br> <faceless> fantasai: should means if you have a good reason not to do it, you don't have to do it. But you need a good reason<br> <chris> https://tools.ietf.org/html/rfc2119<br> <faceless> myles: to paraphrase fantasai : we can put a should and say all browsers should do this, or we can make a partition and say some browsers should, some shouldn't<br> <faceless> myeles: pete said first option was a thumbs down<br> <faceless> pete: if there's an option that is available to the user-agent to do this that's ok<br> <faceless> fantasai: I would imagine you would object to this being turned on by default. but cs-spdf renderers would have to turn this on by default<br> <faceless> pete: doesn't have to be that way. if you're sefving documents off disk, for example, it could be off<br> <faceless> svgeesus: could you explain the harm of the status quo where someone on their own disk converts a file locally<br> <faceless> pete: that's not what I mean<br> <Rossen__> q?<br> <faceless> floriank: so if we don't mean everyone has to do this, then lets not say everyone<br> <pes> +q<br> <Rossen__> ack pes<br> <Rossen__> s/say some browsers should, some shouldn't/say some browsers must, some must not/<br> <faceless> pete: its seems like this must not be a new idea - there are cases where apps using hTML renderers have one set of rules, browsers have others<br> <faceless> heycam: we do<br> <heycam> different conformance classes for selectors (fast profile)<br> <faceless> florian: should means you have to do it unless there is a good reason, but good reasons do exist and if you have them you won't be arrested for not doing it<br> <pes> (Im very sorry to be tedious, but could people identify themselves when speaking for a bit?)<br> <pes> +q<br> <florian> s/for not doing it/for not doing it, but neither would you if we wrote must/<br> <fantasai> s/if you have them you won't be/if you have them you won't be non-conformant. You won't be/<br> <faceless> pete: who's planning on doing what?<br> <fantasai> s/for not doing it/for not doing it under SHOULD, but neither would you be under MUST/<br> <florian> q+<br> <faceless> pete: it's pretty important we get this sorted out so we can get the cross-browser expectations to users<br> <pes> -q<br> <pes> q+<br> <faceless> tab: especially gven recent info. fingerprinting in side channels is a very tricky thing to do and we don't have the expertises in this committee so i'd object to putting a "must" on this as i don't think we have the ability to do it ourselves<br> <faceless> tab: while it's very important and needs doing, I don't want to put anything binding on this committee<br> <Rossen__> ack florian<br> <hober> q+<br> <astearns> and a 'should' allows all non-Chrome browsers to do the thing and eventually make it more likely for them to bend<br> <tantek> note that "print formatters" are also "normal browsers" in Print Preview mode<br> <Rossen__> ack pes<br> <faceless> florian: we could put a note on this clarifying the intent to explain why a should recommendation is there and who shuodl follwo it<br> <florian> +1 to tantek<br> <faceless> pete: surely we do have the expertises<br> <faceless> tab: lI'm talking specifically about the CSSWG - the goal of reducing fingerprinting is 100% our goal, but Chrome doesn't want to bind themselves to a MUST resolution<br> <faceless> tpete: if you aren't hte people to ask, who is?<br> <faceless> s/tpete/pete/<br> <tantek> we really need to capture as much as we can in the issue, and then reach out more broadly than the WG<br> <faceless> tab: we have engineers who are working on this and hav ethe expertise on this, but none of this in this group have the expertise<br> <Rossen__> ack hober<br> <tantek> sounds like this discussion is going in circles<br> <dbaron> q+<br> <faceless> hober: you have co-chairs of ping and the privacy cg in this room, and pete is not coming to us as an individual - this is a concern from a number of people in this area. as a member consortium it's the responsibilty of this group that we have people who can speak on these issues. so it's disheartening to hear you don't want to consider this because we don't have the expertise. that's our role<br> <faceless> tab: yes I understand but this is the only privacy issues on this point, it's not approriate to invite the security team to be here<br> <pes> q+<br> <faceless> tab: i'm on the write person, none of here are.<br> <TabAtkins> s/on the write/not the right/<br> <faceless> rossen: calls order<br> <Rossen__> ack dbaron<br> <tantek> LOL: one-line S&P section in css-fonts 4: "The system-ui keyword exposes the operating system’s default system UI font to fingerprinting mechanisms."<br> <TabAtkins> I think the PING/etc are the right venues for this discussion, not the CSSWG.<br> <myles> did I write that?<br> <hober> TabAtkins: PING came to us with this!<br> <myles> s/did I write that?//<br> <tantek> presumably we are talking about more than just system fonts<br> <faceless> dbaron: pete asked who are the right people. i think sort of a weird question, given the response we're trying for. I think we are the right people, but the misunderstanding that leads pete to ask this question is that it's not a short process<br> <TabAtkins> This needs to be "privacy teams, with a font-related engineer on call", not "a bunch of layout/etc engineers, with a privacy engineer on call"<br> <pes> (i cannot hear anyone speaking…)<br> <faceless> dbaron: we're trying to make a substantial change to the way this works on the web platform. It's a process that requires proposal, iteration, requirements<br> <faceless> dbaron: (is more emphatic)<br> <faceless> dbaron: we're trying to do this thing that requires iteration and refinement of a proposal, and what we're saying is "yes, we're accepting that this is the next stage of the process and it's woth pursuing"<br> <TabAtkins> hober, Sure, and I'm saying that looking to this group for binding resolutions on this topic isn't appropriate. We own a spec with a feature that will be impacted; that doesn't mean we should be designing the change, just ensuring that it's integrated and well-explained when it's finished.<br> <faceless> dbaron: but pete is saying that's not the right thing - we need to have a solution now. But we haven't had the conversation that we need to have first. So we're basically saying yes to it, but we have to begin the process<br> <faceless> dbaron: I think that disconnect is why we're stuck<br> <dbaron> q+<br> <faceless> pete: with respect this was filed in june. there's been on counter-proposal since then<br> <faceless> pete: this is the #1 privacy issues on the web<br> <faceless> rossen: we understand and we recognise the urgency but the reality is there is a backlog<br> <Rossen__> q?<br> <faceless> rossen: the fact it was filed a while back does't mean it's not important to us<br> <pes> s/there's been on counter-proposal/has not been a counter-proposal/g<br> <TabAtkins> See, for example, how we were just spitballing about how to design a font list and how to segregate it. We don't have the expertise to do that; we can't get "close enough". It has to be done *right*, and we're not the group to do that.<br> <faceless> s/pete/pes<br> <Rossen__> ack pes<br> <faceless> pes: i want to know what the next steps are. If there's a process, what is it, what is the timeline?<br> <faceless> rossen: one of the proposals is to resolve with accepting this as a SHOULD statement.<br> <faceless> alan: the spec has this currently as a MAY?<br> <dbaron> q-<br> <faceless> myles: yes, what pete is aiming for is different<br> <florian> q?<br> <chris> the current "MYA" has a lot less detail<br> <florian> q+<br> <chris> s/MYA/MAY<br> <faceless> rossen: can we take the resolution now that changing the current definition to a SHOULD and live with that?<br> <faceless> myles: not unless someone can state what the SHOULD should say.<br> <tantek> agreed I want to see the full statement here in the minutes<br> <faceless> florian: agrees with myles<br> <tantek> +1 myles<br> <faceless> florian: you asked about next steps, the relevant user agents will attempt to do it once the SHOULD has been framed properly<br> <faceless> florian: after that, one the user-agents implement, we'll get feedback and see what to do then<br> <pes> q+<br> <faceless> florian: maybe we will find a line to draw to mkae a distinction, i.e. user agents loading from the file system. but we don't have that information onw<br> <faceless> s/onw/now<br> <Rossen__> q?<br> <faceless> svgeesus: pete if you're happy to make a first draft of the SHOULD recommendation I'm very happy to work with you on this<br> <faceless> pes: happy to, but is there a rough timeline, and also the current proposal points to a list maintained elsewhere. Is that the way we want to keep things?<br> <faceless> rossen: ok first issue. Do we ant to stick with a list that is maintained elsewhere<br> <faceless> dbaron: a list of what?<br> <TabAtkins> TabAtkins: local fonts that are allowed<br> <faceless> florian: the current spec is a list of things which are ok, - fonts<br> <heycam> +1 don't think where the list lives is the first thing to worry about here<br> <pes> q+<br> <faceless> floain: i think we should write the list down, put it wherever, once we have figured it out we can worry about where to put it later<br> <faceless> johnq: it's not clear where this this group maintaining a list is the right approach or whether we should look into platform APIs exist to determine which fonts are platform installed vs user installed.<br> <dbaron> s/johnq/jkew/<br> <faceless> jkew: it seems like maintaining a list is a never-ending nightmare. maybe OS vendors should maintain the list? I'm not sure it's realiistic that we maintain it.<br> <florian> q-<br> <myles> q+<br> <faceless> florian: no macOS API will give you that list. We should start with a list and once we've tried it out, we may find it's not the best option<br> <chris> q?<br> <faceless> rossen: lets try to find something actionable<br> <florian> s/once we've tried it out, , we may find it's not the best option/once we've written it, we can debate the proposal/<br> <faceless> pes: i understand the reticence against a list and wanting something easier to maintain.<br> <Rossen__> ack pes<br> <Rossen__> ack dbaron<br> <jensimmons> a ruberic<br> <faceless> dbaron: to respond to jkew and pes - list is maybe to specific a term. we shoould be describing what we want to do and on each platform there may be a different approach - an API, a list, it's the intent that matters.<br> <tantek> +1 dbaron<br> <faceless> dbaron: the main thing is that we try this and see what works.<br> <pes> what is the road to get to the right answer then?<br> <tantek> pes, where's the proposal? can you link it?<br> <tantek> start with that<br> <faceless> dbaron: I don't think we know what the best thing to do is yes. We can't specify this with the right level of detail on each platfrom, we need to allow for feedback from ach platform to find the best solution<br> <Rossen__> ack myles<br> <pes> this is not a new issue / problem. An outcome that is “vendors will look into it”, this is not progress<br> <faceless> myles: first, responding to florian: feels florian was assuming that there was a single set of fonts common to everyone. we don't do that - we have different sets for different parts of the world.<br> <faceless> myles: seo even just for us, we can't have a single list that is uniform.<br> <pes> [tantek : initial issue / concern https://github.com/w3c/csswg-drafts/issues/4055, follow up proposal: https://github.com/w3c/csswg-drafts/issues/4497]<br> <faceless> myles: so we certainly can't across all OSes<br> <pes> Github: https://github.com/w3c/csswg-drafts/issues/4497<br> <faceless> florian: I was saying the current proposal specifies a single list, but that's probably not ideal. But that's our start point as it's in the spec.<br> <Rossen__> q?<br> <faceless> myles: there is no list for our platforms about what the currently available fonts are - we use an API.<br> <faceless> rossen: next steps. Pete is going to take a stab at moving the current statement from a MAY to a more stict version of SHOULD<br> <tantek> pes, I think we're at the point where we need sample spec text proposed in the issue. Just reviewed the proposal bits and looks a bit scattered TBH<br> <faceless> rossen: and the technical recommendations of how to reference those fonts, dbaron said this well - referring to this as a list is not the full picture. But it is a start<br> <faceless> rossen: once we have the actual proposal we can try to narrow down the technical soution<br> <tantek> pes, I'm not disagreeing with the issue. I read through 4497 and the proposal there is more of an outline of desired outcome<br> <faceless> s/soution/solution/<br> <faceless> rossen: anything else?<br> <pes> tantek: this might be clsoer to what you’re looking for https://github.com/w3c/csswg-drafts/issues/4497#issuecomment-565832611<br> <faceless> rossen: pete, we're not trying to sandbag this - it's a normal process. we are interested in this and that might not be clear. Bear with us and once you have the actionable definition we'll go from there<br> <faceless> rossen: I suggest we end this and move on and will come back to it once pete has acted? on the next call?<br> <faceless> pes: when is that?<br> <faceless> rossen: probably two weeks<br> <tantek> pes, that's a very good summary start. Now, where in the spec would you put that, and can you reword it procedurally as a set of steps that browser should/must follow?<br> <faceless> roseen: thanks for your engagement<br> <faceless> s/roseen/rossen<br> <dbaron> The calls are Wednesdays at 9am California time / noon Boston time / etc.<br> <pes> tantek: on it :)<br> <tantek> pes, related, you may be interested in contributing to https://github.com/w3c/csswg-drafts/issues/4697<br> <faceless> rossen: ok, lets get on with it. a few text related topics. clarifying skip ink auto is related to CJK<br> <faceless> myles: no this was opened by jkew<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-578065380 using your GitHub account
Received on Friday, 24 January 2020 10:01:14 UTC