| 01:06 | <bakkot> | tcq is back! 🥳 |
| 01:10 | <bterlson> | Yes sorry about TCQ friends. Freak accident combined with paternity leave was a bad combo :-P |
| 01:12 | <Justin Ridgewell> | Can an admin update the Reflector link in the room description? |
| 01:12 | <Justin Ridgewell> | https://github.com/tc39/Reflector/issues/380 |
| 01:12 | <littledan> | bterlson: Congrats on paternity! |
| 01:20 | <littledan> | Does anyone know what the current status of archival is, in terms of whether we're managing to archive everything in our GitHub org, and how to access the archives? |
| 01:34 | <ryzokuken> | why are there multiple JSON standards? I thought ECMA-404 was the "canonical" JSON standard but apparently IETF has its own JSON? |
| 01:35 | <littledan> | everyone considers their own standard canonical! |
| 01:35 | <ryzokuken> | well, let me rephrase, I thought JSON was TC39's domain... |
| 01:36 | <ryzokuken> | https://datatracker.ietf.org/doc/html/rfc8259 btw |
| 01:36 | <ljharb> | a musical canon of standards / a round of JSON? |
| 01:37 | <bterlson> | I see them as complimentary standards. ECMA404 is very conservative, describes syntax mechanically, doesn't add much editorial fluff or advisory information |
| 01:37 | <ryzokuken> | wonder if there's any difference between the two standards: if the IETF standard is a subset/profile then I guess that's not that unexpected. |
| 01:37 | <bterlson> | I use 8259 when I need to show people why it's a bad idea to use the complete grammar in ECMA-404 |
| 01:38 | <HE Shi-Jun> | JSON is cross language/platform :) |
| 01:38 | <bterlson> | e.g. if you expect precision greater than IEEE754 doubles, , you're going to have a bad time, and RFC8259 helpfully calls that out |
| 01:39 | <ryzokuken> | thanks for pointing out the differences. Is something on that published somewhere? (maybe you should write something, it'll be useful 🙈) |
| 01:40 | <ryzokuken> | but I generally expected the IETF standard to be more... concise. This is definitely a fun data point! |
| 01:43 | <ryzokuken> | the next IETF meeting (november 2021) is supposed to be in-person... |
| 01:43 | <bterlson> | You can ctrl+f rfc8259 for the phrase "interoperable in the sense that" to see the places where IETF suggested you avoid some corner of JSON |
| 01:43 | <Richard Gibson> | https://datatracker.ietf.org/doc/html/rfc8259#section-1.2 includes explicit reconciliation:
|
| 01:43 | <HE Shi-Jun> | Yeah, JSON itself do not support specific type, there is always confusion/complain about int64 |
| 01:44 | <ryzokuken> | You can ctrl+f rfc8259 for the phrase "interoperable in the sense that" to see the places where IETF suggested you avoid some corner of JSON |
| 01:44 | <HE Shi-Jun> | We also have the trouble of serialization of BigInt/Date/etc. |
| 01:45 | <ryzokuken> | HE Shi-Jun: what's wrong with ISO8601/RFC3339 for Date serialization? |
| 01:45 | <bterlson> | One problem we run in to is you need to know schema to know whether to treat a string value as a date value |
| 01:46 | <HE Shi-Jun> | The problem is you don't know whether it's a date value or string :playful: |
| 01:46 | <bterlson> | implementations which detect date-like strings and convert to date types have been highly problematic in the past |
| 01:47 | <bterlson> | int64 has similar problems - there is no good option. You encode as a number literal and lose precision as the json document traverses a JS runtime. Or you encode as a string and you either need schema or users have to deal with converting to int64 themselves. |
| 01:47 | <HE Shi-Jun> | Previously I wrote a JSON hint proposal ( https://gist.github.com/hax/5691ca8acdf9179e63043857cdc3616b ) to solve the problem in general , does anyone interest in that? |
| 01:47 | <ryzokuken> | Previously I wrote a JSON hint proposal ( https://gist.github.com/hax/5691ca8acdf9179e63043857cdc3616b ) to solve the problem in general , does anyone interest in that? |
| 01:48 | <ryzokuken> | well I dunno what's so wrong assuming valid ISO8601 strings were dates? but I might be missing something here |
| 01:48 | <bterlson> | There are many problems 😁 |
| 01:49 | <bterlson> | For example, performance - you are now attempting to parse every string field. |
| 01:49 | <ryzokuken> | well, I'm running a regex over every field |
| 01:49 | <bterlson> | also, it can become unpredictable what the type of a field actually is - if I so happen to have data that matches the ISO8601 grammar, all of a sudden things are dates, but if not, its strings. |
| 01:49 | <ryzokuken> | and parsing if it matches the regex |
| 01:50 | <ryzokuken> | hm, that's fair. I guess you can assume strings and let users deal with things as they want |
| 01:50 | <bterlson> | I think when you know schema, the practice is fine (we do it all the time in Azure), but it gets messy when dealing with schemaless json |
| 01:51 | <ryzokuken> | sounds fair |
| 01:51 | <ryzokuken> | You should be able to know where the dates are. Any combing through should be done explicitly by the user if needed... |
| 01:52 | <bterlson> | yeah I think that's right |
| 02:08 | <littledan> | Leo says he is stepping away for dinner and has no update |
| 02:08 | <littledan> | (for test262) |
| 02:16 | <leobalter> | Thank you! I'm back now! |
| 02:20 | <littledan> | we're going to be hearing from someone from the LF on this topic too, right? |
| 02:20 | <ryzokuken> | I think so |
| 02:20 | <ryzokuken> | Rob asked them to present to us and they gladly agreed |
| 02:21 | <Aki> | Yeah but I don't think we ever got confirmation |
| 02:22 | <littledan> | hmm, are they not in the call? |
| 02:22 | <littledan> | Do you know who was going to give the update, so we can try to ping them? |
| 02:22 | <littledan> | I'm afraid this presentation isn't explaining things very clearly |
| 02:22 | <ryzokuken> | I think I recall Mike Dolan... |
| 02:23 | <littledan> | OK, Mike Dolan doesn't seem to be here |
| 02:23 | <bakkot> | does anyone know what acryonym he keeps saying |
| 02:23 | <bakkot> | "GDF"? "TGF"? |
| 02:23 | <HE Shi-Jun> | JDF |
| 02:23 | <ryzokuken> | JDF |
| 02:23 | <ryzokuken> | yeah I don't think anyone from LF ended up making it... maybe we can end this one early and come back to it later? |
| 02:24 | <HE Shi-Jun> | but I also want to ask what is JDF |
| 02:24 | <Aki> | JDF https://duckduckgo.com/?q=jdf+foundation |
| 02:24 | <devsnek> | Juvenile Diabetes Research Foundation |
| 02:24 | <Aki> | sorry i didn't mean to drop a ddg link |
| 02:24 | <ljharb> | https://www.jointdevelopment.org/ ? |
| 02:24 | <Aki> | that was a mistake |
| 02:24 | <Aki> | yes that ljharb |
| 02:24 | <Aki> | i just didn't remember their domain |
| 02:26 | <littledan> | OK, could the chairs figure out who from the LF we can invite to clarify all of these things? |
| 02:26 | <littledan> | I think Rob was leading this previously, and tried to set up that someone could attend to explain |
| 02:26 | <littledan> | I think the LF proposal is good, and I'm really confused about why Istvan is casting all this doubt on it. |
| 02:27 | <Aki> | I'll see if i can get ahold of Mike |
| 02:27 | <Aki> | yeah |
| 02:27 | <Aki> | about that |
| 02:27 | <Aki> | anyway fwiw this will be a GA vote, tc39 has very little sway in whether it happens or not |
| 02:27 | <shu> | this is too much inside baseball for SDO politics, can we get a champion for either side to explain implications for TC39's working mode? |
| 02:28 | <shu> | changes to IPR stuff makes me wary |
| 02:28 | <ryzokuken> | shu: my understanding is that they do not want to change the IPR, on the contrary, they want to be able to veto changes to the IPR policy |
| 02:28 | <shu> | that is a change to the process |
| 02:29 | <ryzokuken> | (because they value the status quo) |
| 02:29 | <shu> | that veto power is a special power given to LF over other members |
| 02:29 | <littledan> | the idea is just to make sure that we keep the IPR policy open |
| 02:29 | <shu> | i do not understand that change |
| 02:29 | <littledan> | I think the LF partnership would be very valuable, and we should discuss it further with them. I am not sure if Istvan is the best person to explain this to TC39. |
| 02:29 | <ryzokuken> | that veto power is a special power given to LF over other members |
| 02:29 | <Aki> | TC39 is a special snowflake in SDO world, because we work so openly |
| 02:29 | <Aki> | that is what LF is interested in |
| 02:30 | <Aki> | our open standards work |
| 02:30 | <ryzokuken> | the idea is just to make sure that we keep the IPR policy open |
| 02:31 | <shu> | i am not so much concerned with the intentions that are expressed but with the material implications |
| 02:31 | <devsnek> | they want the power to veto future changes that ecma may want to make? |
| 02:31 | <shu> | that's my reading |
| 02:32 | <littledan> | I'll just give my comments here in Matrix |
| 02:32 | <ryzokuken> | in the exact words, "for decisions that require a supermajority" so mostly just changes to the IPR policy and the bylaws IIUC |
| 02:33 | <ptomato> | this isn't public, as far as I understand - could a mod redact the discussion about it in TDZ? |
| 02:33 | <littledan> | I really strongly support this partnership. The Linux Foundation can help bring lots of extra interesting work to Ecma, and they can bring technical and administrative support to TC39. We've lacked all of those from Ecma so far. |
| 02:34 | <littledan> | this isn't public, as far as I understand - could a mod redact the discussion about it in TDZ? |
| 02:34 | <ryzokuken> | also the logs are public |
| 02:34 | <ryzokuken> | also I think the agenda is public? |
| 02:35 | <devsnek> | istvan disclosed the topic and his slides on github at least |
| 02:35 | <ptomato> | oh, ok |
| 02:35 | <Aki> | yeah i don't think it's a secret. there's a difference between "not public" and "private" i guess |
| 02:38 | <littledan> | I'm not sure that what Waldemar is saying is correct. |
| 02:39 | <littledan> | anyway the GA doesn't play any role in our actual working mode going towards Stage 4 |
| 02:40 | <ljharb> | under what circumstances would the GA not rubberstamp our standard every year anyways? |
| 02:40 | <littledan> | yeah, exactly |
| 02:40 | <shu> | i still do not understand why they want a veto |
| 02:40 | <littledan> | I think we should just expect to see a better level of support once the LF is involved, without any real upsets or surprises |
| 02:41 | <Aki> | they don't want us to turn into every other SDO |
| 02:41 | <ljharb> | shu: my reading is that they want to prevent the ecma GA from making disruptive changes in some scary possible future |
| 02:41 | <littledan> | shu: The idea was to bring LF people here for this topic. I guess we had some kind of coordination error. Hopefully we can ask them these questions tomorrow. |
| 02:41 | <shu> | so join as a voting member, and vote? |
| 02:41 | <shu> | like what is the manifest problem in the current process that requires a veto to safeguard? |
| 02:42 | <littledan> | Isabelle says that about literally every document btw (that they are not final and they are incomplete) |
| 02:42 | <ryzokuken> | like what is the manifest problem in the current process that requires a veto to safeguard? |
| 02:42 | <littledan> | well, let's hear from LF before drawing a conclusion, they must have had a reason |
| 02:43 | <ryzokuken> | but that has nothing to do with the engagement in general. These implementation details can be ironed out. |
| 02:45 | <littledan> | I think Istvan's analysis is unfair and not well-informed. |
| 02:46 | <Michael Ficarra> | FYI I did a side-by-side of the video call and the notes document, and it makes jumping in and out of note-taking SO much easier |
| 02:46 | <Michael Ficarra> | I highly recommend it for anyone who is note-taking-curious |
| 02:47 | <Michael Ficarra> | (it's possible everyone already does this and I am just late to the party) |
| 02:47 | <ljharb> | can someone advance tcq? |
| 02:47 | <waldemar> | littledan's criticism is not helpful here. Istvan is one of the most informed here. |
| 02:47 | <Aki> | working on it |
| 02:48 | <devsnek> | tcq does not match presentation |
| 02:49 | <Aki> | yes it does |
| 02:49 | <littledan> | I'm a bit baffled about how Istvan said he didn't understand the motivation for the partnership, when this was very clearly explained in the GA slides. |
| 02:51 | <ryzokuken> | This discussion is not very fruitful without someone from LF or Jochen here to correct our misunderstandings. Let's try to get them to attend on a later slot and then return to this? |
| 02:51 | <waldemar> | littledan: No it wasn't. In fact, I've heard a lot of false claims made about the motivation. |
| 02:51 | <waldemar> | Blatantly false. |
| 02:52 | <shu> | littledan: to me, the issue is there is a jarring divide between what's said, e.g. "we'll give you more resources, tooling, support, and it'll be great" and what's formally proposed (by-law changes, veto powers), and i'd rather go by what is formally proposed |
| 02:52 | <littledan> | For Ecma, the LF can bring more work items and technical/organizational services. For the LF, Ecma can give it this additional service (standardization) for its various projects. |
| 02:52 | <littledan> | (that's the motivation, not the bylaws details, which we'll just have to have LF people here to explain) |
| 02:53 | <littledan> | I imagine that the LF wants to make sure that Ecma doesn't become closed, that it retains its current openness |
| 02:54 | <bterlson> | maybe missing something obvious: why keep the note about the extends clause? Without designing to extend via subclassing, the fact that an identifier can appear in extends doesn't seem very interesting? |
| 02:56 | <shu> | bterlson: i think the "it won't throw" part seems reasonable to call out |
| 02:56 | <waldemar> | What the LF said during the GA is that they're doing this because they wanted an office in Switzerland. |
| 02:56 | <shu> | coming from other OO languages, one might think some built-ins are final |
| 02:56 | <HE Shi-Jun> | Actually nothing is final in ES? |
| 02:56 | <bterlson> | I suppose |
| 02:57 | <devsnek> | if its a living spec that means it can die |
| 02:58 | <HE Shi-Jun> | As allen explained, this term is used to denote that if you extend it, it keep some invariant. If we remove that, should we add some other text to keep such information? |
| 02:59 | <shu> | HE Shi-Jun: we are, we're replacing it in the PR with just "it works with the extends clause" or something to that effect, too lazy to copy out the exact language right now |
| 02:59 | <HE Shi-Jun> | Great! Thank you! |
| 03:35 | <Richard Gibson> | I don't even see value in that... isn't it true of every constructor that it works with extends? |
| 03:36 | <ryzokuken> | no, some specifically don't. |
| 03:37 | <ryzokuken> | Symbol doesn't, IIUC |
| 03:39 | <ryzokuken> | hm, I might be wrong, it's not triggering an error but IIRC it's not designed to be subclassable, right? |
| 03:41 | <bakkot> | Richard Gibson: yes, and we will have that text on every constructor |
| 03:42 | <bakkot> | we have a fair bit of boilerplate |
| 03:42 | <bakkot> | seems fine |
| 03:42 | <bakkot> | (to be clear we currently have that text on every constructor, and are not proposing to remove it) |
| 03:45 | <ljharb> | hm, I might be wrong, it's not triggering an error but IIRC it's not designed to be subclassable, right? new class extends Symbol {} does throw tho. |
| 03:46 | <ryzokuken> | ah, I was just doing class MySymbol extends Symbol { } |
| 03:46 | <ryzokuken> | trying to construct it does fail |
| 03:46 | <ryzokuken> | Uncaught TypeError: Symbol is not a constructor |
| 03:46 | <bterlson> | Does Symbol have the note since it can appear in an extends clause without throwing? 😁 |
| 03:47 | <devsnek> | may be used as the value of an extends clause of a class definition but a super call to it will cause an exception. |
| 03:47 | <devsnek> | we are nothing if not thorough |
| 03:50 | <Richard Gibson> | I'm just saying I would also support further removal of the "may be used as the value of an extends clause of a class definition" text as well. It's not misleading in the same way as the "designed to be subclassable" text, it's just of dubious value. |
| 03:56 | <ljharb> | i think it's of value in the places where it makes sense, but the primitive constructors are not those places |
| 04:05 | <shu> | how fascinating |
| 04:06 | <bakkot> | non-contiguous weekends, fun |
| 04:06 | <bakkot> | something to add to "falsehoods programmers believe about time" |
| 04:07 | <shu> | indeed |
| 04:09 | <bakkot> | can someone put the conclusion in the notes |
| 04:09 | <bakkot> | I couldn't actually follow what the ask was |
| 04:11 | <ryzokuken> | bakkot: consensus on excluding "search" and "standard" from collations getter |
| 04:11 | <bakkot> | please put in notes |
| 04:18 | <ryzokuken> | please put in notes |
| 04:46 | <ryzokuken> | something to add to "falsehoods programmers believe about time" |
| 04:52 | <bakkot> | not clear to me that the thing Shane mentions would address Yulia's concern at all |
| 04:53 | <shu> | i have trouble understanding the specificity of Yulia's concern |
| 04:55 | <shu> | oh i see, iain is explaining, this is helpful |
| 04:56 | <ljharb> | seems to me like the hazard already exists tho, if any browser actually did the thing they're worried about? |
| 04:57 | <ryzokuken> | yeah, we need a normative PR to ECMA-402 to address the root cause |
| 04:59 | <ryzokuken> | what's needed is a centralized source-of-truth for these supported values that the different constructors draw from/check against |
| 05:01 | <littledan> | hello, yes, I'm around to chat about HTML integration if needed. You can find the PR at https://github.com/whatwg/html/pull/5339 |
| 05:05 | <bakkot> | Did I understand correctly that the set of names to be made available in new realms is supposed to be resolved during stage 3? |
| 05:05 | <bakkot> | because that really does not seem like something which is appropriate to stage 3 to me |
| 05:06 | <littledan> | the set of things that HTML will expose. Each environment can choose its own. |
| 05:07 | <littledan> | the JS builtins are all available (unless an environment goes and deletes them) |
| 05:07 | <leobalter> | MM has this answer always ready |
| 05:07 | <leobalter> | I love to hear this again |
| 05:08 | <littledan> | arguably, the HTML folks could be the ones to propose the exact list. We've done some research into possible dividing lines and how they would work out, but we haven't driven to the point of consensus on any particular one yet. |
| 05:09 | <bakkot> | I cannot imagine WHATWG coming up with any answer other than "literally all of them", from my experience with WHATWG |
| 05:09 | <littledan> | well, that's not where the conversation is with WHATWG right now. I think everyone agrees that, like workers, it is a place where only some of the things should be exposed |
| 05:09 | <littledan> | so the idea is that WebIDL would have notation like [Exposed=Realm] to opt in to interfaces showing up in realms |
| 05:10 | <shu> | i have the opposite intuition, especially with prior art with restricted global scopes like workers as dan says |
| 05:10 | <leobalter> | bakkot: I can answer that if you bring it to the queue, but it's hard for me to multitask right now |
| 05:10 | <bakkot> | ugh sorry I've been trying to take notes |
| 05:10 | <littledan> | The specification on the JS side imposes restrictions on the capabilities that globals in realms can expose |
| 05:10 | <bakkot> | POO: more note takers |
| 05:10 | <bakkot> | can someone TCQ that |
| 05:12 | <bakkot> | i have the opposite intuition, especially with prior art with restricted global scopes like workers as dan says |
| 05:15 | <shu> | what's the phrase jack is saying? |
| 05:15 | <shu> | i heard "hyper graph membrane"? |
| 05:16 | <leobalter> | bakkot: one thing from the ES draft: the realms API require the globalThis to be an ordinary object and all the properties must be configurable |
| 05:16 | <devsnek> | i'm still really salty about not even having opt in object sharing |
| 05:17 | <shu> | i... cannot follow this conversation |
| 05:19 | <ljharb> | it's a very complicated realm (sorry sorry sorry) |
| 05:20 | <devsnek> | i don't know where the queue is |
| 05:20 | <ryzokuken> | the queue is up-to-date |
| 05:20 | <ljharb> | tcq link is in the reflector (https://github.com/tc39/Reflector/issues/380) |
| 05:20 | <devsnek> | i mean on tcq |
| 05:20 | <devsnek> | jack works is speaking rn? |
| 05:21 | <devsnek> | yea sorry for the confusion, i already had tcq open |
| 05:21 | <ryzokuken> | yeah but they skipped their own item 😅 |
| 05:21 | <devsnek> | was just trying to figure out who was speaking |
| 05:23 | <Jack Works> | i heard "hyper graph membrane"? |
| 05:25 | <shu> | thanks |
| 05:26 | <Jack Works> | it's a very complicated realm (sorry sorry sorry) |
| 05:27 | <Jack Works> | it's a bit like what Firefox implemented in web extension (X-Ray vision to C++ objects) |
| 05:27 | <ljharb> | Jack Works: apologies, i was making a pun about the overarching topic of membranes/realms being complicated :-) should have done it in TDZ |
| 05:35 | <littledan> | As Mark said, "The callable boundary meets the use cases that most of us have in mind"--This is what I was trying to get at. It's iterating to meet the previously articulated goals. |
| 05:35 | <ljharb> | "most of us" may apply to the champion group, but does not necessarily apply to the entire committee, nor to the users who have been hoping for (object-sharing) Realms for half a decade |
| 05:35 | <littledan> | (sorry for interrupting; Leo is making a good point) |
| 05:38 | <Jack Works> | it looks like different targets are conflicting |
| 05:39 | <Jack Works> | virtualization wants clean realm, security wants absolute boundary |
| 05:39 | <littledan> | I don't see a conflict, they're just different feature requests |
| 05:39 | <Jack Works> | and other cases want direct object sharing and vendor-modified realm |
| 05:40 | <littledan> | This Realms proposal does not make the Node.js vm module obsolete. That doesn't make it unmotivated. |
| 05:40 | <Jack Works> | yeah but vm module only available on Node |
| 05:41 | <Jack Works> | using iframe is awkward cause there are unremovable things like location |
| 05:43 | <shu> | agree with dan here, the shape of the counterargument from jordan and gus seems to be, "the old proposal solved what i wanted to do as well, and this new proposal reduced the scope, so i'd rather this not move forward because it'd preclude what i want with direct object access" |
| 05:43 | <devsnek> | i cannot understand how someone could block having an option |
| 05:43 | <shu> | but this proposal moving forward doesn't remove the objection with direct object access |
| 05:43 | <devsnek> | like what concern drives that |
| 05:43 | <shu> | devsnek: mark explained it |
| 05:44 | <devsnek> | mark explained why unsafeObjectSharing option is bad? i must've missed it |
| 05:44 | <Jack Works> | +1, I've proposed to give developers choices but not accepted by the champion |
| 05:44 | <shu> | that the value for building in an isolation into the platform as a safeguard against a footgun is that it's not escapable |
| 05:45 | <devsnek> | escapable by who |
| 05:45 | <shu> | if you make it escapable, we shouldn't really take the time and effort to build the isolation into the platform |
| 05:45 | <shu> | by the developer |
| 05:45 | <littledan> | Making a new Realm is just a very bad way to get a fresh copy of built-in functions. It's not going to be very easy to optimize to make way too many Realms, and it will create things in the wrong Realm. |
| 05:45 | <devsnek> | is the developer gpt3? |
| 05:45 | <shu> | what? |
| 05:45 | <Jack Works> | We can made isolation by default but leave a escape path |
| 05:45 | <devsnek> | who is accidentally typing out allowUnsafeObjects: true in their code |
| 05:45 | <shu> | not accidentally |
| 05:45 | <shu> | consciously choosing it without understanding the consequences |
| 05:46 | <shu> | or being overconfident in their userland isolation library |
| 05:46 | <littledan> | Sorry, is arguing points in writing not sufficiently open? Didn't we have a big thread about this all? |
| 05:46 | <devsnek> | that seems pretty condescending :/ |
| 05:46 | <devsnek> | littledan it may have been |
| 05:46 | <shu> | sorry, something i said is condescending? |
| 05:46 | <Jack Works> | Sorry, is arguing points in writing not sufficiently open? Didn't we have a big thread about this all? |
| 05:47 | <leobalter> | As Greg is next in the queue: Greg Whitworth (GCW) (cc bakkot ) |
| 05:47 | <devsnek> | assuming that developers can't make informed decisions and tc39 needs to hold their hand through using realms "safely" |
| 05:47 | <ryzokuken> | what about malicious developers running scripts on a secure platform though? |
| 05:48 | <shu> | it's not pure assumption, this was informed by enthusiasm from some Google internal folks as well as others on Twitter who were excited to use the previous Realm proposal to run untrusted code |
| 05:48 | <ryzokuken> | or running untrusted scripts? |
| 05:48 | <shu> | thinking it was a lightweight sandbox |
| 05:48 | <devsnek> | if you leave the "thisBreaksTheSandboxAllowObjects" option unspecified it apparently is a lightweight sandbox |
| 05:49 | <devsnek> | i would be fine with the option being called that |
| 05:49 | <Jack Works> | anyone I'm natural on the isolated version, the things I worried about is how to pass ArrayBuffer |
| 05:49 | <devsnek> | what about malicious developers running scripts on a secure platform though? |
| 05:53 | <Jack Works> | (A random footgun.png) |
| 05:53 | <ryzokuken> | the malicious code is inside but direct object access allows them to access globals from the outside |
| 05:53 | <devsnek> | don't enable the option for malicious code |
| 05:56 | <ryzokuken> | bakkot: ping |
| 05:56 | <bakkot> | sorry, another 500 |
| 05:56 | <bakkot> | restarted |
| 05:56 | <Josh Blaney> | it's back!! |
| 05:56 | <Josh Blaney> | thanks! |
| 05:56 | <Josh Blaney> | I didn't have TCQ open, sorry I jumped right in |
| 05:57 | <littledan> | given the really short schedule, maybe we can have an overflow item (of an hour or two?) |
| 05:57 | <littledan> | I didn't have TCQ open, sorry I jumped right in |
| 05:57 | <bakkot> | (it's actually the google docs API which is 500'ing, not as I previously claimed the google speech API) |
| 05:58 | <ryzokuken> | given the really short schedule, maybe we can have an overflow item (of an hour or two?) |
| 05:59 | <HE Shi-Jun> | Because this is a very complicated topic, could we have a summary about the argument if we decide to continute the topic tommorow? |
| 06:05 | <leobalter> | HE Shi-Jun: this is related to the slide 6 https://docs.google.com/presentation/d/1MgrUnQH25gDVosKnH10n9n9msvrLkdaHI0taQgOWRcs/edit#slide=id.ge435a9058a_0_563 but I'd leave the summarization open |
| 06:11 | <HE Shi-Jun> | Thank you. |
| 13:06 | <Jamie Kyle> | It looks like the sign-in form on the meeting logistics issue is pointing to the May meeting https://github.com/tc39/Reflector/issues/380 |
| 13:07 | <Jamie Kyle> | Does anyone have the actual link to join the meeting? |
| 13:42 | <littledan> | It's the same as the one that form gives you |