00:02:09  <bterlson>Given that we probably can't bring SAB back until CPUs are fixed, should we remove SAB from the spec for 2018? Seems bad to keep a feature that can't be implemented on modern CPUs securely?
00:41:18  <littledan>maybe we can just add a note?
00:41:31  <littledan>it sounded like there were some possible software mitigations
00:42:00  <bterlson>I am not an expert but from what I can tell the software mitigations may not be 100% foolproof
00:42:12  <littledan>move SAB to Annex B?
00:42:24  <bterlson>why? it's not needed for web compat
00:42:27  <littledan>or move it to ECMA 402, so it's actually optional
00:42:32  <littledan>on the web even
00:42:48  <littledan>oh, then implementations would have to choose between shipping Intl with SAB and not shipping either!
00:42:56  <bterlson>we can make it normative optional wherever we put it
00:43:08  <littledan>sorry, this is just a bad joke
00:43:29  <bterlson>ahhh ok sorry
00:43:50  <littledan>why not leave it required, as an (extremely gentle) push to get everyone to fix it so it can get re-shipped, and just add a note saying, "we understand if you can't ship this now due to those issues"
00:44:24  <littledan>they'll be temporarily out of conformance due to the bug
00:44:28  <bterlson>one possible reason: requiring standards process to bring the feature back is a forcing function to discuss its broader security impliciations?
00:44:57  <littledan>tbh I'm not sure if we're the body to rule on that
00:45:26  <littledan>also a lot of these discussions happen in private
00:46:44  <littledan>Bakkot: Re the conversation above: A really strange consequence of the copying semantics is, if a superclass "gets" the private instance methods of another class (e.g., the super return trick), then the subclass will now also get them.
00:46:56  <littledan>Bakkot: But, I still don't think this is worth changing the semantics for
00:47:04  <littledan>I mean, I think those semantic consequences are OK
00:48:19  <littledan>bterlson: Anyway if you want to remove it I'm not really opposed to it
00:56:43  * Jayfluxquit (Quit: Leaving)
00:59:26  <littledan>Bakkot: The spec came out really short, it's just this: https://tc39.github.io/proposal-static-class-features/#initialize-class-elements
00:59:41  <littledan>or sorry, the relevant part is this: https://tc39.github.io/proposal-static-class-features/#copy-immutable-private-elements
01:00:44  <bterlson>littledan: I'm just exploring options at this point :) I don't really have an opinion
01:04:22  <Bakkot>littledan: seems fine, though gonna be a fun test262 case to write
01:09:55  <Bakkot>You can run into it even without the super return trick: `class Base extends Function { #priv(){} pub(){ this.#priv(); } }; class Derived extends new Base {}; Derived.pub(); // succeeds`
01:14:08  <littledan>oh right of course
01:14:27  <littledan>well, that seems... natural?
01:18:50  <Bakkot>That code kind of damages the static/instance boundary, but if you think of it as "private methods invocable with the base class as a receiver are invocable with the derived class as a receiver", yes, it all checks out.
01:44:19  <ljharb>Annex M, for Meltdown
01:44:34  <ljharb>or Annex I, for Insecure
02:17:11  * jwaldenquit (Ping timeout: 240 seconds)
02:21:47  * jwaldenjoined
02:27:39  * jwaldenquit (Quit: brb)
02:51:37  <Domenic>littledan: Bakkot: I feel like this copying semantic/spec mechanic is more complicated than a branding-based one. I would have thought that when you call a private static method, it checks if the thisArg either has the right brand, or has something in its __proto__ chain with the right brand. This allows reparenting, I guess.
02:52:53  <Domenic>SAB is probably sticking around in Node from what I understand. Not sure how that weighs on the in-the-spec question.
02:59:02  <bradleymeck>Domenic: do we need to kick it out for now? it isn't on by default in Node@8
02:59:38  <Domenic>bradleymeck: I don't think so; Node already has access to your system
02:59:45  <Domenic>Consult your local V8 team for more definitive answers.
03:23:46  * jwaldenjoined
03:34:09  * AtumTquit (Remote host closed the connection)
03:42:16  * ahnheejongpart ("WeeChat 1.6")
04:07:35  <Bakkot>Domenic: the copying semantics are equivalent to putting the brand on the subclass when the subclass is defined, I think
04:08:23  <Bakkot>this avoids doing prototype lookups when the field is used, which is I think more consistent with how private fields work in general
05:07:46  * jmdyckquit (Quit: Leaving.)
05:10:55  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
06:33:09  * tkorejoined
08:18:21  <littledan>Domenic: What do you think the semantics should be for which brands you get? The new draft answers this by copying the set of brands from the parent class
08:20:22  <littledan>Domenic: There are multiple ways we could implement the brand check. It could be done when you read the method from the object, when you call it, or both
08:20:46  <littledan>On this slide from the September 2017 TC39 meeting, I presented to the committee the semantics that the check happens when you read the method from the object: https://docs.google.com/presentation/d/1aI89Jgl7CdtKV6D5-ydieUn_-kgRqAD2X8gGzh62xzc/edit#slide=id.g26a2221655_0_106
08:21:34  <littledan>These semantics were chosen based on discussion at https://github.com/tc39/proposal-private-methods/issues/1
08:23:14  <littledan>Domenic: Anyway, we could decide to, instead, do a proto chain walk when something is subclassed, and copy all of the declarations, as I was describing above. That would handle reparenting, as long as the reparenting happens before the subclassing happens. I don't know if that case is worth doing a whole new proto chain walk for
08:24:53  <littledan>Domenic: Something I'm trying to avoid is having a call to a private method trigger anything observable outside the class body (unless the private method does something observable in its body). Going up the proto chain when the method is actually called (as opposed to when subclassing happens) would be interceptible by proxies.
08:27:00  <littledan>backpocket alternative: Make all private method calls just a funny lexically scoped thing with no checking ever
10:53:16  * Draggorquit (Ping timeout: 272 seconds)
10:53:58  * Draggorjoined
11:25:10  * mylesborinsquit (Quit: farewell for now)
11:25:41  * mylesborinsjoined
12:01:46  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
12:37:14  * jmdyckjoined
13:46:50  * isHavvyjoined
13:49:52  * Havvyquit (Ping timeout: 248 seconds)
13:51:58  * bradleymeckquit (Quit: bradleymeck)
14:08:44  * gibson042quit (Ping timeout: 265 seconds)
14:10:34  * AtumTjoined
14:17:33  * bradleymeckjoined
15:05:51  <Domenic>littledan: based on how web platform objects work I'd expect the brand check to be done at call time with proto-walking.
15:28:11  * bradleymeckquit (Quit: bradleymeck)
15:32:35  * bradleymeckjoined
15:54:43  * bradleymeckquit (Quit: bradleymeck)
16:30:09  * bradleymeckjoined
17:43:09  <littledan>Domenic: Could you give me an example of a mismatch?
17:43:36  <littledan>instance methods work with brands getting added to objects as they are constructed; I thought that's how platform objects worked
17:45:43  <Domenic>After testing I guess I am wrong, but I am not sure why
17:45:48  <Domenic>Here is the code I thought would work (and not throw):
17:45:52  <Domenic>var obj = {}; obj.__proto__ = document.createElement('div'); Node.prototype.isSameNode.call(obj, obj);
17:46:06  <Domenic>But, it throws.
17:49:39  <littledan>anyway private methods aren't really trying to be like web platform methods; it's private fields that are sort of analogous to internal slots
17:50:30  <littledan>there's no sugar that's proposed here to do a brand check at the beginning of a method
17:55:15  * bradleymeckquit (Quit: bradleymeck)
17:57:26  <littledan>Domenic: you're talking about step 2.1.2.4 of https://heycam.github.io/webidl/#dfn-create-operation-function ? Yeah, this proposal is not attempting to match those semantics; we discussed this as a possibility (vaguely, and without the WebIDL reference). I don't know exactly what it's talking about, but I sort of expected the WebIDL constructors that say they output a platform object that implements the interface as
17:57:26  <littledan>conferring a brand on those objects, which wouldn't be inherited through prototype chains or proxies
17:59:29  <littledan>am I understanding you right ,or are you asking about something that's really more about private methods?
17:59:44  <littledan>anyway I can't find a formal definition of what it means to be a platform object that implements an interface
18:14:31  * bradleymeckjoined
18:14:33  * bradleymeckquit (Client Quit)
18:29:08  <ljharb>if it's truly a brand check, you should not be able to alter its behavior over time, even by reparenting.
18:29:20  <ljharb>iow, an array is always an array no matter what you do do it or Array or Array.prototype
18:29:32  <ljharb>similarly, reparenting should not grant, or take away, any internal slots or private fields
18:53:34  * not-an-aardvarkjoined
19:28:05  * AtumT_joined
19:30:39  * AtumTquit (Ping timeout: 248 seconds)
19:40:33  * AtumTjoined
19:41:53  * AtumT_quit (Ping timeout: 256 seconds)
20:43:01  * isHavvyquit (Read error: Connection reset by peer)
20:45:11  * jwaldenjoined
21:47:45  * Draggorquit (Read error: Connection reset by peer)
21:49:13  * Draggorjoined
22:07:05  * jmdyckquit (Ping timeout: 240 seconds)
22:07:33  * jmdyckjoined
22:42:54  * bradleymeckjoined