| 03:40 | <bakkot> | 11 hours until the meeting, woo |
| 04:55 | <littledan> | Wow I thought there was going to be a huge amount of under flow but it is not so much in the end |
| 09:00 | <Rob Palmer> | Reminder: Today's meeting is remote, starting at 10am in the New York timezone. That is 6 hours from now. |
| 14:31 | <Rob Palmer> | The sign-in link for Jitsi is now available via the entry form. Please don't post URLs into this publicly logged channel! Find it on the Reflector: https://github.com/tc39/Reflector/issues/454 |
| 14:41 | <littledan> | Please note that we will have stenography support at this meeting. You can find an explanation/disclaimer here: https://github.com/tc39/Reflector/issues/460 |
| 14:42 | <littledan> | Due to legal/GDPR concerns raised about stenography support, I want to reinforce that we will remove any information from the notes at participants' request (or direct edits). Further, any participant can feel free to either opt out of appearing in the notes, or object to the use of the stenographer overall. I will explain this at the beginning of the meeting |
| 14:44 | <littledan> | We will still need delegate note-correctors to ensure accuracy, but we expect their load to be considerably lightened, as in our previous experiment here. |
| 14:55 | <Rob Palmer> | *** The plenary meeting begin in 5 minutes *** |
| 15:01 | <ljharb> | hm, the jitsi link is timing out for me in my browser |
| 15:02 | <ljharb> | nvm, just took a few tries |
| 15:03 | <Rob Palmer> | we have 25 participants now - no tech problems so far |
| 15:06 | <msaboff> | Please add your name, abbreviation and organization to the top of the notes. |
| 15:08 | <ljharb> | have we started? i don't hear anything on the jitsi still |
| 15:08 | <msaboff> | We are underway |
| 15:08 | <ljharb> | i just hear the sound effects of joins |
| 15:08 | <ljharb> | hm, i'll try to restart the app |
| 15:08 | <ryzokuken> | can you refresh? |
| 15:09 | <ljharb> | disconnecting and reconnecting worked |
| 15:15 | <Michael Ficarra> | btw that is not a picture of F5 Tower |
| 15:16 | <Rob Palmer> | Sorry it was just supposed to be generic Seattle |
| 15:16 | <Rob Palmer> | I hope we don't disappoint anyone with the shape of the tower. |
| 15:16 | <Michael Ficarra> | it is still a pretty building, but it is no space needle |
| 15:17 | <bakkot> | I wonder how hard it would be go get chatGPT to re-format the notes... |
| 15:17 | <shu> | the space needle is diminuitive and puny |
| 15:19 | <davethegr8> | Did the meeting start? I am not getting audio or video |
| 15:19 | <waldemar> | The notes are a mess |
| 15:20 | <Michael Ficarra> | waldemar: we're working through technical difficulties |
| 15:21 | <bakkot> | davethegr8: yes, try reconnecting |
| 15:21 | <bakkot> | currently on the secretary's report |
| 15:22 | <davethegr8> | bakkot: that didn't help |
| 15:24 | <Rob Palmer> | davethegr8: You can select your audio device by clicking the upwards array next to the Microphone icon. |
| 15:27 | <ljharb> | we did used to have these nice "summary" docs volunteer-prepared by the chairs https://github.com/tc39/notes/blob/main/meetings/2020-07/summary.md but that's the most recent one, and they weren't always consistent before that either |
| 15:31 | <davethegr8> | Rob Palmer: I think I'm getting into a load failure loop on every browser |
| 15:37 | <Rob Palmer> | Is it possible you have some odd VPN/network? |
| 15:37 | <davethegr8> | Rob Palmer: was finally able to access via the ipad app, but the browser experience was impossible |
| 15:38 | <msaboff> | I think we actually want more that just the summary in the Ecma minutes. We should include key points in the discussions and any concerns raised. The minutes should include the resolution of those concerns. |
| 15:39 | <littledan> | msaboff: I agree, but this is a baseline that is already possible |
| 15:39 | <yulia> | i believe that the secretariat was suggesting that the champions summarize it |
| 15:39 | <yulia> | for each of their topics |
| 15:39 | <littledan> | I think it's important that we publish these abbreviated minutes somewhere more prominent than the Ecma filer |
| 15:40 | <littledan> | this all has been done in the past; we're just behind on it due to a lack of volunteers |
| 15:40 | <msaboff> | Putting it on Istvan is not the answer |
| 15:40 | <Michael Ficarra> | also we are still looking for a TG3 chair! |
| 15:40 | <littledan> | well, it is literally the secretary's job to prepare the minutes.... |
| 15:40 | <littledan> | anyway it's fine if we do it as a committee |
| 15:40 | <littledan> | I agree we need committee participation. Any of us could help prepare these summaries. I do like the idea of involving champions. We would also need someone to somehow organize the effort. |
| 15:44 | <littledan> | Note that the budget for the TC39 secretary is significantly higher than the budget for the transcriptionist, and there isn't much by way of deliverables beyond preparing the minutes |
| 15:44 | <msaboff> | If we had the secretary taking minutes, they wouldn't be transcriptions. |
| 15:44 | <littledan> | Yes, we're talking about something higher level |
| 15:44 | <yulia> | it is likely a good practice anyway as it will ensure that the champions understood the major points brought up in committee. I think what might be a good idea is dedicating 5 minutes for the champions that can also be used as a bio break. |
| 15:45 | <yulia> | summarization and rephrasing is a good way to ensure understanding |
| 15:45 | <littledan> | sounds good. yeah, I like the idea of doing it on-line, rather than a later homework assignment, to ensure shared understanding |
| 15:46 | <littledan> | This could be in the form of an extended conclusion section, so we'd include a summary of the discussion in addition to the conclusion, collected on-line in the same tehcnical notes document. |
| 15:46 | <yulia> | yes, with dedicated time we can ensure that this happens, plus it may give a much needed separation between topics -- sometimes (like now) we bleed in previous topics while the next one is being presented) |
| 15:46 | <littledan> | this is a good meeting to trial that, given that we have extra time |
| 15:47 | <yulia> | ^ cc Rob Palmer ryzokuken bterlson |
| 15:49 | <Michael Ficarra> | I think it's sufficient to just link to the slides for update topics |
| 15:49 | <littledan> | I think it's sufficient to just link to the slides for update topics |
| 15:49 | <yulia> | yeah or a copy/past of the bullets from the slide |
| 15:49 | <Michael Ficarra> | I've never asked myself what the conclusion was to an update topic when reviewing notes |
| 15:49 | <ljharb> | indeed, we usually don't have any kind of conclusion unless decisions were made |
| 15:49 | <littledan> | I think a copy-paste of bullets would be not helpful if it's not a subset |
| 15:50 | <yulia> | If the update was just the bullet points with no discussion, would we be able to say more than that? |
| 15:51 | <ljharb> | a "conclusion" requires that we concluded something. what could we conclude from an update? |
| 15:51 | <yulia> | maybe lets turn this around. we are communicating to a broader public, what is important for them to know from each update? |
| 15:51 | <Michael Ficarra> | conclusion: committee has understood the update |
| 15:52 | <yulia> | in the case of the ecma262 -- perhaps it is something along the lines of : we are doing minor editorial updates in line with the editorial plan, here are the summarized issues. <issues> |
| 15:52 | <ljharb> | ideally that'd be in the slides |
| 15:52 | <yulia> | this way, we can point to a general strategy (which we've seen for example the editors do) and say, here is the work that was done related to this |
| 15:53 | <yulia> | because the public will not be following at all times, and having something to get re-centered on will be useful |
| 15:54 | <yulia> | when i do summarizations for my team, i am usually copy pasting the general topic of a proposal (pulled from the repo + general notes over the years of discussion), plus bullet points of what is mentioned in the slides |
| 15:55 | <yulia> | we have a similar situation with people dropping in and out and this has been good for team knowledge. we are just now thinking about the public post factum (we do pre with post additions) and our summaries don't work for that. overall the strategy works though |
| 15:58 | <Rob Palmer> | I think we should develop guidelines in how-we-work to describe the ideal way to write a conclusion. |
| 15:58 | <Rob Palmer> | The suggestions here seem a great start. |
| 15:59 | <Ashley Claymore> | It would also be great to pause a little bit when moving between topics. It's a bit intense sorting the notes putting in the footer/header |
| 15:59 | <Ashley Claymore> | just a 30sec pause to settle would be great |
| 15:59 | <yulia> | or a couple of minutes honestly |
| 16:00 | <Michael Ficarra> | I'm kind of in favour of a stage between 3 and 4 |
| 16:01 | <Michael Ficarra> | "stage 3: impl experience, stage 3.5: web compat experience, stage 4: standard" |
| 16:02 | <Michael Ficarra> | that also gives us a nice place to add a test262 entrance requirement |
| 16:02 | <Michael Ficarra> | stage 4 is not the right place for that |
| 16:03 | <Michael Ficarra> | but stage 3 is maybe unnecessarily early |
| 16:03 | <ryzokuken> | ljharb: I was too late 😅 |
| 16:03 | <ryzokuken> | also the comment was so vague there was no way to guess! |
| 16:04 | <ljharb> | lol no worries, i was looking at the previous tcq link - i hadn't refreshed the reflector issue |
| 16:10 | <bakkot> | what if instead of arguing about what the current wording in the document means we figure out what we want it to mean and then find wording that everyone agrees means that |
| 16:10 | <yulia> | I agree with what dan is saying here, we are deliberately ambiguous about this. +1 to bakkot's comment |
| 16:10 | <shu> | dan's point is that we have tried and failed to find consensus |
| 16:10 | <ljharb> | i think the challenge is that we don't have consensus on what we want it to mean |
| 16:10 | <Michael Ficarra> | what if instead of arguing about what the current wording in the document means we figure out what we want it to mean and then find wording that everyone agrees means that |
| 16:10 | <shu> | for a wording that everyone agrees with |
| 16:10 | <ljharb> | the current wording allows for both viewpoints |
| 16:11 | <ljharb> | but it does not imo allow for an interpretation that something must not be shipped pre-stage-4 |
| 16:13 | <Michael Ficarra> | it sounds like Apple's stance is only compatible with a strategy of us adding a new stage between 3 and 4 |
| 16:13 | <rbuckton> | I have always been of the opinion that Stage 3 should mean "ready to implement", and Stage 4 should mean "ready to ship". If an implementer ships prior to Stage 4, it is the responsibility of the implementer to adjust to consensus changes. As it stands, Stage 4 just seems to be pro forma and has no real meaning. |
| 16:14 | <shu> | i won't agree with a new consensus seeking stage for when a browser can flip a flag |
| 16:14 | <shu> | you literlaly cannot gather compat feedback on canary populations |
| 16:14 | <Michael Ficarra> | rbuckton: stage 4 means people can reliably program against the standard and expect it to run correctly on any compliant implementations |
| 16:14 | <yulia> | you literlaly cannot gather compat feedback on canary populations |
| 16:17 | <shu> | yulia: good point, but it had to be unflagged at least |
| 16:18 | <shu> | and in the past there were changes we didn't really see compat issues until it hit stable? |
| 16:18 | <yulia> | yes, agreed -- thats how we fin them |
| 16:22 | <yulia> | and in the past there were changes we didn't really see compat issues until it hit stable? |
| 16:23 | <shu> | let's see... |
| 16:23 | <rbuckton> | Precisely. That to me indicates "ready to ship" for both engines and user code that depends on that functionality. Based on my observations over that past few years, Stage 3 seems to mean a feature is mostly stable but there could still be changes that impact syntax/semantics, especially regarding oversights or compatibility concerns. I've always been concerned that an engine shipping a Stage 3 feature that potentially gains mass adoption before it reaches Stage 4 can result in consensus changes in Stage 3 becoming impossible because of the potential to break the web. |
| 16:24 | <ljharb> | "ready to ship" and "ready to rely on" needn't be the same thing tho |
| 16:24 | <ljharb> | and those kinds of changes happen after stage 4 too, just, ideally less often |
| 16:25 | <yulia> | "ready to ship" and "ready to rely on" needn't be the same thing tho |
| 16:25 | <bakkot> | can't, really, because developers can't rely on something until it is already shipping and has been for a while |
| 16:25 | <ljharb> | littledan: so do we have a conclusion for that one? |
| 16:27 | <yulia> | rename of the column to indicate not shipping, but that we need coordination |
| 16:27 | <yulia> | is my understanding? |
| 16:27 | <ljharb> | ok - i think if we don't precisely mention "do not ship this" in some way it won't achieve the goal |
| 16:28 | <ljharb> | because the thing we need coordination FOR is "shipping" |
| 16:28 | <yulia> | I disagree |
| 16:28 | <yulia> | because we already do this coordination without this label |
| 16:28 | <ljharb> | otherwise we already have plenary and the reflector as a way to coordinate |
| 16:28 | <yulia> | temporal, private fields, etc. have all had an unofficial agreement |
| 16:28 | <ljharb> | right - for known implementations and participants |
| 16:29 | <ljharb> | the column would include implementations that aren't part of tc39, or, specific implementor people who aren't |
| 16:29 | <yulia> | afaik those do not impact web compat as significantly as the three major browsers |
| 16:29 | <ljharb> | sure |
| 16:29 | <yulia> | though im open to being surprised, it would need evidence though |
| 16:30 | <ljharb> | so how do we communicate to the broader public, then, that the three major browsers have agreed not to ship something yet, without mentioning "shipping"? |
| 16:30 | <yulia> | i believe that the public gets this information in other ways, for example -- many will get it from looking at chrome logs, or can-i-use |
| 16:30 | <ljharb> | they can, sure. whether they do or not is i think more vague |
| 16:30 | <yulia> | by coordinating, the signal that something is shipping by default in a major browser never happens |
| 16:31 | <ljharb> | caniuse tells them that it hasn't shipped, but not why |
| 16:31 | <yulia> | so the signal that you are citing never happens |
| 16:31 | <ljharb> | the proposal's advancement to stage 3 is that signal |
| 16:31 | <shu> | wait i don't care about the wording |
| 16:31 | <ljharb> | despite michael's interpretation, devs do interpret stage 3 as "will be shipping" |
| 16:31 | <yulia> | stage 3 is not a sign that users can use a feature |
| 16:31 | <shu> | i'm happy with whatever wording other people can live with if the thing being signalled is the same |
| 16:31 | <shu> | right, stage 3 is a sign to implementers |
| 16:32 | <ljharb> | but it's also become a signal to users, that implementors will be shipping soon |
| 16:32 | <yulia> | stage 3 is not a sign that users can use a feature |
| 16:32 | <yulia> | but it's also become a signal to users, that implementors will be shipping soon |
| 16:32 | <shu> | ljharb: also agree, but a small degree relatively |
| 16:32 | <yulia> | for example private fields. |
| 16:32 | <yulia> | that was 5 years |
| 16:32 | <ljharb> | there are some. not many. |
| 16:32 | <yulia> | or something likethat |
| 16:32 | <ljharb> | private fields, and temporal, are certainly notable examples. but they're rare. |
| 16:32 | <yulia> | the stronger signal is that a browser is shipping unflagged |
| 16:32 | <shu> | i have another mtg i gotta drop for 30min |
| 16:33 | <ljharb> | right. and when a proposal hits stage 3 - something that takes many many years sometimes - users get excited that at some point in the near term, browsers will be shipping it and they can use it |
| 16:33 | <ljharb> | i've fielded hundreds of questions on irc and slack about "why hasn't temporal shipped yet‽ it's stage 3!" |
| 16:34 | <yulia> | im not really sure where this is going... the reason for temporal was stated pretty early |
| 16:34 | <yulia> | i think at stage 3 advancement |
| 16:35 | <ljharb> | yes but it's not stated on the proposals page. where users look. |
| 16:35 | <yulia> | giving contextual information is always useful |
| 16:35 | <yulia> | i think it is a different topic though |
| 16:36 | <ljharb> | in practice there's a huge difference for users between stage 3 proposals that have this unofficial agreement, and don't. i see the column dan proposed as a clear way to label those |
| 16:36 | <Michael Ficarra> | ooohh I really like the idea of explicitly soliciting non-blocking dissent |
| 16:36 | <yulia> | im not sure where we are disagreeing? |
| 16:36 | <Michael Ficarra> | HUGE +1 to that |
| 16:36 | <ljharb> | ha, maybe we aren't :-) i'm saying that the wording on such a column needs to imply shipping (or not shipping) somehow, to be clear to users. |
| 16:37 | <yulia> | ah, this is where we disagree -- i don't think it should, as per ron bucktons comment -- shipping can be misunderstood. i would say that a better place for "this is not shipping because .." information is in the proposal repo itself. |
| 16:38 | <ljharb> | my experience is that the current scenario is what's most often misunderstood, not the meaning of "shipping". |
| 16:38 | <yulia> | i think you are looking to solve a different problem. and it can be solved, but not by forcing the wording as you are suggesting |
| 16:39 | <yulia> | there are other places with that information |
| 16:39 | <Michael Ficarra> | can we just add a ⚠️ emoji? |
| 16:39 | <yulia> | honestly that would work for me |
| 16:39 | <ljharb> | lol yes but with what column header :-p |
| 16:39 | <Michael Ficarra> | 🤔 |
| 16:40 | <ljharb> | 🚢 |
| 16:40 | <bakkot> | I am happy with "don't block a proposal from stage 1 because you dislike the current shape of the proposed solution", and less happy with "don't block a proposal from stage 3 because you dislike the major API decision [which are made in the process of getting stage 2]" |
| 16:41 | <ljharb> | (altho major API decisions are often made in stage 2) |
| 16:41 | <bakkot> | regrettably, yes |
| 16:41 | <Justin Ridgewell> | Was there a conclusion for "Stage 3 ready to ship" talk? |
| 16:41 | <Justin Ridgewell> | (In a company meeting, so missed that and the current talk) |
| 16:42 | <yulia> | i would say that all stages should be blockable for any reason, except stage 3 to 4 transition |
| 16:42 | <yulia> | but, explicit discussion is better than silence |
| 16:42 | <ljharb> | blocking stage 1? |
| 16:42 | <bakkot> | yes, you should be able to block stage 1 |
| 16:42 | <ljharb> | not for any reason tho |
| 16:42 | <ljharb> | the only reason to block stage 1 is generally that the committee doesn't want to spend time solving the problem |
| 16:43 | <bakkot> | or doesn't agree it's a problem, sure |
| 16:43 | <ljharb> | right |
| 16:43 | <ljharb> | imo there exists reasons to block any transition, even 3 to 4, it's just that the list of those reasons gets rapidly smaller as things advance |
| 16:43 | <yulia> | yes, you should be able to. I think the goal of diversity is not very well achieved by allowing everything into stage 1 -- in particular i believe we block previously discussed proposals that are already stuck on the same problem, things that break significant properties of the language, and others |
| 16:44 | <yulia> | imo there exists reasons to block any transition, even 3 to 4, it's just that the list of those reasons gets rapidly smaller as things advance |
| 16:44 | <bakkot> | 3 to 4 it is not clear there is any valid reason to block, if it's web reality |
| 16:44 | <yulia> | well... there may be reasons... |
| 16:44 | <ljharb> | yes, absolutely "i don't like it" is not a valid reason to block stage 4 |
| 16:44 | <yulia> | similar to degrading 4 (like we did with i think it was implicit eval?) |
| 16:45 | <ljharb> | but "i don't believe there's been sufficient shipping experience to ameliorate compat risk" is a valid one |
| 16:45 | <yulia> | this is already in the process doc fwiw |
| 16:49 | <yulia> | unfortunately we don't have anchor tags, but its under tips for consensus here: https://tc39.es/process-document/ |
| 16:49 | <ljharb> | we can add anchors anywhere we want :-) i'll take a look at that later today |
| 16:53 | <yulia> | this is great, thanks littledan for driving this |
| 16:54 | <Anthony Bullard> | A small, unimportant question while the meeting is in session, but who is the maintainer for the TCQ app and is it open contribution? |
| 16:54 | <nicolo-ribaudo> | A small, unimportant question while the meeting is in session, but who is the maintainer for the TCQ app and is it open contribution? |
| 16:55 | <ryzokuken> | nicolo-ribaudo: beat me to it |
| 16:55 | <Anthony Bullard> | Thanks Nicolo |
| 16:55 | <Anthony Bullard> | Noticed that it does not show the navigation on narrower screen widths, which should be quick to fix |
| 16:57 | <bakkot> | thanks for bringing forward this process change littledan |
| 17:05 | <shu> | what was the conclusion to the consensus item? |
| 17:05 | <shu> | is there a change to process? |
| 17:07 | <yulia> | afaik it is to the how we work document? |
| 17:07 | <shu> | to encourage more explicit support from non-champions? |
| 17:08 | <shu> | (i had to drop for a different call, trying to understand what we concluded from the notes) |
| 17:08 | <yulia> | yes, this was my understanding. More explicit support, and more explicit non-blocking concerns |
| 17:08 | <shu> | thanks |
| 17:09 | <bakkot> | My understanding is that there are two changes: 1.) a non-normative change to make time for encouraging non-blocking concerns to be raised during the advancement-seeking part, and 2.) a normative change to require explicit support from at least two non-champions during the advancement-seeking phase in order for a proposal to advance stages |
| 17:10 | <Justin Ridgewell> | Are we at lunch? |
| 17:11 | <Anthony Bullard> | Yes |
| 17:13 | <Justin Ridgewell> | Was there a conclusion for "Stage 3 ready to ship" talk? |
| 17:15 | <Ashley Claymore> | and Dinner too |
| 17:16 | <littledan> | I will update the conclusion in the notes (after I have lunch) |
| 17:18 | <littledan> | the conclusion was, "we can land something like the how-we-work PR but we need to switch out the column title to be compatible with multiple interpretations of Stage 3" |
| 17:51 | <yulia> | I'm off this afternoon, see you all tomorrow morning |
| 17:58 | <Rob Palmer> | We are restarting plenary in 1 minute! |
| 18:00 | <msaboff> | The transcribers are human as well |
| 18:00 | <Rob Palmer> | yes! |
| 18:03 | <littledan> | The transcribers are human as well |
| 18:04 | <Ashley Claymore> | I know it's not 'standard', but just to say it is also super helpful when people put their acronym in their Matrix display name (as many people already have, thank you!!) |
| 18:05 | <Ashley Claymore> | I've memorized as many voices->acronyms as my brain can handle now ;) |
| 18:05 | <bakkot> | littledan: Rob was saying stuff like "people doing the human part of the notetaking" to mean the people adding delegate names and so on |
| 18:05 | <bakkot> | which made sense when the main notetaking was done by a bot, less now |
| 18:05 | <littledan> | ah! I logged in while he was in the middle of clarifying |
| 18:19 | <Michael Ficarra> | someone who can take a mitigation action for this attack can also change their data structure to { __proto__: null } or new Map |
| 18:19 | <ljharb> | i agree, that's my queue item in a nutshell |
| 18:20 | <ljharb> | Ashley Claymore: what's the transcription suggestion? |
| 18:20 | <Michael Ficarra> |
|
| 18:23 | <Michael Ficarra> | a directive wouldn't make sense for this because it's not syntactically bounded |
| 18:24 | <bakkot> | CVE-2022-46164 appears to be, the client sends messages like |
| 18:24 | <bakkot> | making that one not work requires specifically cutting off dynamic access to Object.prototype.constructor, not .prototype |
| 18:25 | <ljharb> | the __proto__ and constructor accessors are already normative optional |
| 18:26 | <bakkot> | Object.prototype.constructor is not optional and is also not an accessor |
| 18:26 | <ljharb> | node has a flag to remove the proto one, but ofc it breaks things to use it. |
| 18:26 | <ljharb> | ohh right sorry |
| 18:26 | <bakkot> | the __proto__ accessor is though |
| 18:33 | <Luca Casonato> | node has a flag to remove the proto one, but ofc it breaks things to use it. __proto__ accessor (with no opt out). Even in Node compat, we can run essentially all commonly used code. For this most commonly used code, all of the accesses to __proto__ were happening in very few third party modules (which we managed to get fixed up with the maintainers over about a year). I am sure there is a long chain of rarely used modules that would still break, so I agree with your "this will break the web". But with an opt-in mode, this seems pretty viable nowadays. |
| 18:34 | <ljharb> | i agree that via evangelism it's potentially tractable - altho much less so on the web than on a server - but without enabling it by default i'm skeptical it will actually prevent the problems it aims to |
| 18:34 | <littledan> | ljharb: The presenters have explained why an opt-in mode can be helpful in practice; did you find their explanation persuasive? |
| 18:34 | <Luca Casonato> | i agree that via evangelism it's potentially tractable - altho much less so on the web than on a server - but without enabling it by default i'm skeptical it will actually prevent the problems it aims to |
| 18:35 | <Luca Casonato> | but i agree, that does not solve the adoption problem on the web |
| 18:35 | <ljharb> | no, because if you know to opt in you've already had solutions for decades. eg i just stick a $ in front of all my keys on write or read and the problem is fixed |
| 18:37 | <Jack Works> | this is like SES lockdown. I open lockdown() and found libraries crashes, but that's still better than works but security holes |
| 18:37 | <littledan> | I think the key property was, the opt-in is global whereas those mitigations are local and distributed |
| 18:37 | <ljharb> | oh, it's not per scope, it's global? |
| 18:38 | <littledan> | yeah |
| 18:38 | <Justin Ridgewell> | no, because if you know to opt in you've already had solutions for decades. eg i just stick a |
| 18:38 | <littledan> | well, maybe undefined for now, but that is one possibility |
| 18:38 | <Jack Works> | oh, it's not per scope, it's global? |
| 18:38 | <ljharb> | I don't see how that solves the problem? |
| 18:38 | <bakkot> | yeah one of the potential things is "a header that changes behavior of all JS on the page" |
| 18:38 | <ljharb> | if it's global, then i agree that it would work, but i'd be even more confident that it wouldn't be web compatible to enable it by default, and potentially not practical for many to enable anyways - like CSP. |
| 18:39 | <bakkot> | well, right, but the proposal would be opt-in, as they say |
| 18:39 | <bakkot> | and yeah many people wouldn't, but, I see CSP a lot, so these opt-in mitigations are seeing use |
| 18:39 | <bakkot> | at least on, like, banks |
| 18:39 | <Jack Works> | another thing to worry about is, HTTP header is longer and longer 🤔 |
| 18:40 | <Jack Works> | CSP COOP COEP ... |
| 18:40 | <Jack Works> | and we're going to add more |
| 18:40 | <Michael Ficarra> | This problem is worth researching, but I doubt any of the proposed solutions are feasible. My bet is that we can let this solve itself. As people start using Maps, the problem will subside. And I expect Maps to start being used more as older browsers without Maps die off. |
| 18:40 | <bakkot> | I do not expect Maps to start being used more, since their UX is worse |
| 18:41 | <Michael Ficarra> | maybe making their UX better can be pursued as part of this effort |
| 18:41 | <bakkot> | Not as part of this effort, surely... |
| 18:41 | <Michael Ficarra> | why not? |
| 18:41 | <bakkot> | re: feasibility, I suspect that the "__proto__ does not work in computed keys" thing would be compatible with almost all apps, so I think that at least is likely to be feasible |
| 18:42 | <ljharb> | using a Map would be a callsite-based mitigation, no? |
| 18:42 | <bakkot> | I am much more skeptical of the feasibility of making prototype and constructor not work in computed keys, though |
| 18:43 | <Santiago Diaz> | many common features force you to write vulnerable code, like copying properties from one object to another, reading from postMessage, etc. - that makes hoping for the issue to go away with maps a lot more convoluted, I think |
| 18:43 | <bakkot> | nitpick: postMessage works with Maps, people just don't |
| 18:43 | <littledan> | how does SES address the stratification issue? |
| 18:44 | <bakkot> | (I think, anyway?) |
| 18:44 | <Anthony Bullard> | This may be my lack of knowledge and experience here, but could many of these issues not be solved by running third party code in separate Realms? |
| 18:44 | <Anthony Bullard> | I thought that was part of the Realms proposal. |
| 18:44 | <bakkot> | Anthony Bullard: very few of these are about third-party code |
| 18:45 | <bakkot> | at least in the traditional sense of "code" |
| 18:45 | <ljharb> | here's es6-shim, deployed on lots of websites, using __proto__ dynamically: https://github.com/paulmillr/es6-shim/blob/98a175f41849f9894a21794a3e2767cdfc421a19/es6-shim.js#L1538-L1587 |
| 18:45 | <Anthony Bullard> | Tell me more :-) |
| 18:45 | <Jack Works> | well, since it is opt-in, you can upgrade/patch the library |
| 18:46 | <Jack Works> | this is how we adopt lockdown() to freeze primorials |
| 18:46 | <ljharb> | right - but it means even the proto changes couldn't be by default. |
| 18:46 | <bakkot> | ljharb: does that code run in environments which support modern features? |
| 18:46 | <bakkot> | Yeah I think no one has proposed making this on by default |
| 18:46 | <ljharb> | yes, shims are typically ran unconditionally so they can patch behavior as needed via feature detection |
| 18:47 | <bakkot> | assume the feature detects as present - does the linked section of code still run? |
| 18:48 | <bakkot> | sorry, by "the feature" I mean setPrototypeOf |
| 18:48 | <bakkot> | I guess this is maybe the code which detects the feature? |
| 18:48 | <ljharb> | oh, i see what you're asking. presumably if the one that's present behaved, then it wouldn't install anything - but the detection code itself, that always runs, relies on the feature, yes. |
| 18:48 | <Jack Works> | sorry, by "the feature" I mean __proto__ because it's shorter |
| 18:50 | <ljharb> | in this specific code, the original author seems to have used a variable solely to avoid having to repeat the ugly __proto__ multiple times |
| 18:50 | <bakkot> | reading the code I think it still would end up working - you'd hit the _call(set, {}, null) line, and either that would not throw (and so you get the accessor you wanted) or it throws and you hit Object.prototype !== {}[magic] (and it gives up) |
| 18:50 | <bakkot> | either way it works out |
| 18:51 | <ljharb> | interesting, you may be right |
| 18:51 | <ljharb> | that was just the first place i looked, i'll check some other packages |
| 18:51 | <bakkot> | yeah |
| 18:51 | <bakkot> | I mean, I am sure there would be at least some breakage from changing this behavior |
| 18:52 | <bakkot> | but I think it likely to be small enough to be feasible to opt-in in a lot of places |
| 18:52 | <Jack Works> | in this specific code, the original author seems to have used a variable solely to avoid having to repeat the ugly |
| 18:54 | <ljharb> | lol i agree, but i added it nearly a decade ago ( https://github.com/paulmillr/es6-shim/commit/792b0d58015e58773ff988fe4a3373c74c200fae ) and haven't touched it meaningfully since |
| 18:55 | <bakkot> | it's stuff like this: https://matrixlogs.bakkot.com/TC39_Delegates/2023-01-30#L227 |
| 18:56 | <bakkot> | where you're passing around dynamic paths and then accessing those |
| 18:57 | <snek> | why is __proto__ factored out into magic |
| 18:57 | <snek> | just out of curiosity |
| 18:58 | <Michael Ficarra> | probably manual minification |
| 18:58 | <ljharb> | why is |
| 19:02 | <Anthony Bullard> | Oh, I see. |
| 19:02 | <Anthony Bullard> | So very unintentionally polluting the prototype chain within your own code |
| 19:03 | <snek> | matrix message links do not work very well |
| 19:03 | <snek> | but i managed to find the message, ty |
| 19:04 | <snek> | +100 support for this change lol |
| 19:04 | <ljharb> | is kevin's voice robotting for anyone else, or just me? |
| 19:04 | <snek> | it sounds ok for me |
| 19:04 | <snek> | i mean not great but like normal jitsi quality |
| 19:04 | <ljharb> | it might be just me then, i've been having internet trouble |
| 19:04 | <Michael Ficarra> | no more than usual ljharb |
| 19:04 | <shu> | kevin sgtm |
| 19:05 | <shu> | there's a little static but his voice is unmodulated to me |
| 19:05 | <snek> | i'm spoiled by google meet and discord voice call quality, jitsi always sounds like robots |
| 19:07 | <ljharb> | zoom for me, but true |
| 19:07 | <ryzokuken> | there's uhhh no solution that works for everyone 😅 |
| 19:08 | <shu> | conference phone call |
| 19:08 | <ryzokuken> | SIP /s |
| 19:08 | <shu> | "so-and-so, your line is now open" |
| 19:08 | <ryzokuken> | I suppose next meeting would be zoom, so we'd see how it goes |
| 19:08 | <ryzokuken> | but I'm terrified already, fingers crossed |
| 19:09 | <Michael Ficarra> | we would prefer Zoom, but Rob has asked us to try Meet first |
| 19:10 | <ryzokuken> | if that'd be possible, I'd be personally grateful to you |
| 19:10 | <snek> | tbc i'm totally fine with jitsi, i was not saying we need to switch |
| 19:11 | <Michael Ficarra> | littledan: It is not a consensus-seeking matter. The editor group believes this is fully within our control. We are just looking for feedback before making the change, in case there are things we didn't think of. |
| 19:15 | <shu> | by "all my hats" i meant something like, i recuse myself as editor |
| 19:15 | <Michael Ficarra> | on the scale of refactorings we've done recently, this actually isn't all that big lol |
| 19:15 | <shu> | but as implementer and mentor for new folks to the spec on V8, this will be a lot clearer |
| 19:25 | <Michael Ficarra> | unfortunately, identity isn't the appropriate concept for intuition either |
| 19:25 | <shu> | liveness is, but it's tied to identity |
| 19:25 | <shu> | identity by itself isn't |
| 19:25 | <snek> | forgability |
| 19:25 | <shu> | the intuition i think is something like can be reasonably considered to have liveness |
| 19:26 | <shu> | which is like... idk you tell me |
| 19:43 | <shu> | i would unship TA#sort if i could! |
| 19:43 | <shu> | i will die on the hill that there is no use case for sorting your bytes |
| 19:43 | <ljharb> | middle-endian |
| 19:44 | <shu> | chef's kiss would've been if by default, it used lexicographic sort |
| 19:48 | <bakkot> | speaking of TAs, there was a request from the W3C ColorWeb CG for float16-TAs if anyone wants to pick that up https://github.com/tc39/proposals/issues/453 |
| 20:08 | <littledan> | Yeah Anne had written me about this, it is a Googler who wanted to push it forward I think |
| 20:08 | <littledan> | I previously asked the former champions to work more on web platform integration, and now the request is coming from that side directly, so it is completely met |
| 21:54 | <shu> | who wants it? webgpu? |
| 21:55 | <shu> | i have some vague memory of Kai Ninomiya mentioning this but i may be misremembering |
| 22:04 | <ljharb> | i'd be happy to pick it up, but tbh i can't commit to unfunded time on it rn (i am available with funding tho) |