Agoric SES, 30 Sep 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: SES Meeting: Records and Tuples as primitives convergence

Description

In this call, MarkM and Mathieu deliver a new understanding about how Records and Tuples should be new language primitives, how this will interact with the evolution of SES to accommodate them, and the constraints on the design that are sufficient to preserve confinement invariants.

A

All right welcome to the cess meeting, uh we're resuming our conversation on records and tuples and uh we've had uh since our. Since we last spoke. We uh we were uh stuck on the matter of which of the bad options uh we were on the table and uh on the work side. Mark and matthew have been uh working hard to figure out a way to to move forward so mark. uh Let's take it away so.

B

Okay, so I'll get I'll I'll actually do it sort of from my subjective point of view uh on the record now uh and then and then we can proceed from there. um So I was objecting to records and tuples as primitives because of uh old code that um uh would check for for primitive and then say. Well, if it's a primitive, it's it's fine. There can't be any hidden authority here. Let it through uh and matthew, had previously raised the thing about.

B

Well, you know, cess can block box, and I I was sort of misunderstanding that or mishearing it or something as cess can block box, which, which is unacceptable for cess as a general solution, because cess is trying to accept the whole normal programming language, all normal programming practices, so that it can run all sorts of old code.

B

That's not written to run under cess, but obeys best practices like not not monkey patching primordials the case splitting that I only recently understood for matthew that completely resolves this is that there's old cess and there's new cess, meaning there's copies of cess in old code whose security needs to be maintained, and then there is the maintained.

B

Cess project that people keep using and that we keep maintaining as the spec evolves, and once you do the case splitting the dilemma I was worried about goes away and the reason it goes away is that old says because of the white listing mechanism and because box is already not on the white list will remove box and therefore the security uh dangers for old says does not arise because bach the whole box constructor, is simply censored now.

B

This means this only works if box is required to create boxes, so we still have an absolute requirement under this rationale.

B

That boxes cannot be created by syntax that, if you don't have the box constructor has been removed, then it's impossible to create boxes so that takes care of old, says and then for new cess, which is something we're maintaining.

B

We simply stop testing for deep primitiveness in the old ways. Part of the records and tuples proposal is to provide a new predicate, which is needed anyway, for is this deeply primitive, which you can't tell by just type of or using the object, constructor so every place that that's that maintains ses needs to know. If something is primitive, it would switch to the new primitive and only after it successfully switches everything over to the new primitive.

B

Would we stop censoring the box constructor, and at that point we can accept the new language with records and tuples and with box and without the security danger so, and I think that case splitting uh not only applied one of the things I was very worried about is uh we know that cess essentially has been. You know. The core assess has been reinvented several times, so we should presume today that it's also still reinvented several times by people out there in the wild that we don't know about.

B

I keep coming across academic papers that try to secure javascript and that rediscover elements of sas on their own or or partially cite us and then rediscover other things. I know that the history of salesforce was caridi, uh was kind of reinventing cess just from the enablers in javascript, without knowing about ocap theory just from from what it's, what it seemed like was possible.

B

So the reason I'm still okay under that scenario is anything that is successfully securing javascript in assess like way, must already have a white listing mechanism like this, because there's enough dangerous other things that come in that need to be removed because they're not on the white list, so anything, that's that's successfully. Securing javascript in a cess-like way must already have a white listing mechanism like this. So I think the same case splitting applies.

C

So um yeah, uh I could never explain the cess uh case like as well as mark um one case I tried to understand, but I admit I'm not familiar enough with is the case of legacy realms and membranes between them and what it takes to keep that use case. Secure.

C

My understanding of those use cases is there isn't really a whitelisting mechanism like that, uh which means a box might be mined up getting constructed.

C

However, since we're talking about two different realms, we might be able to leverage the language to block a box from being usable in the other realm and thus uh piercing the membrane.

C

I would love to be told, I'm wrong and that those environments do censor the box constructor, and this wouldn't be a concern. Similarly, but I honestly did not know enough about this use case to to be authoritative here.

D

And this is just to try to understand what you're saying you're talking about uh saying the main iframe kind of.

C

Yeah so same domain iframe, uh I'm assuming that when you create a realm in uh same domain iframe, uh I don't know if you're censoring all the apis, uh all the globals of that iframe and if you would be removing the box constructor in them. I don't know if you ever have a case where you need to put a membrane between the uh incubator, realm and a created realm, and in that case, uh is it possible for the incubator realm to create boxes and pass them uh to a created realm.

B

I think also the the we should. I've always objected to this incubator and created realm as the thing to focus on the hard case are mutually suspicious realms. When you have an incubator realm in a created realm, you've got suspicion in one direction.

B

The incubator realm can create two created realms, put a membrane between them and introduce them to each other. Now you have mutual suspicion, so that's the hard case to focus on.

C

Right and so, if that's the only case we actually care about um and if those created realms uh do uh clean up their global and sensor the box constructor the same.

C

The same reason sets would be safe. uh Membranes like this or systems build on top of real membranes would be safe as well. uh I it's it just feels. uh I don't know enough if, if that's actually the case in.

D

In those environments, so so this is, this is what we use today at software.

D

This is exactly what we what we use, so I believe that's not a problem and the reason why that should not be a problem if we get to implement the checks in the in the uh unboxing method, to only unbox, if you, if the rom associated to the to the box, is the round that is trying to unboxing, it um is because imagine that the the incubator realm creates that record and has a box on it and give it to to the to the creator on what we call blue and red yeah.

D

Give it from blue to red red will not be able to open that up, because it will fail by unboxing it um that that that case is okay.

D

um The the case that is a a a little more tricky is that, assuming that you could access the box prototype method from the other rom to try to unbox the thing on the other end. That case is impossible, because when you create a membrane and you try to access the box in one side, it will map that box to the other side. So.

C

I think I was not clear enough on the context here. I I entirely agree. So this is what this is. The reason I I said uh to be entirely safe. Having unbox uh check the uh realm, uh where the box was created uh would guarantee that the multi-realm use case like that would never be. uh There would never be a problem. uh However, this is a contentious point. This is something uh jordan is pushing uh back against uh and he would like uh the unbox to behave to not do a realm check.

C

Basically, you would be able to like pluck the uh unbox from another element apply into a box created locally without it uh throwing um and that's what I'm wondering. Is it something we can actually accommodate or is it? uh I.

D

Don't think so? Okay, I don't think so push back on that to two main reasons: uh the the one what you mentioned before, like we are in that scenario. We have that scenario where, if the thing is a primitive, we don't know we just blindly give it to the other guy and the other guy might try to access the box to fail. But the secondary reason, I think, is more important is to have some coherence with the shadow realm.

D

Where, in the shadow realm scenario, you will never be able to unbox because you're going to get an error, because you cannot get access to an object from from another realm, and I believe uh google will probably have the same stand that they have for the realms when it comes to mixing the the the object graph from different realms yeah in an iframe, you will be able to do that if you have access to the iframes prototypes to ask to try to unbox with the with the foreign prototype, and that should be fine and there's some precedent in the web idl for that most likely.

D

I remember some of the web components. Apis registry of web components- stuff, like that, that you must have access to the other, uh um the other realm api in order to try to access or do something that is meaningful.

B

In any way, that case is that's that case still same origin, or is the web component case uh where they're concerned only about cross origin.

C

There is no cross origin.

D

Yeah same same origin, yeah, okay, yeah! It's just that you, you might register like the case of web components like you might register components in different documents and you might be able to instantiate it and move them around. But when you move them around, like you create an element from an iframe and then you move it to the main window, and this element now will do some. Creation of other elements is no longer tied to the old iframe anymore.

D

uh It's remapped to the iphone that received the thing. So there's some some precedent there in terms of oh, you must have the thing on the other side in order to do something with it, um which I think is fine, but the the fatal one is like. If we allow that, then it's just simply going to be uh brock and foreshadow shadow realm, because in the shadow round you never will be able to do that, and you will be like what's going on here, like there's a reason to have that.

C

Yeah, that means shadow realm would have to prevent any box from being passed uh across the boundary, which is.

D

C

Means which is a no goal.

D

Because it's a primitive value so.

C

Well, I mean it would be possible by doing a removal of all the boxes before sending and then reconstructing a new record and yes other side recreating replacing.

D

But then that's different from a symbol like you giving a symbol to the other guy symbol coming back, but I don't think that will fly, but um we can talk to jordan about. I don't know if he's around today.

B

So so let me take a stance on a on on another controversy and how it's related to this one and and in this and what I'm about to say. I think I'm going to be contradicting something I had previously said to matthew, which is: if the ability to unbox is realm sensitive.

B

Then we should put the unboxing on the constructor not on the prototype, because people will come to think of the ability to unbox as being something that is related to a protection domain and over time people people will migrate their protection domain thinking from realm separation to compartment separation.

B

So if, if the ability to unbox is local to a protection domain, something that's seen as useful that you can't unbox after it's passed through another protection domain, then if we put the unboxing operation on the constructor, then cess can treat the box constructor the way it treats the date constructor or the function constructor as local to a compartment. I already saw on the thread that people seem to that. Mostly people seem okay with uh box dot d ref, rather than um putting it on the prototype. People seem okay with that.

B

Even if they're somewhat resistant, it's not a show stopper.

D

Yeah, I think I'm okay with that. um I I I don't see the I when it comes to primitive. We already have the present and for the dot, something that the done notation on a primitive that is tied to the local prototype, not to the remote prototype. So um I'm finding the way, but uh certainly.

B

The problem is that that between compartments, they all share the prototype. They can only differ in their constructors.

B

Within one realm, but between different compartments, let's take the um uh the date. Constructor is the the simplest clearest example, which is in the start. Compartment you've got a fully powerful date, constructor that still has date.now on it as a static in other compartments. You have a safe date, constructor that you from which you cannot find the current time. However, both of them point to the same date, dot prototype instance. Instances created by any of them are instances that inherit from the same date.prototype.

B

So if you ask any of them, if you do the instance of check for a date created by any of them using the cons any of these constructors, the answer will be yes, because the instance of check reviews on the prototype.

B

um uh Furthermore, the construct, the the the inert constructor pattern or the safe constructor pattern, uh as is that uh from any of these constructors, if you say date, dot prototype, dot, constructor, the shared prototypes dot, constructor property only points back at the safe date, um uh so I so the the uh and and uh and for some things like function where there is no safe one to be generally shared, because the entire concept of function is specific to a global. Because of scoping, we put a inert.

B

That's the inert constructor pattern where, if you say uh function, dot, prototype dot, constructor, you get a function that only that looks like a function constructor, but only throws.

B

So what I would the way I would adapt this to box is that every compartment can have its own box constructor. So they can separately virtualize box.

B

They can have different dref behaviors as statics on the box constructor, but box dot. Prototype leads to the same shared prototype where the prototype itself has no draft behavior. So it should have no draft method and the prototypes dot. Constructor property points back at a box, constructor that is safely shared and the only way to make it safely shared across. All these compartments is to is, for its dref to never deref anything, because it has to be shared between different protection domains.

D

I see I I get that I get that, but the difference between for me the difference between a box and the data is that the box itself is not a object. It's a primitive.

B

But if you're going to have the primitives behavior differ between realms, then it then people will come to expect that that and and if you're doing that, in a way that people can use that to treat realms as a protection domain. So they can count on the box being underefficable from within a non-origin protection domain.

B

Then, when they refactor their protection domain code to go from separate realms to separate compartments. We need to maintain the security properties like this that seem like normal security properties that they've that they came to count on between realms.

D

I I think I get most of that still for me, it's the same because whether you protect against the draft on the box.draft or you or you do it at the box.prototype..

D

um Unbox sounds like the same thing to me in terms of what you're saying.

B

The prototype is shared.

B

Every box constructor points at the same prototype all boxes in that realm, inherit from the same part.

D

I see so you want the constructor to be different right and and okay, I got it. I got it. Okay,.

C

I mean you could make both work, but conceptually so I I want to say quickly, I I agree and mark. Actually we don't uh you don't contradict something you don't reconstruct something we agreed upon earlier because uh earlier, when we discussed this, uh the original idea was to have uh books uh being equal and not realm specific here at this point, since they would only be able to contain objects they to do to perform this check.

C

They would also be realm uh specific, so uh making the constructor and the unboxing mechanism uh compartment specific, uh makes sense. So we're we're good yeah, actually.

E

Can we swim around and do nicolo first and then I'll go after.

F

uh Okay yeah so just to be clear.

F

This means that we can have a box dot pro site, but the box that prototype the constructor would not be the box function in compartments.

B

That's right, but that would be something that cess does uh as part of as as part of uh part of how cess changes javascript during lockdown, just as it does for date right in normal javascript uh date.prototype points back at the dangerous date object uh after cess does lockdown after you do lockdown in your assess environment, date.prototype.constructor.

B

Points back at a safe date that everyone shares likewise function.prototype.constructor points back at a safe, shareable function, constructor and the function constructor is in order to be safe and shareable. uh That one has to only throw so you have to so. The constraint is: what is it that is safe and compartment independent uh and it's okay? If it's not very useful, because nobody looks up the useful one by following the dot constructor property, making the dot constructor property lead to something that's much less useful.

B

We have found essentially breaks no code, um uh so the the proposal is that for cess, um the from any box constructor uh box.prototype.constructor.

B

Leads to a box constructor that can still construct boxes. There's no problem with that, um but it's dref.

B

Refuses to dereference any box, and as I'm saying this, I realized it could actually be more permissive than that. It could just be that every box constructor only derefs boxes, that it constructs, which you could keep track of with a weak map and then even the shared one, so that that's a possibility for making it more permissive, as I'm saying this out loud, I'm uncomfortable with it, but even if it can't de-ref anything, uh nobody will care because nobody finds these things by following the dot constructor property.

F

Okay thanks so yes like having a prototype, is really nice for us, uh because this means that we can have the value of method that jordan wants, because for records you can unwrap a wrapped record without value off, but for box value off is the only way to to get back the primitive.

F

When you put a box when you have the object for a perfect box value.

B

Of the references.

F

No uh like, if you have the object, wrapper of a box value. Oh.

B

Oh, the object wrapper. That's fine! That's fine, leaving leaving the the value of on the prototype, because that will be the case across. Let's bring it back to what we're generalizing from. uh If you create an object, wrapper on a primitive in one realm, including an object wrapper of a record or a box, and you pass that to another realm and in the other realm you, you do a box.prototype.valueof.call.

B

In other words, you you take the value of method from one realm and you apply it to the object wrapper from another realm. It will still unwrap correct, yep, correct.

D

Okay, that's the case of the same iframe same domain, iphone.

B

Okay right same domain iframe, in that case, the value of unwrapping is not a security is not useful for security separation of realms and therefore, there's no reason to preserve that security separation between compartments within a realm.

B

So value of is fine.

D

Yeah nikola, that's what what I was saying before, like in a real case, there's another way. You have a membrane that brings some guarantees there. You will never be able to get your hands on that other box, prototype or box uh method from the other from the other name in space, because it will be remapped to your local one and it will continue to throw.

F

Okay, thanks for the clarification, I think, ashley had something to say.

E

Yes, so one thing and the answer to this could be we don't know but to what you were saying earlier: meteor about older iframe based systems.

E

What's what are the possibilities of iframe based systems, not sanitizing the global as well, because I understand you know the separation of object graph. Does that pretty much always go hand in hand with reducing access to powerful things like date and fetch, or could there be quite legitimately, people that are purely doing object, graph separation, but no other security.

C

I'm not a specialist here, um but my understanding is, since there is a membrane. Anything that looks like an object would be wrapped anyway. So it's not as risky to not sanitize, but I will let kary d uh talk about membranes and uh realms yeah.

D

No, I I think uh I would say that keeping the separation between a same domain, iframe and then main window or multiple saying the mining frame is very very hard. We haven't found very, very little code that can actually keep that separation very clean, uh and the objective here is that the box doesn't introduce a new thing that might hinder that.

D

But again it's just really really difficult to have that that separation, when it comes to errors and throws, and things like that, like people do crazy things. So I think the answer to that is we don't know if there is anything out there in the world. I doubt it that there is something out there in the world that is very well uh though, and implement, and then that has a clear separation and it never leaks anything, and it's just very hard to think about something like that in a same domain scenario,.

C

However, um I think kerali had a great point earlier uh is that if you do not throw on unboxing uh for a box that was created in different realm, uh the shadow box, the shadow realm semantics have to change, and instead of allowing a box through the collarbone boundary, you now have to decline it, and that makes a membrane building on top of shadow realms, uh either impossible or extremely difficult and inefficient.

B

So so I don't understand that I was, I didn't, get that either yeah. I was I'm glad you brought this up, because I was going to ask about that. I'm very uncomfortable, with boxes going through the callable boundary, uh the the um for a membrane.

B

You have to reconstruct the box around the proxy anyway, and um uh so uh for the case where you construct a membrane on top of the callable boundary, because not passing the box makes you're already not passing other things through the call of the boundary you're, not passing objects, and then you have to reconstruct proxies without having passed the object.

B

Why isn't not passing the box exactly as much pain for for reconstructing the membrane as not passing an object.

C

So, first uh passing a box that you cannot unbox uh makes the box nothing more powerful than a unique symbol. So I don't believe that creates uh any hazard.

B

uh I trust my words carefully, I'm uncomfortable rather than I object or anything like that.

C

So as for um basically, it allows you to pass a record uh through um and rely on, the identity of the of the record uh through basically create the proxies on the other side for the content of the box and um and replace them. So so I I did a mental exercise like few days ago, and I looked at how kerdi and implemented ireland uh I it's it's beautiful engineering, it's really hard to understand uh and and that one is not.

D

Even the latest one so yeah.

E

Yeah have been working.

D

Very very, very, very much.

C

I I looked at how box uh and uh how box and records could be supported through that, if you assume identity being able to put in weak map and assume that you can pass them through and and it's actually fairly easy to add support without too much performance impact. You can just pass the record through uh and pass instruction on uh on on for each content of the box. Basically, a deep.

C

How do you say uh a deep spread of the the boxes uh and and passing the record and then just recreating a uh record on the other side once uh where, if you don't have that capability, you need to re, take a record if it has boxes, remove all the boxes so you're you have to clone a record uh that way um which would not have the same structure because, instead of boxes now you have to put- uh I don't know uh undefined or symbol instead or something like that, uh pass it through somehow reconstruct a record showing everywhere where there were boxes that were removed.

C

But since you don't have an identity to do that um again, I'm not sure what you can do. You can't put those symbols in uh in there, um so I'm not sure how you can easily identify where the holes were uh and to reconstruct the record. On the other side, it makes it really much harder to reason about for the memory.

D

I I I thought I was I was I was reading your comment. I was uh trying to reason about this clearly more advanced mechanics that we could do and I want to specify. There are two ways in which I see using records in a in a membrane on top of of a shadow realm. The first one is to use it as an internal artifact to communicate between the two sides of the membrane, because you can give them something and then they can send back that thing.

D

So the coordination between the two sides of the membrane can relied on records and tuples a specifically on boxes for for sharing all these metadata from one side to another. That would simplify a lot some of the mechanics that we use to create a membrane on top of a shadow rom.

D

So that's just a uh very clear to me at this point that it will help a lot um right now we're using the the tracks with the functions and the callable functions that put something in memory in one side of the mem and the membrane and on the other side. So you can recollect what the other side is saying about the objects that you that you control, so we could do a lot easier with boxes through records uh on on the internal mechanics of the membrane.

D

The second one is: how can we efficiently create a record on the other side that has the proper boxes and where those boxes will have a proxy of the value on the other side, on the box on the other side, and- and it seems that the the ideas that you brought up made me think a little bit more and the way we do it for objects. Today is all lazy.

D

So I'm just going to give you I'm going to give the other side a reference to an object, I'm giving you the metadata of that object and on the other side, you create a proxy and if the other side ever interact with that proxy, then you go through the membrane again and you ask what exactly is the other side trying to do so you ask for that particular piece, and then you reconstruct the object from that point of view. In the case of the record we could we could.

D

We could do a lot better by saying um I'm going to give you a record, you must do something on the other side to reconstruct the record on the other side, and um I don't have to do any ahead of time processing here. I'm just going to give you the record on the other side will say: okay, I got the record. Let me see there are boxes on it. Let me loop through those boxes. Let me ask for each of these individual boxes.

D

Can you give me a proxy of what is inside the box on the other side, and is it single pass? If we have the mechanic, the mechanics for that, it would be a single pass just to reconstruct a new record by replacing the boxes on it, and if we can optimize that in the engine that would be pretty cool because you just simply look through it change it produce a new record with the new boxes, you're done and- and that seems very elegant to me. I hope I hope that we can get to that point.

B

So after this conversation, uh the assumption that I'm inclined towards uh is that um uh until we tried someone should try, the experiment be wonderful. If somebody would try the experiment, but I'm not volunteering, to write a a membrane on top of a callable boundary under each of these engineering assumptions and seeing how much pain there actually is. If we don't allow boxes to pass through the caldwell boundary, uh but um uh so first of all, that would be wonderful. Somebody did that, but I'm not volunteering.

B

In the absence of anybody trying the experiment, I'm not inclined to introduce a hazard. Even if I agree it's not a vulnerability, I'm not inclined to make boxes pass through. The call will boundary in the absence of an experiment showing that it's substantially more painful, to construct a membrane.

B

uh If we don't allow the boxes to pass through.

D

So I pasted it in the link there. This is, in my opinion. Obviously I have worked on it. In my opinion, this is the most advanced neo-membrane implementation that we have done. um What material? What you we saw in in the iran is kind of a dummy version of these, and if you spend time on it- and we have a few folks, rick and jd and myself mostly working on this particular file um this.

D

If it feels to me that with the identity issue- and I know it is an issue because daniel raised that issue- uh these are incoherence between what the requirement tuple will will do. If we allow boxes to be passed through the callable membrane, the callable boundary versus uh what happened with the functions today that are wrapped and then when they come back, they are wrap again. So they don't preserve the identity.

D

But functions are not I'm not primitive, they're objects, while records and tuples are considered primitive and and because of that, I feel that the identity of it should be preserved. So.

B

So I I don't, I don't understand that the way a a a membrane built on top of the caldwell boundary has to engage in its own mechanisms to preserve identity, and you know, with a weak map on each side and corresponding things. That's how you build the membrane.

D

For objects for.

C

B

Right well and for functions right I mean, if you pass a function through the membrane, then it comes back with the same identity right.

D

Right right, yeah functions; yes,.

B

Yeah so uh and the same mechanism would work for boxes. Yes,.

F

Sorry go ahead: okay! Okay, thanks uh does really a function, keep identity. If you pass from one side to the other one and then back. Doesn't it.

D

F

Identity and the inconsistency that daniel pointed out was that uh if you have a function inside of a box, you pass it to one side, and then you pass it back.

B

So understand so we need to be careful about there's two different layers here: there's a callable boundary itself and there's the membrane on top of the column boundary. The callable boundary does not preserve identities. A membrane built on top of the coral boundary must preserve identities.

D

D

F

D

Four four, four four, so so I I think I understand what you're saying mark yes, so if, if you give a record with a box to the other side uh on a membrane on top of a call of a boundary and they eventually send back the record, you're gonna get a the the orino record with the arena boxes on it good.

D

So yes, so that's that's! That's a requirement of of of that membrane right. It's not even.

B

An additional mechanism- it's just reusing the mechanism that any membrane already has.

D

All right, well, you in in this particular case, because the boxes the the boxes are are going to have a a type of that is not object right right. um uh The membrane the initial implementation membranes are out there in the wild will will not support that. They will not be able to unbox right until.

B

D

Introduce the capacity or the capability to do the the the proper uh process to preserve that identity in the first place. No.

B

I agree what I meant by no additional mechanism. Is that there's no additional engineering effort? It's just a question of extending the cases that are that that the existing engineering um right.

D

Which is uh using the the new predicate to check if the thing has the boxes and then do the extra exercise of reconstructing a record that has different boxes on it and having the proper mapping between the two sides of the membrane. So if it comes back, it comes back at the arena record, not as the record on the other side.

C

I think I'm a little uncomfortable at like having some primitives not being able to go through uh the collaboratory.

D

Yeah, I think it's going to just be a problem for for for adoption and record tuples. If you just simply block that, um I I don't see any problem with letting them pass through the callable boundary, and I see some benefits that, from my point of view, are important for implementation of membrane, but also for the you to speed up the process of of of communicating between the two sides of the membrane for users.

C

There are use cases for uh shadow realms that don't involve a full membrane uh and it like isolation of code executed and if that code just wants to go and uh and operate on on the record, whether it has boxes in it or not and and transform it without touching the boxes, it should be able to do that. Yeah.

D

And, and and and and again it's you you're, so it's right, it's not really about membranes, it's just any kind of protocol that you want to implement and that's why I was talking about the using this mechanism as an artifact to do the communication between the two sides. So if you had to build your own, let's say you, you have a plugin system.

D

You want to evaluate plugins there and the plugin has to communicate back to um through the callable boundary, with the incubator and share some data, some metadata, some objects or whatever some identities that you use just to control the communication.

D

You could use records and with boxes to do that, communication and the identity is preserved. So you could you could do a lot of things as simplification mechanisms for not having to do all the gymnastics that you will have to do otherwise,.

C

Yeah and I think in general, this the difference be. Actually, there is a difference between a uh box uh that you cannot unbox and a symbol is that you can actually put it in a uh in a weak map um and and that's very powerful.

C

It actually does solve the it does solve the problem of uh of uh symbols that we cannot use as weak map keys currently and and use uh an identity. That's shareable uh directly across the shadow realm uh callable boundary.

B

Okay, so let me let me try, let me try out a question from the opposite direction.

B

Let's say that we do pass boxes through the callable boundary uh and that you know we're all agreed that uh they're not unboxable on the other side uh that they're just opaque, but they, but they come back and they preserve identity.

B

um So, let's now not worry about building a membrane that passes records and tuples and boxes through. Let's say that we that that that boxes pass through the coral boundary, as we stated and now we're just interested in building a normal membrane.

B

So now all of the work that we do to pass objects through and maintain identity on both sides, the encoding that we do to talk about objects across the callable boundary could that encoding make use of these opaque boxes in order to more efficiently communicate, object, identity across the call boundary and use this box mechanism to preserve the object identity when it comes back so that it becomes much easier to build a normal membrane.

D

Right, that's exactly what what we're doing right now, instead of.

B

D

Sorry, instead of that thing that that you mentioned, which is I I give you this box to the other side, you send me back whenever you want to do an operation. On top of that update you, don't you don't have access to the object? You only have access to the record. That represents the object internally and, and so you do operations on the other side and anytime that you have to do an operation. On top of that object, you send me that object back and I unbox it and use it.

D

Do the operation, whether that's a get or a set or where it has or a defined property or whatever it is, and I return the result back that that simplifies the thing right now. What we do is different. We give you a function, you give me a function back. That function has no identity. I need to call it. It set something globally. Yeah on the scope. I take that thing that I have in the scope and I use it as the mapping between the function and the identity wrapping that function.

D

So it's exactly the same thing, but in a more efficient way.

B

Okay, so let me just make sure I'm getting the punch line here accurately um if we introduce boxes and have them pass through the cauldron boundary, as we talked about that building a membrane using the box encoding just for normal objects in order to get a membrane across the coral boundary. Using this as the encoding for communicating across the coral boundary means that, for normal purposes, membranes become much cheaper and more straightforward. Even when there's no records and tuples and boxes involved in what we're sending across.

D

That's correct, yep.

B

E

Could I quickly clarify one thing on whether it's something we one of the other concerns was passing? The boxes across was whether that would cause engines problems for when they do equality. So if I'm, when you're, comparing two records, you know one's come across.

E

If I get two records passed across a callable boundary, they have boxes in them, and I now want to compare if they're equal engines going to have any issues with the fact that we're trying to compare things as in like could either side of this different realm, be in a different address, space or anything and they're, going to be confused. Trying to compare these things or not,.

D

I'm not an implementer, but I would say no because they have the same cover. Collector anyways.

B

Yeah the place where people create separate garbage collectors in separate address spaces uh is either between different origin, iframes or between different agents.

B

I've never heard of anybody trying to put different same origin iframes into different address spaces, cool.

E

Okay, I was making sure we just hadn't dropped. One of the previous points that was raised. It sounds it sounds like we're all good.

C

In a scary dimension like we're not introducing anything new, the the object. Graphs like themselves are isolated for shadow realm, but the linkage between the two is not you can already reference indirectly, through a wrapped function, uh an object from one side to another. uh It's just you have that you have that, like boundary of the uh wrap function here, the boundary would be different. It would be the box.

E

Yeah and just to be super clear as much as this sounds like everything is solved, jordan was very against this realms check in the first place, so there is still work to do. Don't work on that yeah yeah, so just yeah. Just so. People.

D

E

Like really think about how, because it's a shame that jordan wasn't here this week, that this this may come off again, just when there's a different group of people in the room.

D

Yeah and one one question that I have is that with these new or another new by the, uh they seems that the clear path forward is to have them as primitive.

D

um Are they going to be able to be keys in a weak map?.

C

They have to, I mean I don't see any other way if they're, not you want.

D

C

And this is why I'm still also saying like only being able to put an object or function uh inside a box makes this a lot more uh easy to reason about, and uh I know there are use cases for putting primitives in boxes, but I still don't fully uh grasp them and how uh how prevalent they are.

E

If boxes can go across a callable boundary that strengthens the argument about weak maps, because one objection to putting them in a weak map is you can just emulate that, because you can unbox the box use a like a finalization registry and kind of emulate weak behavior. But if the other side can't unbox a box, the only way they can hold it weekly is if it's natively supported directly.

E

So that's um those two things kind of go hand in hand, passing it across a realm not being able to unbox and whether they can be weak map keys. I think they're tied together.

A

So we are um auspiciously close to converging on uh into concluding on the hour on a high note, um so I I'd like uh I'd like uh nicolo, has volunteered to summarize what uh what we've converged on since we last spoke, so that we can um uh start from there when we, when we resume a conversation on records and tuples.

F

Okay, so I think we now all agree that record support doubles and boxes can be primitives and the. So this is good. uh We didn't really talk about the ability of putting primitives instead of boxes. I think we mostly all agree that we can disallow primitives, but we can talk about this again if needed, uh we are still discussing about what to do uh with boxes that cross uh crosstalk that go from one run to the other they shouldn't be allowed to be.

F

It should not be possible to unbox a box coming from under realm, but we still have to to decide exactly where it should throw.

F

I think we'll agree that boxes containing well boxes can be used as with map keys or records and tuples containing boxes.

F

Yeah so, and it's important that we move the unbox uh function from the prototype to the to the box constructor so that it it can be replaced in compartments to have a like a same compartment check.

A

That sounds that sounds like what I've heard uh does is: does that match everybody's understanding.

D

Yeah, I think so.

B

Yeah I I would go a little further on on, uh I think, with regard to boxes across the column boundary uh I was the only one who expressed that I'm uncomfortable with it and then after coridi's punchline about regular membranes, become much easier and probably more efficient.

B

I'm now fully on board, with um with boxes, go through the callable boundary opaquely, but identity. Preserving. I think, that's now very powerful.

F

C

um Yeah one thing that wasn't mentioned, but it is very important- is that there is no way to syntactically uh create a box. Yes,.

D

Yeah right, and so it's a side note on on jordan's objection.

D

I think the going in in the opposite direction and letting records to be unboxed from another realm uh will again just get a different set of people, a different group to object to uh I'm talking specifically about google positions and I'm not introducing any new api that allow this kind of intertwined object. Graph between roms.

E

One of us clarification. We, I think you can unbox a box from another realm if and only if you have already got hold of the unbox function from that other realm right.

B

E

Like so, you know in the world of callable boundaries that wouldn't be possible, so it's effectively the same thing, but in other environments, where there is a way of actually passing objects across like iframes that don't enforce this or some node api like if there's already a way you've been able to get hold of the other realms object graph and they haven't sanitized and you they give you their unbox function.

E

Then you now have it because you're now, it's now no longer cross-realm. From the unboxer's point of view.

D

Yeah to use jordan's uh punchline like this is not a very common use case. Anyways, like you, normally don't do those things across iframe and using things from the iframe and that.

B

Yeah, this should never be sensitive to the caller. It's a question of of what unbox primitive you use. So just take the the flip side of the distinction you just made is if I'm in the realm, where the box was made, but I used the unbox function from another realm, then I fail to unbox.

C

Exactly yeah and that that's kind of was, I was like if we could make this check instead of being uh from where the box functions and constructors were constructed. But if we could make those sensitive to where they're called from, I think it would alleviate all the problems, but that would be probably very bad in a lot of other yeah. That's.

E

A a can of worms inheriting, like that's the whole function.corley stuff, coming back into the spec.

B

Yeah we've we've struggled from the from the beginning successfully: we've paid an enormous price to avoid dynamic scoping successfully paid that price. Let's not introduce dynamic, stepping.

A

Yeah all right. Well, I think that that's that's uh that's good for this week. I think this is excellent progress this week um and and we have a pretty clear idea of what the uh what the, what the next actions are for this topic. So um thank you, everyone for joining us for this meeting this week, I'm going to pause about stop, recording.