July 26, 2012 TC39 Meeting Notes

Tom Van Cutsem tomvc.be at gmail.com
Tue Jul 31 10:06:52 PDT 2012


2012/7/30 David Bruant <bruant.d at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120731/399a2a28/attachment.html>


More information about the es-discuss mailing list