00:19:27  * jwaldenquit (Ping timeout: 240 seconds)
00:19:56  * jwaldenjoined
00:28:53  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
00:40:11  <bterlson>https://sites.google.com/a/chromium.org/dev/Home/chromium-security/ssca chrome disabling SAB :(
00:56:42  * bradleymeckquit (Quit: bradleymeck)
00:57:58  <aklein>bterlson: Firefox too: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
01:05:29  <cloudshu>unsurprising
01:06:02  <cloudshu>i do share the :( though
01:07:13  <ljharb>i can't tell from either message if they're disabling SAB because it's causing the problem, or because they're just scared it might be
01:08:10  <cloudshu>from luke's wording it seems a POC exists
01:08:37  <cloudshu>JS cache timing sidechannel attacks already exist afaik
01:09:14  <ljharb>so it's just another way to do something that's already possible
01:09:15  <ljharb>?
01:09:22  <cloudshu>but spectre made weaponizing that a much realer thing
01:09:29  <cloudshu>well, side channel attacks have existed
01:10:08  <cloudshu>but spectre and meltdown demonstrate new ways of using it that are immediately super scary
01:10:22  <cloudshu>e.g. reading kernel memory, escaping sandboxes
01:10:40  <cloudshu>whereas before, i guess, they existed but people were like maybe it's fine
01:11:49  <cloudshu>that's how i interpret luke's "instead of just hiding the leak by disabling timers"
01:20:18  <cloudshu>aklein: https://twitter.com/filpizlo/status/948721275085635584
01:21:23  <aklein>cloudshu: ha
01:21:36  <cloudshu>i can totally picture him saying it too
01:34:12  * AtumTquit (Remote host closed the connection)
02:34:09  * jwaldenjoined
04:43:52  * jwaldenquit (Ping timeout: 265 seconds)
04:45:27  * bpaytonjoined
04:45:34  * jwaldenjoined
05:08:50  * jmdyckquit (Remote host closed the connection)
05:16:52  * jwaldenquit (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
06:41:42  * bpaytonquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
06:43:13  * bpaytonjoined
07:55:23  * bpaytonquit (Quit: Textual IRC Client: www.textualapp.com)
10:53:33  <serbang>what does `The resolution of performance.now() will be reduced to 20µs.` mean?
11:25:09  * mylesborinsquit (Quit: farewell for now)
11:25:39  * mylesborinsjoined
11:29:57  * not-an-aardvarkquit (Quit: Connection closed for inactivity)
12:07:27  <littledan>:(
12:08:26  <littledan>A few people have been asking me about it, so I've been thinking more about lexically scoped friends and private fields in object literals. I wrote this gist; what do you think? https://gist.github.com/littledan/d3030534cf96075d47228955828f932e
12:09:19  <littledan>in particular, there are two alternatives: keep the current private field syntax, and add two contextual keywords for defining and using lexically scoped private names that aren't from the class, or add one keyword and require it in all new places where a private name is created, including in private class field and method declarations
12:10:49  <littledan>the two-keyword variant is compatible with the current Stage 3 proposal, and might make the common case more terse, but the one-keyword variant could be thought to have a simpler mental model and make use with object literals more terse
12:34:18  * bradleymeckjoined
12:53:02  * jmdyckjoined
13:16:26  * howdoiquit (Quit: Connection closed for inactivity)
13:38:29  * H|f|ishchanged nick to DDoB2
13:38:44  * DDoB2changed nick to H|f|sh
13:51:45  * bradleymeckquit (Quit: bradleymeck)
14:21:21  * bradleymeckjoined
14:49:01  <littledan>there's a third possibility, to give objects the default behavior of "it's defined outside" and classes the default behavior of "it's defined here", with these two keywords to control choosing the other one
14:54:01  * bradleymeckquit (Quit: bradleymeck)
15:11:33  * bradleymeckjoined
15:12:15  * bradleymeckquit (Client Quit)
16:00:25  <littledan>never mind about the idea for going back to `private #x`; yehuda's original arguments that `@protected private #x` and `@reader private #x` are weird still apply
16:21:18  * AtumTjoined
16:59:35  * srl295quit (Quit: Connection closed for inactivity)
17:30:20  * bradleymeckjoined
17:57:56  * bradleymeckquit (Quit: bradleymeck)
19:29:07  <cloudshu>serbang: it means performance.now() was made into a more coarse-grained timer
20:10:16  * jwaldenjoined
20:55:28  * bradleymeckjoined
21:31:19  * Jayfluxjoined
21:32:04  * not-an-aardvarkjoined
21:48:02  <Bakkot>littledan: this is something I wouldn't want to worry too much about for a couple of years after private state and decorators land, to get a better feel for what the actual JS usecases are. best not to rush. with that said: I like the 'introduce new keywords for using an external definition' option; I'd personally probably go with `private` for declaration and `outer` for use.
21:59:49  <littledan>Bakkot: I like those names
22:00:14  <littledan>Do you think it'd be premature to introduce these at Stage 0, just so the committee can have them in mind as reviewing the private fields proposals?
22:00:57  <littledan>Another decision-point is whether we would want to make `outer` implicit in object literals
22:01:27  <Bakkot>Mm... if the point is *just* so the committee can have them in mind when reviewing those proposals, I would just mention them as possible future work as part of those proposals.
22:02:23  <Bakkot>Right; I would not want to, since we definitely don't want to for classes.
22:03:01  <littledan>it'd lead to a place where, when seeing a LHS bare #x, you have to think "is this a class or object" to understand whether it's a declaration or not
22:03:10  <Bakkot>right.
22:03:17  <littledan>but, maybe that'd be justified by overall terseness, I dunno
22:03:28  <Bakkot>(and because `return { #x: 0, get x(){ return this.#x++; } }` is a reasonable line of code not requiring any outer declaration, so it's not the case that you'd *always* want object literals to refer to an outer name.)
22:03:44  <littledan>we could permit that too
22:04:20  <littledan>generally, there's a hazard where you accidentally shadow outer private names with inner ones, since it's so easy to. I think linters would be good to enforce, no redeclaring a private name in a file, for that reason
22:04:21  <Bakkot>I would be deeply uncomfortable if you'd be required to look outside the current context to determine if `#x: 0` is a declaration or reference
22:04:29  <littledan>s/redeclaring/shadowing/
22:08:15  <littledan>Bakkot: Well, it'd be #x: 0 vs #x = 0, but that's not a very clear indicator
22:08:33  <Bakkot>er
22:08:39  <littledan>or, #x; vs #x,
22:09:47  <Bakkot>I'm not talking about objects vs classes
22:10:01  <Bakkot>I am talking about `outer` being implicit in object literals.
22:10:42  <Bakkot>I would not want it to be, since I want to be able to write `return { #x: 0, get x(){ return this.#x++; } }` and have that be a declaration, always, regardless of whether there is a `private #x` somewhere in scope.
22:13:57  <littledan>yes, I definitely wasn't suggesting that the definition-ness depends on what's defined in an outer scope
22:14:09  <littledan>I was just suggesting that object literals would have no way to create a new private name declaration
22:14:42  <littledan>anyway, you'd want to do some more work to thread this through import and export private names in the #foo namespace, and also create a new package private concept, to really make this all hit home
22:15:05  <littledan>which would be a lot
22:15:18  <Bakkot>Ah. And yeah, I'm saying I'd prefer that not be the case, since it seems to me there are plenty of places I might want them to, just as I might want that for classes.
22:15:34  <Bakkot>And for symmetry.
22:16:05  <Bakkot>Aaaaanway, yes, you're right that this is speculating way far down a path to a feature which would need a great deal more exploration before we got to that sort of decision.
22:17:31  <Bakkot>I don't think the committee would accept anything which required changes to the current private field syntax or semantics for classes, so I don't think it needs to be explored that fully before class fields go forward.
22:18:10  <littledan>OK. The complexity here and lack of people clamoring for private fields in object literals was why I was working more on the decorator integration than this path
22:18:24  <Bakkot>:thumbsup:
22:18:52  <littledan>I mean, part of the reason for doing this investigation is to make sure that this proposal isn't cutting off future paths for private fields in object literals. Anyway, if this syntax (the first option) looks good to you and a few other people, mission accomplished
22:22:24  <Bakkot>IMO, private fields for classes are a much bigger and more important feature than private fields for objects, and I think we've explored the syntactic space for private fields for classes pretty thoroughly and found the best point we're likely to get; I would not want to compromise that for the sake of private fields in object literals. But it's nice that it seems likely not to come up!
22:45:34  * jwaldenquit (Ping timeout: 265 seconds)
22:51:28  * jwaldenjoined
23:01:46  <littledan>Bakkot: I'm wondering what you think of private static methods inheriting the method brand by copying the methods from the superclass
23:02:12  <littledan>is that too ad-hoc? should it be a prototype chain walk (which is what I was imagining for your fields proposal)
23:02:49  <Bakkot>Is that not the semantics we discussed yesterday?
23:03:03  <littledan>which one?
23:03:05  <Bakkot>er
23:03:30  <littledan>a "hazard" case is if you have a class hierarchy, A > B > C, and you reparent B to D before executing the class declaration of C. Then, C will have A's private static methods, but C instances will have D's instance static methods
23:03:34  <Bakkot>the one described by the readme in master as of a few yours ago, I think
23:03:37  <littledan>s/instance static/instance/
23:04:18  <Bakkot>oh, if you're just talking about reparenting: i definitely think brands and methods should be installed when the class is defined using the class in the `extends` clause and then never mutated.
23:04:22  <littledan>an alternative semantic would be, when executing the class declaration of C, walk the prototype chain of B until you get to null, copying the method *declarations* that you see along the way
23:04:24  <Bakkot>reparenting should not affect that.
23:04:43  <littledan>well, there's multiple times for reparenting. I'm not talking about reparenting after the class declaration executes--totally with you on that
23:04:55  <littledan>I'm talking about re-grandparenting before the class declaration executes
23:05:26  <littledan>the semantics of copying the immutable/accessor *fields* of the parent class would not take re-grandparent that occurs before the class declaration executes into account
23:05:58  <littledan>the other possibility would be to do a proto chain walk, to get at the *declarations* that are "live" at the time that the class declaration executes
23:07:10  <Bakkot>Ah, right.
23:08:01  <Bakkot>Ehhh - I am in favor of the simple thing, which is to use the methods that are present on the superclass when the subclass is defined, even if those methods don't make sense given the superclass's current heritage.
23:08:05  <littledan>https://www.irccloud.com/pastebin/03Oq1hAh/
23:08:38  <littledan>good, I like that variant too
23:08:44  <littledan>here, we'd be saying, no TypeError
23:09:07  <Bakkot>Right.
23:09:27  <littledan>and, for completeness, if we have `class D { static #baz() { } static baz() { this.#baz() } }; D.baz.call(C)`, that would be a TypeError
23:09:42  <Bakkot>Yup.
23:09:47  <ljharb>imo it's totally fine if reparenting makes things confusing; reparenting is confusing.
23:09:54  <Bakkot>Also yup.
23:10:06  <Bakkot>Especially in the presence of private fields.
23:10:52  <littledan>OTOH private instance fields ,by design, *do* handle reparenting decently
23:11:26  <littledan>this was one of the things I didn't like about the previous private fields design, where reparenting and super return didn't work
23:11:46  <littledan>I think this stuff is more important for instances, where super return is actually a thing that's used by design (e.g., in custom elements)
23:12:17  <Bakkot>I actually think this *is* decent. It has a very simple explanation, which is that private methods are copied to a class from its parent when it is defined, and are thereafter immutable.
23:13:26  <littledan>wait, that's not our current private methods semantics
23:13:34  <Bakkot>sorry, private static methods
23:13:34  <littledan>private instance methods also follow any reparenting
23:13:43  <littledan>which, again, is important for custom elements
23:13:56  <Bakkot>right, on board with all that, slip of the keyboard.
23:13:59  <Bakkot>Instance fields are pretty different, in that the "reparenting" in question is not of the objects in question but of their constructors.
23:14:24  <Bakkot>If you change the prototype of an extant instance with private fields, weird things might well happen there to.
23:14:27  <Bakkot>*too.
23:15:22  <littledan>yep
23:16:01  <littledan>OK, another obscure corner: I was thinking of phrasing the spec as, all non-writable and accessor private fields of the superclass constructor are copied to the subclass constructor
23:16:19  <littledan>this means, for example, if you make a @nonwritable decorator for an instance field, it'll get copied
23:16:23  <ljharb>accessors can be mutators too tho, no?
23:16:44  <littledan>no, accessors are always non-configurable (everything in private-land is non-configurable)
23:17:08  <littledan>an alternative would be to add additional tracking for which fields originated as methods and which as fields, and copy just the method ones
23:17:21  <Bakkot>ehm... I would prefer the spec be written in the way which makes the most sense for this feature on its own, and the decorator spec be applied as a patch on top of it.
23:17:25  <littledan>this is unobservable until we add decorators, but I sort of want to phrase it the right way first
23:18:29  <littledan>the private methods spec was always written so that the decorator spec doesn't need to make any changes to the private stuff internal MOP; this isn't really an essential property but I'm also maintaining the decorators spec, so...
23:19:29  <Bakkot>don't have a strong opinion either way, though. as you're the author of the spec text I'd defer to you, as long as you think it'll make sense to readers (and bterlson or whoever is editor at the time). If you do go with your original plan, a non-normative NOTE would be enough to make up for the difference I think.
23:19:53  <littledan>note that says what?
23:20:29  <littledan>I'm leaning towards going ahead and copying the nonwritable private fields to subclass constructors; I think it makes semantic sense for the same reason it makes sense to copy methods and accessors
23:20:37  <Bakkot>`NOTE: private static accessors and methods are copied to subclasses.`
23:20:51  <Bakkot>or something to that effect.
23:20:59  <Bakkot>I guess you'd want to make reference to the syntactical difference.
23:21:05  <littledan>oh, no, this is too complicated to leave to a note; I'm trying to write the spec text now
23:21:25  <Bakkot>right, I was trying to answer the "note that says what" question
23:21:33  <littledan>I could do a note for other things, like NOTE: restore the lexical scope of the private scope stuff properly (I think there's a note like that now)
23:21:55  <littledan>sorry, I don't understand what you meant by " If you do go with your original plan, a non-normative NOTE would be enough to make up for the difference I think."
23:21:58  <littledan>which original plan?
23:22:00  <Bakkot>er
23:22:07  <Bakkot>"I'm leaning towards going ahead and copying the nonwritable private fields to subclass constructors"
23:22:44  <Bakkot>I think that, if you do this, there should be a NOTE in the final spec text which points out that "nonwritable private fields" is equivalent to syntactically declared static private methods and accesors.
23:22:59  <littledan>oh, yeah, good point--this is pretty non-obvious
23:23:14  <littledan>OK, thanks for all your help here
23:23:15  <Bakkot>And then take that note out when decorators land, or amend it to say that this is only true if decorators haven't messed with things.
23:23:28  <Bakkot>(assuming decorators have the relevant powers.)
23:23:47  <littledan>decorators can create non-writable fields in the current draft spec
23:23:57  <littledan>but, I don't see why anyone would want to do that
23:24:13  <littledan>I mean, they'd be frozen to the value of their initializer
23:24:37  <Bakkot>To the value their initializer returns, or its thunk?
23:24:44  <littledan>the first one
23:24:50  <Bakkot>Beause I write `private static final foo` in Java all the time.
23:25:27  <littledan>`@nonwritable static #foo = 1;` huh not so bad
23:25:42  <littledan>but, maybe better `const foo = 1` outside the class
23:26:20  <littledan>anyway seems like it wouldn't hurt to have access in subclasses there
23:26:28  <littledan>and I don't see a reason to exclude it
23:29:28  <Bakkot>I have no strong opinion either way, and am not the target audience for decorators in any case. Something to discuss there, possibly. (Where "discuss" means "pick a semantics and explain what it is going to be, and then if people offer objections take that into account", I guess.)
23:32:21  <littledan>yeah, sounds like a plan
23:32:41  <littledan>sadly the set of people who have strong opinions about decorators differs a bit from the set of people who have strong opinions about private fields and methods
23:33:01  <littledan>or, happily?