Existential Pontification and Generalized Abstract Digressions

## What is a membrane?

If you hang out long enough with a certain crowd (in my case, it was the ECMAScript TC39 committee), you will probably hear the term membrane tossed around. And eventually, you will start to wonder, “Well, what is a membrane, anyway?”

As is the case with many clever but simple ideas, membranes were first introduced as a footnote [1] in a PhD thesis. Suppose that you are building distributed system, in which you pass references to objects between two separate nodes. If I want to pass a reference to foo in process A to process B, I can hardly just hand over an address—the memory spaces are not the same! So instead, I need to create a wrapper object wrappedFoo representing foo in B, which knows how to access the original object in A. So far so good.

Now here’s the catch: what if I pass a reference to wrappedFoo back to process A? If I were not very clever, I’d do the same thing as I did originally: create a new wrapper object wrappedWrappedFoo in A which knows how to access wrappedFoo in B. But this is silly; really, when I cross back over to A, I want to get back the original foo object.

This wrap-unwrap behavior is precisely what a membrane is. We consider the original object foo to be “inside” the membrane (a so-called wet object), and as it exits the membrane, it is wrapped with its own little membrane. However, when the object returns to its original membrane, the wrapper goes away. Just like in biology!

There is one last operation, called a “gate”: this occurs when you invoke a method on a wrapped object. Since the wrapper cannot actually perform the method, it has to forward the request to the original object. However, the arguments of the method need to get wrapped (or unwrapped) as they get forwarded; as you might expect.

While I used an RPC-like system to demonstrate the basic principle of membranes, a more conventional use is to enforce access control. Membranes are quite important; Mozilla relies on them extensively in order to enforce access restriction between objects from different websites which may interact with each other, but need security checks. (Actually, did you know that Mozilla is using a capability-based system for their security? Kind of neat!) It’s important to notice that when we unwrap, we are skipping security checks—the only reason this is acceptable is because the only objects that will be able to access the unwrapped object are precisely those objects in the same domain. For a more modern treatment of the subject, check out a more recent paper, Trustworthy Proxies: Virtualizing Objects with Invariants, which includes a lucid explanation of membranes.

[1] Well, actually it was a figure; figure 9.3 on page 71, to be precise!

### 5 Responses to “What is a membrane?”

1. Brian says:

Are you sure Miller wasn’t drawing on Salzer’s use of the term membrane forty years earlier?

2. Hard to say! It seems certainly plausible that the term membrane was already floating around in the folklore prior to the thesis; I haven’t been able to identify any earlier uses of the term in this context, but I’d be quite interested to hear about them!

This reminds me quite a bit of Matthews & Findler’s work on the semantics of multi-language programs: http://www.cs.uchicago.edu/files/tr_authentic/TR-2006-10.fdf

In this application, it’s less about providing extra information along with the foreign object than it is about inserting necessary runtime checks for conversion between dynamic and static values.

This gets particularly interesting when converting arguments and return values, as you have to account for contravariance (in fact, I think this paper was my first exposure to contravariance). I am curious how this is implemented in an untyped setting; lots of dynamic checks?

4. Interesting paper! It is hard for me to tell if there is a relationship here; however, I can say that at least for Mozilla’s membranes, wrapped objects can perform any assortment of dynamic checks before forwarding the request along.