2012/7/30 David Bruant <bruan...@gmail.com> > Le 28/07/2012 15:16, Tom Van Cutsem a écrit : > > We still want proxies to intercept private names. It may be that the proxy > handler knows about the private name, in which case it has the "capability" > to usefully intercept access to it. > > But it may be that the proxy doesn't know the private name for the very > reason that the name holders do not want any proxy to know it. In that > situation, why would the proxy trap be called? > The proxy cannot make any constructive use of the public part without the > private counter part, apart maybe from storing all public names it can and > wait for a private name leak. Not trapping offers security by default. > > [analysis snipped] > > Is there a disagreement on my analysis? > Is there a benefit in the "public counterpart" design I'm forgetting? >
I'm open to the idea of just not trapping private names (it would certainly simplify things), but like any part that proxies cannot virtualize, what would be the implications on self-hosting APIs? Of course, since private names don't yet exist, APIs such as the DOM do not make use of it. But we cannot guarantee that all APIs worth intercepting/virtualizing in the future will not make use of private names, only unique names. On the other hand, if we automatically forward private name access (no trapping), we should be aware that such accesses would pierce membranes. One could argue that the private name should never leak through the membrane in the first place. If private name access can be trapped, membrane proxies can throw when an attempt is made to access a private name the membrane doesn't know. You do seem to suggest that the current design unnecessarily elevates the risk of a private name leak by allowing trapping. A proxy can store all the .public objects it wants, that doesn't give it any more power. The confinement of the private name never rests on the confinement of the name.public property. I see no elevated risk of leaks in the current proposal due to a proxy hoarding public objects. Cheers, Tom
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
