2013/1/10 Brendan Eich <[email protected]> > 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. I previously argued that symbols should actually be treated like primitives when crossing a membrane, so it'd even be easy for the collaborators to pass each other the private symbol. That said, the worst a malicious proxy can do here is to cancel the property access. This fails noisily, not silently. It's basically a denial of service. We don't really protect against that at all. A proxy could throw in all of its traps. Actually a deviously malicious proxy could just go into an infinite loop rather than throwing ;-) So yes, WeakMaps are the tool of choice if you want to be absolutely sure the object used as key cannot interfere with the lookup. > > 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. 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. Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
