tristanls
commented
6 years ago Hi @ajvincent ,
Thanks for reaching out, it's always exciting to meet someone with deep understanding of membranes! I think I reviewed enough to be able to provide a comparison, here goes...
capability-sdk-js is a JavaScript SDK for web services of capability.io, Membrane Service is one of the services. Membrane Service pretty much implements the membrane as described in the concept article. However, the Membrane Service implements Membranes as an HTTP proxy. So, instead of working at the level of JavaScript properties/objects, it works at an abstract level of "resources on the web" and HTTP requests.
For example, say, I create an AWS Lambda function and want to give you ability to invoke it. The AWS Lambda function would be the "resource on the web". The AWS API call of InvokeFunction would be the (using Tom's terms) "wet object". I would then create a Membrane in Membrane Service. Then I would export the "wet object" (AWS API call of InvokeFunction) through the membrane and end up with a "dry object" of a Capability. Something like cpblty://example.com/#CPBLTY1-IbwNerN4Dw4BYlpYc4Az-pNBWen_WsdrTrpb-HmMiJOEHvCv1xHKBn2Q (this translates into an HTTPS POST request in a straightforward manner, cpblty URI scheme is described in capability-uri). This is a capability in the sense of an object capability, in that it is "a transferable right to perform one (or more) operations on a given object". The key aspect of it being a capability is the transferable part, in that anyone with the capability can invoke the original AWS Lambda function. This way, you can give the capability to someone else, or better yet, create your own membrane, and then export your capability through the membrane and give the resulting capability to someone else, thus creating a separate revocation domain for the capability you give away. Another key aspect of being a capability is to be unforgeable. I discuss more nuances of unforgeable in this blog post(for the purposes of this comparison you can interchange the terms "actor address" and "capability" for the blog post to be more topical).
@dalnefre and I have also implemented membranes in JavaScript, but took a completely different approach. It was motivated by providing an actor framework for JavaScript. The membrane implementation is here, the actor framework (it's really really small) is tartjs. We chose to hide data in closures instead of using JavaScript proxies, also, the proxies weren't around when we worked on this. We have also implemented oblivious distributed confinement, as demonstrated in tart-marshal, which demonstrates how to span membranes across memory realms. @dalnefre describes more on that in his Distributed Security blog post.
I hope that provides a comparison that makes sense.
Cheers,
Tristan
ajvincent
Greetings! I've been building a JavaScript library named es7-membrane, based on a Membranes concept article by Tom van Cutsem. It appears to me that my concept of a membrane differs from yours, but I can't quite figure out what your project means by the term "capabilities".
That said, there's a Secure ECMAScript group that might be interested in what you're doing here as well - the terminology you use aligns with theirs in some respects.
I stumbled across your project because a fellow engineer asked me to consider renaming my npm package to es-membrane or js-membrane. Your packages showed up in a quick search on npm for the latter term.
I figured I'd file this ticket to ask for a written comparison between your goals and mine, your terminology and mine.