2012/7/31 Tom Van Cutsem <span dir="ltr"><<a href="mailto:tomvc.be@gmail.com" target="_blank">tomvc.be@gmail.com</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">2012/7/30 David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <div>Le 28/07/2012 15:16, Tom Van Cutsem a
      écrit : </div></div><div><blockquote type="cite"><div><div class="gmail_quote"><div><div>
              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.<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote></div><div class="im">
    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?<br>
    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.<br>
    <br></div>[analysis snipped]<div class="im"><br>
    <br>
    Is there a disagreement on my analysis?<br>
    Is there a benefit in the "public counterpart" design I'm
    forgetting?</div></div></blockquote><div><br></div><p style="margin:0px;font-size:13px;font-family:Arial">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.</p>
</div></blockquote><div>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.<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><p style="margin:0px;font-size:13px;font-family:Arial">But we cannot guarantee that all APIs worth intercepting/virtualizing in the future will not make use of private names, only unique names.</p>
</div></blockquote><div>true. Flexibility is an interesting and important argument.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote">



<p style="margin:0px;font-size:13px;font-family:Arial">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.</p>


<p style="margin:0px;font-size:13px;font-family:Arial;min-height:15px"><br></p>
<p style="margin:0px;font-size:13px;font-family:Arial">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.<br>
</p></div></blockquote><div>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.<br>
<br><br><br><div class="gmail_quote">2012/7/31 Tom Van Cutsem <span dir="ltr"><<a href="mailto:tomvc.be@gmail.com" target="_blank">tomvc.be@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><div class="gmail_quote">2012/7/31 Brandon Benvie <span dir="ltr"><<a href="mailto:brandon@brandonbenvie.com" target="_blank">brandon@brandonbenvie.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.
</blockquote></div><br></div><div><p style="margin:0px;font-size:13px;font-family:Arial">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.</p></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>

<p style="margin:0px;font-size:13px;font-family:Arial">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.<br></p></div></blockquote><div><br>I think I missed the *Name trap design in the notes.<br>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.<br>
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.<br>
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.<br>
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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>


<p style="margin:0px;font-size:13px;font-family:Arial">AFAICT, the only two useful things a handler can do when it intercepts a private name it knows nothing about is:</p>
<p style="margin:0px;font-size:13px;font-family:Arial">1) ask the proxy to forward</p>
<p style="margin:0px;font-size:13px;font-family:Arial">2) throw<br></p></div></blockquote><div>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.<br>
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:<br>
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)<br>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.<br>
<br>What do you think?<br><br></div></div>David<br></div></div>