Membranes, unmediated access to objects through Object.getPrototypeOf

Mark S. Miller erights at
Tue Oct 9 10:52:31 PDT 2012

On Tue, Oct 9, 2012 at 6:25 AM, David Bruant <bruant.d at> wrote:

> 2012/10/9 Tom Van Cutsem < at>

> I agree this is a (probably the only) reasonable way to relax the current
>> invariant. Chaperones in Racket show that this is workable. I'd still like
>> Mark to weigh in though. IIRC he had good reasons for not wanting to break
>> the identity-invariants related to frozen properties. I think the grant
>> matcher puzzle actually strengthens the case for not weakening the identity
>> guarantees provided by Javascript today.
> For a target, if a proxy wrapping target.[[Prototype]] can be returned by
> the getPrototypeOf trap, then, someone who knows target.[[Prototype]] can
> differentiate the wrapped version from the actual one thanks to identity.
> Being able to differentiate is what protects from being confused by 2
> objects which are presented to be the same (like in the grant-matcher
> problem).

That is correct.

> My point is that if the trap returns something else than the original
> object, a defender who knows which object is expected can know that either
> the object is a proxy or the genuine one, so it's not that big of a deal to
> allow a different object.

The typical use of a membrane is to separate two subgraphs that are not
otherwise connected, except through the membrane and perhaps a small number
of objects created and trusted by the spawner of the membrane. In my
examples, Alice spawns a membrane so that she can give Bob mediated access
to Carol, typically under the assumption that Bob and Carol are not
otherwise connected. If this membrane maintains identity on each side as
corresponding to identity on the other side, if maintains the illusion.
Since neither Bob nor Carol are ever on both sides of the membrane, neither
can do the comparison you suggest. This is as much a transparency issue as
it is a security issue. Think of FF's use of membranes to separate frames.
If the illusion broke, so would much software.

> If you don't (and won't) know the original object, what difference does it
> make to be lied to if you can't ever know the truth?
> As the dummy target example shows, actual identities don't make much of a
> difference.

I didn't follow that at all. It is a stability invariant which is being
maintained. Much software in JS counts on object identity: indexOf, switch,
WeakMaps, etc. If (Racket-like) state were maintained but identity were
not, all these would break when a membrane is interposed.

> In a way, what I'm asking is to make dummy target "official" and more
> restricted, by not allowing arbitrary objects, but only proxies with the
> actual target in their target chain.

Making them more official and restricted sounds promising. But if I
understand the rest of your sentence, what you're suggesting is not more
restricted, it's differently restricted. And the way it is less restricted
is, IMO, bad.

> David

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list