2012/7/31 Tom Van Cutsem <tomvc...@gmail.com> > 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. > To some extent, we can say that they do. dom.js uses _properties to discriminate what's private. So, that's where they use private names if they had them. It certainly gives a good sense of where private names would be used in a self-hosted DOM. Other libraries use that convention (especially in Node.js from what I've seen), so that could give an idea.
But we cannot guarantee that all APIs worth intercepting/virtualizing in > the future will not make use of private names, only unique names. > true. Flexibility is an interesting and important argument. > 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. > I didn't say that, I said that the outcome of a leak is bigger if a proxy can store the public parts and wait for a private name leak, but I realize I was mostly wrong on that point. Public parts do not increase the things one can reach in case of a leak in a meaningful way. It just make it more efficient to search for things. 2012/7/31 Tom Van Cutsem <tomvc...@gmail.com> > 2012/7/31 Brandon Benvie <bran...@brandonbenvie.com> > >> You can still do useful things even without access to the public name >> though, as long as you can still forward to the target and get the result >> back. This allows you to instrument the action and to associate it with >> something unique even if you don't have a way to access the name and it's >> valuable arbitrarily outside of the trap. However, if there's no way to >> forward it correctly then the trap can't really exist at all anyway. > > > No, if a handler intercepts a private name access for a private name it > doesn't know, it has no way of forwarding the access in such a way that it > can still intercept the result. That would allow the handler to read or > change the value of a private name it doesn't know. > The only way a handler can forward a private name access is by returning > undefined from its getName trap. The forwarding at that point is done by > the proxy, with no further interaction with the handler. The handler > doesn't get to change the value returned from target[name]. This is crucial. > I think I missed the *Name trap design in the notes. Returning [name, value] looks very heavy to me. If you know a secret once and can prove it once, you can know it and prove it forever (and very likely will), so the API should take that property into account. One idea would be to have a particular property in handlers, like "knownPrivateNames" (which could smartly be expected to be an ES.next Set, or more accurately a WeakSet if this one ever gets mentionned in the spec) and whenever an *Trap returns for a particular private name, the after-trap checks whether you have the private name in your knownPrivateNames set. That should be enough to prove you know the secret. When you get to a new private name, put it in the knownPrivateNames set. Even in the "return [name, value]" design, one needs to store known private names somewhere anyway and it'll likely be on the handler anyway too :-) So it may be a good idea to make this storage "official" and make it a tool to communicate with the JS engine. Maybe the details I propose are not perfect, but I think there is a game-changer in the idea of a handler being able to share with the JS implementation which secrets it knows. AFAICT, the only two useful things a handler can do when it intercepts a > private name it knows nothing about is: > > 1) ask the proxy to forward > > 2) throw > Interestingly, you do not mention the public counterpart here :-) Digging a bit deeper, from a trap point of view, if you get to know 2 unique names for which you don't know the private part, then I don't think you can make any use of this information. Can you do a more relevant choice (forward or throw) based on the different unique name identities? I can't think of any now. From a trap point of view, you just have 2 unique, unforgeable and useless tokens, you can differnciate them thanks to identity, but that's as far as it gets, so I agree with your analysis here. Certainly trapping for private names, if it's to offer these two choices, is valuable, so I take back the idea of not trapping for private names. But I think i would take a different direction for the trap design. Combined with the above idea of sharing a knownPrivateNames set with the JS engine, what could happen is the following: 1) regular get/set/delete/... traps even for unique names and private names you have proven to know (since you have proven to know the private name, they are passed directly, no need for a public counterpart) 2) *Name traps when you don't know the private name. This trap doesn't have the public part as argument (since there is no use for it) but still leaves you the 2 choices of asking to forward or throwing. What do you think? David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
