Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))
bruant.d at gmail.com
Mon Jan 28 11:10:30 PST 2013
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
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
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:
> 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.
More information about the es-discuss