Invoke trap

Jason Orendorff jason.orendorff at gmail.com
Mon Jun 10 07:17:40 PDT 2013


On Sun, Jun 9, 2013 at 1:28 PM, David Bruant <bruant.d at gmail.com> wrote:

> For the non-membrane proxy use case... I don't know what to think
> anymore...


I'm not sure what we're trying to do is meaningful in the non-membrane
case. The properties we would like to have are:

* Security - A proxy can wrap an arbitrary object, such that code that has
a reference to the proxy can't obtain the wrapped object.

* Transparency - Given an arbitrary object, a proxy can be created that's
indistinguishable from the wrapped object.

But how do we define "indistinguishable"? I can imagine an adversarial
game: as the challenger, you give me an object. I create a wrapper around
it. Then I hand you either the original object or the wrapper, and your
challenge is to figure out which one I've given you. But to make the game
nontrivial, you shouldn't be allowed to use object identity (that is ,
===), and I don't see how to formalize that rule.

In the membrane case, I think it is possible: instead of handing "you" an
object to test, I run test code of your choice in some kind of isolated
environment.

In the non-membrane case I don't know that there are any invariants to
worry about breaking.

-j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130610/030a003a/attachment.html>


More information about the es-discuss mailing list