Yes, you made a nice case. In a way I'm glad, as I wasn't too keen on the
additional complexity brought about by the bicephal approach (membranes
could still be made to work by converting all non-configurable properties
into accessors as shown on the wiki page, at the price of giving up fully
transparent wrappers)
I guess the way forward is to try and specify precisely what consistency
checks a proxy should perform, and how cheap or costly these will turn out
to be.
Re. untrusted code communicating via non-configurable, writable properties:
I believe this is not a problem specific to proxies with fixed properties,
or even proxies in general. As soon as you share a non-frozen object, this
kind of communication can happen. But granted: membrane proxies +
transparent fixed properties are flawed in this regard.
Cheers,
Tom
2011/6/20 Mark S. Miller <erig...@google.com>
> Hi David, my compliments. This is an important issue I should have caught
> but didn't notice. Thanks. I think agree with your conclusion (which I was
> leaning towards anyway).
>
>
> On Mon, Jun 20, 2011 at 10:25 AM, David Bruant <david.bru...@labri.fr>wrote:
>
>> Le 20/06/2011 17:15, David Bruant a écrit :
>> > Hi,
>> >
>> > We may need to switch from the (bicephal) fixed properties model to a
>> > "trap all with invariants enforcement" model.
>> >
>> > With the current simple membrane example:
>> > -----
>> > var o = {};
>> > var s = makeSimpleMembrane(o);
>> > var wrapper = s.wrapper,
>> > gate = s.gate;
>> >
>> > // ... later, in untrusted code (variable name kept for readability)
>> > Object.defineProperty(wrapper, 'a', {value:1, configurable:false});
>> >
>> >
>> > // ... later, back in trusted code:
>> > gate.disable()
>> >
>> >
>> > // ... later in the same untrusted code which had a reference to the
>> > wrapper object.
>> Actually, it's more convincing if the wrapper is given to another piece
>> of untrusted code, because this code should not have access to what
>> another untrusted code added to the wrapper AFTER disabling. Also,
>> untrusted code could communicate through non-configurable, but writable
>> properties which doesn't sounds good.
>>
>> > wrapper.a; // 1 in the fixed properties model
>> > // throw if the 'get' traps was actually called.
>> > // Such a difference is certainly noticeable in all traps.
>> > -----
>> >
>> > The problem with the fixed property model is that properties exist on
>> > the proxy object itself with no way to control (and prevent in our
>> > case) access to them.
>> >
>> > David
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss@mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Cheers,
> --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
