unknownPrivateSymbol trap (was: WeakMap better than Private Symbols? (was: direct_proxies "problem"))

David Bruant bruant.d at gmail.com
Tue Jan 15 11:56:00 PST 2013

Le 15/01/2013 20:32, Tom Van Cutsem a écrit :
> 2013/1/10 Brendan Eich <brendan at mozilla.com <mailto:brendan at mozilla.com>>
>     David Bruant wrote:
>         [Cc'ing Tom and Mark to be sure there is agreement on what I'm
>         claiming in this message]
>         Le 10/01/2013 22:10, Brendan Eich a écrit :
>             Nathan Wall wrote:
>                     Brendan Eich:
>                         No, not if the symbol is not in the whitelist.
>                         Zero information leak is
>                         required.
>                     That's good news too. Objection withdrawn.
>                 Maybe I gave up too easy :). Is the
>                 `unknownPrivateSymbol` trap called? What's the
>                 rationale for this trap?
>             I just wrote that the trap is not even called if the
>             symbol is not in the whitelist passed in when the proxy is
>             created.
>         No, the unknownPrivateSymbol trap is called when the symbol is
>         not in the whitelist, so, as Nathan fears, a malicious proxy
>         could throw and cancel the access to the private property.
>     Of course, and my description was for a "knownPrivateSymbol" trap!
>     Shows how much I know :-P. Waiting to hear from Tom on this.
>     Thanks to Nathan for being a squeaky wheel.
> The "unknownPrivateSymbol" trap would indeed be called when a private 
> symbol not on the proxy's whitelist is encountered.
> As far as I recall, the purpose of the trap was to allow a membrane or 
> revocable proxy to explicitly abort accesses involving such private 
> symbols. The point being that if a membrane can't abort such accesses, 
> then collaborators on both sides of the membrane could circumvent the 
> membrane by communicating via a previously agreed upon private symbol.
Yes, we've discussed that in length with Nathan Wall :-)

>         I think the return true/false protocol should be replaced by a
>         return/throw protocol (return value is ignored). It'd be much
>         more explicit this way.
>     Agreed.
> I would be fine with that, although it might be a bit inconsistent 
> with other traps like "set", "defineProperty", etc. which all return 
> booleans to indicate success.
There is a precedent for defineProperty because [[DefineOwnProperty]] 
returns a boolean. After-refactor-[[Set]] also returns a boolean, so it 
makes sense the set operation does too.

> That said, this trap is already the odd one out: it doesn't really 
> make sense to define a Reflect.unknownPrivateSymbol method either, 
> like we did for all other traps.
> IOW, unknownPrivateSymbol is really more like a notification callback 
> than a real trap that gets to return some useful value.
I agree with this view.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130115/0754ac38/attachment.html>

More information about the es-discuss mailing list