- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jan 2025 17:19:14 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[meta] Rechartering 2025-2027`. <details><summary>The full IRC log of that discussion</summary> <bramus> ChrisL: few responses<br> <bramus> ChrisL: 1st response saying nothing special<br> <bramus> ChrisL: 2nd asking extra language<br> <bramus> ChrisL: response is that it sounds great and doesnt sound specific to CSS. suggestion to suggest to other group or some wording. no response yet.<br> <dbaron> s/nothing special/editorial addition saying CSS is good for a11y/<br> <bramus> ChrisL: suggestions welcome here<br> <ChrisL> https://www.w3.org/2024/09/font-i18n-privacy.html<br> <bramus> ChrisL: here is a link to a doc I wrote for tpac<br> <bramus> … long running issue is sometimes called a privacy issue or an i18n issue that pulls in opposite directions<br> <bramus> … had good discussion at TPAC<br> <bramus> … now, third comment … from center for democracy and technology<br> <fantasai> Regarding the previous point, how much of what's requested actually belongs in the charter?<br> <bramus> … looking forward to collaborating with css and privacy and i10n<br> <bramus> … not sure we can change charter to say we have more progress on this<br> <bramus> … i think they are saying that we should keep going<br> <bramus> … would love to reply that we will do that<br> <bramus> … does that seem reasonable?<br> <bramus> astearns: sounds reasonable<br> <bramus> ChrisL: can you send that?<br> <bramus> astearns: where to send it to?<br> <bramus> ChrisL: somewhere public would be good<br> <bramus> … should be addressed to the privacy wg and i18n wg<br> <bramus> … all of those were comments of the form whether we are doing things about something<br> <bramus> … last one is from brave and is a formal objection<br> <ChrisL> https://lists.w3.org/Archives/Member/w3c-css-wg/2025JanMar/0017.html<br> <bramus> ChrisL: unfortunately they were not able to attend the meeting at tpac back in the day<br> <bramus> … its not clear whether they realize work had been done, although they sort of quote a bit from that<br> <bramus> … i think they are aware but htey are saying we are doing nothing and are not addressing things<br> <ChrisL> Brave will happily remove our FO to the rechartering if the group proposes<br> <ChrisL> a plan to address the fingerprinting surface, and to commit to<br> <ChrisL> incorporating mitigations for this fingerprinting vulnerability into the<br> <ChrisL> group's specs.<br> <bramus> … they will remove FO if the WG plans to remove the fingerprinting surface<br> <bramus> … (see copy-paste)<br> <bramus> … also saying that our _refusal_ to address is concerning<br> <bramus> … what should we do as a group?<br> <bramus> astearns: my recollection is that we sort of had a plan, but not one that we can push through the specs directly<br> <bramus> … we thought that there would be a way of threading th eneedle between i18n and privacy<br> <bramus> … in saying that “yes browsers can limit access to user installed fonts if they provide a UI that popped in“<br> <bramus> ChrisL: my recollection as well, but have no resolution on that<br> <astearns> s/popped/opt<br> <bramus> … i think that nick dotty was of the opionion that UAs should do that<br> <bramus> … cost is that its an opt-in, either web wide or site-specifici<br> <bramus> … seems clear enough to propose as spec text<br> <jensimmons> q+<br> <bramus> … also true that ther eare other fingerprinting issues and should commit to solving those<br> <bramus> jensimmons: if there is gonna be text that mandates a UA to turn off privacy preservering features then I need to discuss internally<br> <bramus> astearns: but that has been a way forward for a while<br> <bramus> … maybe apple have arleady been thingkin gabout this<br> <bramus> jensimmons: I will try to find out<br> <bramus> ChrisL: Of course I will put proposed text into an issue, not directly in the spec.<br> <bramus> … dont want to break the web<br> <ChrisL> qq+<br> <bramus> fantasai: one of the things we can do to reduce the surface is to only allow access to user installed fonts if they give you access to code points that is outside the range of those served by the system<br> <bramus> … could limit it to letters<br> <bramus> … outside of the normal range<br> <astearns> ack jensimmons<br> <astearns> ack fantasai<br> <bramus> … but would allow a browser to uncoditoianlly allow access to user installed fonts, but only when necesaary<br> <astearns> ack ChrisL<br> <Zakim> ChrisL, you wanted to react to a previous speaker<br> <bramus> ChrisL: sometimes people install a newer version of a font because some glyphs were wrong, so doing a codepoint by codepoint thing means they would still get the broken behavior<br> <bramus> astearns: for the purpose of this discussion: chris you will open an issue with a proposed text and we will discuss that on a call very very soon and show that as the proposed plan that brave is requiring<br> <bramus> ChrisL: yes<br> <bramus> fantasai: when does our charter expire?<br> <bramus> ChrisL: have until march<br> <bramus> fantasai: so can discuss at f2f<br> <bramus> jensimmons: would love to see this fonts issue written out separately, in 1 place<br> <bramus> ChrisL: the whitepaper I linked to is basically that writeup<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10671#issuecomment-2593520980 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 January 2025 17:19:15 UTC