Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))

David Bruant bruant.d at gmail.com
Mon Jan 28 11:10:30 PST 2013


Hi Tom,

Thanks for this summary.
About the first proposal and getting rid of the whitelist, indeed, the 
whitelist was here to tell about known symbols to avoid leakage. If 
private symbols pierce proxies, the whitelist has no purpose any longer.

I don't understand why problem B isn't solved with the first proposal. 
Since the proxy is pierced, access to private symbol'ed properties don't 
trap and the proxy can't throw on access (since it's not trapped).
If I'm misunderstanding the proposal, could you show an example, under 
the unconditional forwarding proposal in which the problem B can be 
reproduced.


The second proposal reminds me a bit of an evolution of the first proxy 
design in which each proxy would have its own storage for invariant 
checks. Since a forwarding proxy was the main use case and already had a 
storage area (the target), this led to the second design "direct proxy" 
in which both storages would be merged in the target.
By analogy, the natural evolution of the second proposal would be the 
first proposal.

David


Le 28/01/2013 19:45, Tom Van Cutsem a écrit :
> I just wrote up a strawman on the wiki to summarize the recent debates 
> about the interaction between proxies and private symbols:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:proxy_symbol_decoupled
>
> The page actually lists two proposals, out of which I prefer the 
> second one.
>
> If I forgot some benefits/drawbacks of either approach, please speak 
> up. Thanks.
>
> Cheers,
> Tom



More information about the es-discuss mailing list