Defining membranes

These are notes from a Secure EcmaScript Meeting, many years ago, when I was trying to understand what was going on. This might evolve into something more substantial later on with regards to multi-realm programming in JS.

part of the [[ tc39 playlist ]]

A membrane:

A membrane’s main objective is to provide access to the object graph on the other side of the membrane, in a way that preserves the integrity of the outside object graph. A Membrane is a cut point in the object graph. A membrane can be at the realm boundary. A membrane has to preserve separation, it must be impossible to get direct access.

Near Membranes

A near membrane is different where:

• When you see an object graph from thee lens of a near membrane, you have the illusion that it is in the same realm. The difference is in mutation, the mutations you make are only seen by you, and not by the object on the other side of the membrane.
• One that is fully transparent providing the illusion of same realm, whereas the regular realm is just fully transparent. Not relaying mutations is something that could be done in both.

Fully Transparent:

Membranes:

Case of a regular membrane where the membrane boundary coincides with the realm, interaction with an object in the other realm is as though there was no membrane.

Even with transparency you can encounter identity discontinuity (as you do between realms). The goal of the membrane is to act as though the membrane isn’t there.

For Near Membranes:

You can operate on objects on the other side of the membrane as if they were local objects.

You do not experience identity discontinuity. Provides illusion that everything is in the same realm.

Transparency corresponds with operations from one side of the membrane with the other side of the membrane that result in the same output as if the membrane was not present. It will give the same data, or it will give an object that appears to be the same object.

—

A concrete example is a near membrane that protects your application, blue side runs your code. Red side attempts to change array.prototype.forEach — this is visible to the red side. However this has no effect on the integrity of the blue side.

Important points:

The reason it is called near membrane: Tries to make the objects look like they are part of the same realm as the accessor. Near membrane rewires things to appear local to the realm of the accessor.

-The difference between a regular membrane and near membrane is transparency. It isn’t handing proxies, it is handing realm appropriate versions of the callers realm?-

The difference between a regular membrane and near membrane is how they uphold transparency. For a near membrane you will still handle proxies, but when you navigate from the proxies to other objects such as navigating up to the prototype, it will substitute a realm local substitute.

A Membrane can achieve this near membrane property with a distortion. A distortion is a way to describe taking a membrane mechanism and introducing a purposeful deviation.

This is correct up to exotic internal slots.

Identity discontinuity is one of the real motivations for near membranes. If you move everything into the same realm you would have to freeze all objects in order not to deal with mutations from the same realm.

For a regular membrane, if you have a red proxy for a blue date instance. If you navigate to its prototype, you will get a red proxy for a blue date prototype

In a near membrane, you will get the normal built in red date.prototype.

It can be considered a distortion.

A membrane connects two different realms transparently — that is, you have the same effect as though the objects were in the same realm.

Normal membrane has no distortions, while near membranes have distortions.

Exotic Internal Slots

Near membranes do not cover maps, weak maps, etc. “undeniables”

Promises.

Record and tuple add new undeniable intrinsics.

Internal slots on Undeniable intrinsics are problematic because they make practical transparency.

Undeniable Intrinsics -

First approximation: An undeniable object is one that can be reached purely by syntax regardless of what monkey patching has been done in the primordial space. IE) all of its properties were replaced with something else. But, if you evaluate [] — it will be an array that inherits from the original array prototype. This makes array.prototype undeniable.

This is incomplete. In order to get to the array instance to the array prototype, you have to navigate upward [[ prototype ]] — and if all of the builtin methods have been replaced (of) that would be replaced. It is not clear if there is any way left to get to thee object that the array instance inherits from.

If you can get to it by syntax and ascending the prototype chain.

Access to the object cannot be prevented

Undeniable = Array, Undefined, etc. throw TypeError()