[Harmony Proxies] Proposal: Property fixing

David Bruant david.bruant at labri.fr
Thu Jun 16 07:00:50 PDT 2011

Le 16/06/2011 00:53, Mark S. Miller a écrit :
> On Wed, Jun 15, 2011 at 2:10 PM, David Bruant <david.bruant at labri.fr 
> <mailto:david.bruant at labri.fr>> wrote:
>     In a way, the fixed properties proposal make proxies bicephal. For
>     some
>     inputs (property names), they plug their handler-provided
>     MOP-brain and
>     for some others, they plug a native object MOP-brain (ES5 - 8.12).
>     These
>     brains cannot communicate. This is why changing .length in the "native
>     object brain" has no effect in the other brain (which handles numeric
>     properties(...unless some of these are non-configurable)). And I think
>     it has been said before, but there would be no logging possible for
>     non-configurable properties in the context of the fixed properties
>     strawman since native MOP-brain doesn't allow that.
> Cute metaphor. But as Tom's code showed, the proxy can create fixed 
> (non-configurable) accessor properties whose getters and setters form 
> a corpus callosum ;).
I think I see also a potential security issue. In Tom's code, getters 
and setters of the non-configurable properties trigger code of what was 
in the handler. This is useful as a user to keep triggering the get and 
set traps, but it also leaks a reference to these functions (after a 
call to Object.getOwnPropertyDescriptor). In the current proposal, 
before a property becomes non-configurable, there is no access to any 
trap (unless having access to the object which implies having indirect 
access to all traps or the handler itself). After becoming a 
non-configurable accessor property, the get and set trap applied to the 
non-configurable properties become available as independant functions 
that can be passed around.
Currently, one can revoke the access to an object with a 
membrane/wrapper, but with the leak, I think that all getter/setters 
will have to be wrapped as well (their call trap in particular)? Ok, 
maybe there is no security issue, but it adds a little bit more work.

I was first enthousiastic by the general idea of keeping get/set traps 
through getter/setters (came up first with the fix trap, I think), but 
since there is an API allowing to extract these functions independently, 
I'm not really sure it's a good idea (in general) anymore.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110616/4aef6a3b/attachment.html>

More information about the es-discuss mailing list