Non-extensible WeakMaps

Brendan Eich brendan at mozilla.org
Mon Jan 23 08:25:04 PST 2012


> David Bruant <mailto:bruant.d at gmail.com>
> 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.

>> 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.

> However, besides the {WeakMap|Map|Set}.prototype, I do not see anything
> that cannot be controlled with a revocable caretaker.

Right, and these are needed in general in same-frame mashups anyway (if 
I understand correctly). Mark is Jedi master here, he should weigh in.

/be
>


More information about the es-discuss mailing list