2012/8/2 Tom Van Cutsem <tomvc...@gmail.com> > [+samth] > > 2012/8/2 David Bruant <bruan...@gmail.com> > >> >>> To follow-up on that part, here is a gist with the difference between >> what the current proposal is and the alternative proposal [1]. [...] >> >> [1] https://gist.github.com/**3232772 <https://gist.github.com/3232772> >> > > Thanks for writing up that gist. Sometimes a piece of code says more than > a 1000 words ;-) > I had it clear in my mind, but felt my explanations weren't conveying it, so writing the code sounded like the right solution :-)
> Your proposed alternative is something to consider, although I'm still > uncomfortable with the WeakMap.prototype.has.bind mechanic. > I have to admit that it's a bit specific as a constraint. The problem is that for security reasons we can't have isPrivateNameKnown to be any function, because an attacker would just set a function and wait for it to be called with the private name. A bound function would guarantee security. Certainly there are other directions to explore. The goal is to have a proxy-scoped (in "space") and potentially infinite-scoped (in time) shared knowledge of what private names a proxy knows. The knowledge is to be shared with the engine and no one else. We should also reconsider the simplest alternative of just not trapping > private names on proxies. > You mentionned that if private names aren't trapped, it pierces membranes, so when you want to prevent access to objects in the membrane, you can't for private names. A softer option in the direction of "not trapping" would be to have a privateNameSink for known and unknown names. It leaves the opportunity to not pierce membranes (but I don't know if it's detrimental to other use cases) David
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
