Agoric SES, 24 Jan 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SES-mtg: Decorators and private state

Description

Recorded at the "SES Strategy Meeting" on Jan 24, 2019. See https://github.com/erights/PNLSOWNSF/blob/master/PrivateName.js

Bradley observed that a class decorator can obtain the source of the class, rewrite it, evaluate that, and replace the original class with the result. This means there's no loss of security providing a class decorator with access to the internal PrivateName.

However, the decorator can only do an indirect eval. It cannot access the lexical scope that the class appears in. Thus, a "private" declaration that appears outside the class remains protected.

A

Are in fact recording so.

B

Previously I wanted to make the claim that decorators, including all the class elements including private names, was not problematic for security and modularity and in fact it has similar aspects to it too, even if we don't include them at all- and this is comes down to really two points that I want to bring up when we're talking about decorating a class one is one of the driving features of decorators.

B

Is the ability to entirely replace the class meaning you could replace a class which is only able to be constructed with new, with a function which you could call or apply to and get something else, so the common term, for that is a callable constructor. That is one of the driving use cases of classes. There are a few other ones or why you may want to replace the class entirely mix-ins, abstract superclass is that kind of stuff?

B

Okay, so that's one of my claims is: we will be able to replace classes entirely if we decorate them. Okay, the ability to reevaluate a class's source code has similar aspects to it, as if a decorator were able to intercept the private names of the class. That's decorating is my second claim.

A

B

A good example of this is if we had a private field ID, and we did some sort of operation with the private field inside of our class, expecting it to be encapsulated by our class yeah.

A

Argument, I have often argued from well. If you rewrote it, you could accomplish X. Therefore, there's no loss of security in enabling that entity that could have redundant rewriting to do X anymore. So one of those so.

B

That's my claim, but I want to make a further claim if we can skip ahead due to time constraints. Okay, we do have a need for a different structure of private private state where just like. If we use an evaluator, we can reevaluate the classes source text. We can't access its closure, so if it is referencing an external binding, we can't really wait it and maintain that binding.

B

Yes, that's great, so I've added an agenda item which it's very relevant, at least to this discussion about private declarations and the ability to produce a private binding, not within the class source text itself, but outside of it. Okay, so it would be only able to be gotten to via this closure mechanism. So in.

A

Terms of the the the private state at week, map ish mod in terms of the week map ish model of private state, where the private name object is, is such a collection? Does this declaration turn into approximately a constant declaration of the same name initialized to the private name, and that.

B

For the proposed form, I would say yes, but we're not going to be exposing the private name in the same way as a first class of value, at least with what I'm proposing okay.

A

Now? Okay! Okay! So that's if you have a private name outside the class. Well right now we're not decorating anything that's outside of class, so so the private name, Dec declaration, that you're proposing, is not decorated.

B

Correct and I never want it to be decorated. Well, actually, okay I can share slides there yeah, that's my helping Michael thingies yeah.

B

Can we see this I'm assuming so yeah when it's being recorded sure? That's why we're gonna present this next week? But it comes from two or three now driving questions. Well, do we want to be able to pass the keys the ways to access our private data round as a first class value, which decorators, by their very nature, need to have it as a first class value? So the question is: what can we do for cases where it doesn't need decoration?

B

The second thing is: should we have the exact appearance of accessing public data? Things like private symbols do look as if they are public access. Private fields do not look like they're public access and, lastly, what.

A

Did you make just what does looking like public access mean so.

B

When you access a field, this dot, who it is accessing the public property to when you use a computed property, it is this open bracket, foo close bracket for whatever fuels. If it's a symbol, if it's a string, it doesn't really matter if it's available under public reflection. Okay, when you access things through private fields, it's always through dot hash.

B

Roughly, what we have today, it's kind of lists. We clocks, fubar, you know yep. This does not look like public access is roughly what I'm getting okay, this private state roughly equates to a week map internal VM implementation differs, but yeah have.

A

You seen have you seen my private name class that wraps a week map that has a distinct in it versus a sign, so.

B

We're gonna get to that in a minute. Okay,.

A

B

Gonna go very fast at this because we're running short on time, but there are some problems with doing this with week: maps yep mutating state yep. The idea here is what, if we introduced a declaration private bar and we allowed people to start accessing bar on other values, other bindings within the scope and the values contained within, and so if we have this private bar, which is a way of declaring a private field, not within a class but within a scope, we can kind of start to do some interesting things.

B

We can use this within an object literal. As long as bar remains in scope. You.

A

Haven't yet you have a getter named bar as well that name that name coincidence is intentional. This.

B

Is intentional, just it's it's setting up people when they ask me questions about it. Okay,.

A

B

Hope, I don't get asked questions about it, but I might so we could assign to bar in all this, but there's a problem here where we don't want to add a private private field to something unintentionally, yeah and assignment is generally going to be unintentional right. We all don't want to reinitialize. This is bad and more important. We don't want to reinitialize a private field, yep and so classes are proposing something called class dot initialize for this problem for some web compatibility reasons and so piggybacking off the same idea.

B

This is subject to bike shedding. We could introduce a way to initialize a private field on an arbitrary value similar to how a week map can take an arbitrary object and pull it it within itself and map a value on it. Okay,.

A

B

Makes sense so far so.

A

Say it again, I think I got it so.

B

Similar to how a week map can take an object and attach a value mapping to it, I want to be able to use these private fields or private declarations. Sorry in such a way that I could attach them to a object in the same manner where it's not at instantiation time, it's not when the object is allocated, but potentially later, okay.

A

But just by having a registration operation here called initialize that is intentional, and for for the purpose of registering specifically something that has not already been ready.

B

Correct- and this is actually possible with the private fields through some really yeah, odd scenario- setups and it's in the private fields FAQ on how to make bread fields, work of proxies. Okay,.

A

I, don't you return override track right? Yes,.

B

Okay and classes, like I, said for reasons of inheritance hierarchy of the web are going to probably introduce and propose next week class dot, initialize.

B

So similar here we're separating out the initialization thing: do it multiple times you get errors, don't do it. You can't access it. So one of the questions that gets brought up whenever we bring this up is shadowing. We already have computer properties within classes, use the external scope for fields mm-hmm-hmm same same idea here. If you have a bar private field for the class foo, you know it's not computed, it accesses it within it. So you have a bar field. That's from the outer scope. You could use the same syntax in it.

B

It Maps the same for what scope is being pulled in okay.

A

So the when you use a square bracket bar as you've highlighted does that that creates the when the object literal evaluates to an object that does and initialize not an assign of this object to the bar map.

B

This isn't supposed to be an object. Literal, it's supposed to be a class. Oh.

A

B

I'm currently not proposing inline object, literal syntax for this I see I could but yeah, maybe later okay. So.

A

Now was it being a class I no longer know what you intended to me.

B

B

Plants who will have a public field outside equal to some value because it pulls bar from its external scope right.

A

Right and and and right.

B

So, in the same manner got it: okay, I.

A

Actually know that the computer that makes sense, though, because the computer properties have to be computed, a headed, okay, okay, we.

B

Could propose this? This highlighted I'm somewhat up in the air, using it with the computed.

B

The computed literal syntax seems fine to me, but I am hesitant to actually remove those computer square brackets around it. Okay,.

A

So let me so so, with this code, I can ask the question that I was thinking about with the previous code, which is the way this would evaluate. Is that the object literal would evaluate to an object, and then the pound bar private state map object would be invoked. Its initialized method would be invoked to register the instance with bar yes, okay, good and store.

B

The value 0 as its initialization good. Well then, this since bars within scope. It acts just like it does with in classes and gets the external scope right post. You can have nested scopes within classes, oh yeah, and this just starts going over more examples. Okay,.

A

So, while I have you on recorded, chat here, I'm going to find my private name thing.

B

But I do think this is absolutely necessary. Considering our decoration problem, we're storing private state within the class itself is perpetually subject to evaluators.

B

If we want to create a private storage mechanism, it needs to be done via closure. This is currently possible with some interesting nesting of classes, but this just makes it actually readable. Okay,.

A

So I am now trying to screen share. Do people see my screen and I just switched our screen to private named Jas inside a repository of mine, all right.

B

I had a quick question on the code that Bradley showed before we move on, we don't have to switch back screens or anything. Just a really quick question. um Are you thinking of blocks Cote private so could I create like like Latin koncak, an I have nested blocks cope with its own private and anything outside that block scope cannot affect the private bindings that occur within that block school correct. This also gets into something we saw in the last meeting where roll-up is trying to eliminate scopes, and we don't want that yeah.

B

We want block scopes to be available, not wasted. I love that concept long. If we like I'm, really falling in love with it. Okay,.

A

So, switching to my screen, I've got let's just let's just take a look at lines: 3 through 22 I'll expand it. This is a adequate expression of the semantics I have in mind, so this make boot. Private name makes an object like a week map and it does it by wrapping a week. Map and week map. Has these four methods: I'm. Sorry, three methods.

A

I'm sorry week, map has four methods which is has get set and delete I'm, not making use of any delete here and I'm, adding an init, that's I, think the same as the emit Bradley was just talking about and not and purposely omitting delete.

A

So, first of all, I just want to check with Bradley that this is precisely mirroring the semantics he has in mind. So in it. If the underlying week, map already has the key we throw, and otherwise we set it on the week on the underlying week, map get if it's not there, rather than returning undefined we throw, and otherwise we do a get and and for asset. If it's not there, then we throw and otherwise do asset.

B

Yes, this matches me, but it makes me need to go and reread the private fields to ensure they're in it does throw on double in it. Okay,.

A

Good, but this this is the semantics you would like correct, good good and then the bottom of this file. What I'm doing here is I'm. Just you know. The thing up here at the top of the file is doing it as an object literal, where the four methods are owned, properties, which is not the JavaScript style for it's not well. First, let's not week map like in the sense that week map is following the class pattern, not the objects as closure pattern, so I used to make boot private. It turned out.

A

That was the right first thing to do to say such that I can then do a private name in terms of that and I'm doing it. This way, because I'm writing this code, not using primitive private names, because I'm using this to explain the semantics of the private name that we would introduce so I'm trying to do it only with existing abstractions and then.

A

Like using that I go through.

A

Yeah, so so, using it, the current private name proposal I can model it in terms of the private name object. If we imagine that ampersand pound state just represents some mangling of of the the pound state variable into a lexical name that is not otherwise mentioned. You know standard trick of explaining something by expansion.

A

Is there is an assumed magical non-conflict in the expansion fresh names, so I would claim that the class at the top with the private state variable the semantics of it, is exactly reflected by the the more explicit code at the bottom of the current screen and then okay now over here, we get to.

A

At the top of the screen now is.

A

Something that I think corresponds to an explanatory expansion of the private, the external, explicit private syntax. That Bradley was just referring to.

B

I, don't understand the ampersand hash access at the bottom.

A

You know I, think I, think I'm. Looking at the wrong thing hold on.

B

So one of my things is actually I am explicitly trying to avoid reapplying into a first class value and only having it within references. So.

A

If so, when I do it with a week map right when I write now I can do private state week, mapping and if I'm, careful about initialized versus assignment I can get all of the semantics of any of these private State, with both the the main line privacy, a proposal and of your explicit private state, but the week mapped way of expressing it also lets me reify the week map.

A

So why is that not a future.

B

So, for what purposes do you want to use it to reify that.

A

ah So so the following does not answer your question, but just now that I'm, looking at the looking more carefully at the code that I wrote so there's the gimme special access method at the bottom, where I'm now not treating ampersand pound anymore as a as an assumed mangle, but rather as explicit syntax for reapplying, and so that would that would give you the private name, object itself, which is reifying. That does not, but that does of course does not answer your question.

A

A

Okay, it would let me set up what a C++ programmer might call friend relationships and in particular you would. Let me set up a situation where I could have open box test code elsewhere, where I arranged for it and only it to be able to reach in and access the private state of these objects. So.

B

I do think this is important, so I'm gonna share my screen again, because I actually have more slides. Okay sharing is caring, so there there are ways to set up shared secrets already, with some finagling of cycles in ESM.

B

There's a whole lot of trust going on when you do it when you put actual getters and setters. This is what languages which don't have friend access. Do they expose getters and setters, either by decorators annotations or like well for test builds things like that I'm actually fairly uninterested in that, because getting people to run things in the right environment was proving to be interesting. For now,.

B

So the real question is: how do we limit who can get access to things right if we had exports that only applied to other module records? This would be less problematic, saying that oh only my test files can access this and not actually prefetching those files or anything for coming today. Well in this in a similar way, we already have kind of this interesting aliasing mechanism for imports, and we can do these export statements separate from declarations. Oh I'm,.

A

Sorry, how did you limit, who can who can get at the who can share by this mechanism? I didn't understand, but.

B

This is not from this is for oh.

B

It could be export with or.

B

Really, I really do worry about exposing this as a first-class value, because you get into weird interception mechanisms where people start doing prototype based mutation in order to get a hold of something that is privileged.

A

I mean in general the the premise of object capability programming is permissions are represented as reified objects and you grant a permission, bypassing access to the object, I.

B

Would agree with that statement and I am just looking in a different direction currently, but I agree that this use case does need to be solved. Okay,.

A

So this so so by just providing reification directly you're kind of reducing it to within a module, a previously solved problem and then between modules, when you're trying to restrict who can who can import it. Let's say we're reducing it to a previously unsolved problem, but it's a problem that we need to address in general, not just fruitless mechanism and and for is interesting. I've, never considered that. Do you know Mike Samuels module, Kees proposal. Yes, I do okay,.

B

This is similar, but done it's a syntax. Yes,.

B

For object, capabilities, I think this is a little bit weird, but it avoids at least some naive leakage. It's still leaking it in various ways. If you're exposed, getters and setters well,.

A

I, don't understand the point about getters and setters, so.

B

In c-sharp and well, c-sharp is where it's mostly seeing. This in tests builds they'll expose private state as getters and setters, and so, if we had a private say where a person dot social security number was private. Normally during the test build that social security number would not be private. Would.

A

Not be private or would be accessible to the test code. Specially oh.

B

Yes, folks, okay.

A

So so what we would like is to be able to arrange that it remains private, but also be able to make it accessible purely to the test code. Yes,.

B

And I don't have a solution for that. This is.

A

B

A

Yeah and with regard to the the as long as we have impure modules, resource modules, going back to our normal topic of conversation, any initialized time limit limited access between modules is always going to feel a little mana object capability because it's happening statically and declarative.

A

It's only by going all the way to what Daria did, with all modules being pure and all state being instances that you go back to a pure object capability story. Even for initial access, defects, I.

B

Would agree there so a minor good thing talking about initialization. They do check that the present field doesn't already exist on values. Okay,.

A

Oh I'm, going to the the the thing I was looking at I forgot you going to go back and paste the URL.

A

A

So that was you know. That was what I wanted to say for now about the my private name thing: Bradley, do you have anything else you want to to say about it? No.

B

I was just bring this up with regards to the problem that was seen with decorators the concern about how to enable this private state, and we should look at a new feature to do it, because I can't think of a way to solve the problem. You brought up about decorators without introducing a way to put the private binding in the closure. Okay,.

A

Yes, yes, I, think that's a very nice observation. It's not one that I hadn't been thinking about the re-evaluation as a way to analyze, who should be allowed to do what and I think it's very insightful.

A

The class decorator there's no loss of security and enabling it to do anything that could do by reevaluation and a private declaration outside the class text is clearly outside of its powers to capture with their re-evaluation. So that's very nice.

B

So that's it for this I think Alex. You want to talk to me briefly about something. A week ago we had an email. Do you have time for a second I have.

A

Time my workday is over okay. We also had some more comments in chat, I.

B

Think we can stop recording at this point.

A

It looks like comments and chat are relevant to what we're just talking about so I'm, going to keep recording and go through those. So solid-solid refers to super dot, X yeah.

B

This was covered already, like was before Bradley mentioned, that it's actually locally scoped like like let and Const.

A

Okay, yeah yeah, okay lever: this is heading once the scoping product. A we clarify that week, map asset call as a return value of the week map ditto for the Matt I. uh So that's a a criticism of my private name, abstraction at being unnecessarily divergent from the week map API. That's correct. I should fix that. Okay on I think that at this point we can go ahead and stop recording.