unknownPrivateSymbol trap (was: WeakMap better than Private Symbols? (was: direct_proxies "problem"))
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
> 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
> 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.
> 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...
More information about the es-discuss