Le 23/01/2012 17:25, Brendan Eich a écrit : >> David Bruant <mailto:[email protected]> >> January 22, 2012 12:54 PM >> I'm not sure to understand what you're calling "/the/ key". >> WeakMap.prototype, being itself a weakmap, does provide a covert >> channel (since everyone has access to the same primordial objects >> identities). Of course, it can be repaired [1], but it's quite >> unfortunate to have to "repair" a feature that isn't part of a >> standard yet, isn't it? > > Yes, you're right -- the prototypes require special handling for some > of these classes. We've talked about this at past meetings. It's > unfortunate that in JS, a prototype is not instanceof the objects of > its kind. > > There is a tension between making prototypes be blank Object instances > and making them as if they were the first of their kind. For the > built-ins, we did the latter up till ES3, where RegExp.prototype was > spec'ed as Object. No implementation followed that part of ES3, and > ES5 matched reality. > > We would like a principled way for built-in constructors that have > such covert channel hazards to opt out of their prototype being of > their kind. Can you elaborate on this last point? Do you mean a run-time way? Does "opt-out" mean that the default would be that Constr.prototype is always an instance of Constr? It's been standardized this way to match reality, but it doesn't mean it was a good design decision. It's not too late to change this.
A "spec" principle could be that no new built-in (any built-in, not just the Constr.prototype) provide an irrevocable access to a shared mutable state. "built-in" here, actually refers to anything 2 scripts can irrevocably. Mutable state of objects available to everyone are almost systematically a source of covert chanel. It's true for Date.prototype, WeakMap.prototype, Map.prototype, etc. 2 scripts having access to the same built-ins and these built-in having a mutable state is what starts troubles. For the record, this rule (no irrevocable access by default to objects with mutable state) was applied in the design of Joe-E [1], a subset of Java designed to allow object capabilities. >>> For Maps and Sets, which support enumeration, the threa[t] model is >>> different. >> Allowing any type to be a key also changes the threat model, because it >> means that prior arrangement can be enough to communicate. > > True but it's only with such arrangement, which would be a different > kind of bug from any in the case where a key could be forged. In the > forged key case, there's no defense. I think that wrapping the object in a proxy and passing this proxy can save from pretty much any situation. Just an intuition. It assumes that the party I want to give access to an object via a proxy doesn't already have access to it (if it's global for instance). David [1] http://www.cs.berkeley.edu/%7Edaw/papers/joe-e-ndss10.pdf _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
