Non-extensible WeakMaps

David Bruant bruant.d at gmail.com
Sun Jan 22 12:54:03 PST 2012


Le 22/01/2012 21:11, Brendan Eich a écrit :
>> Herby Vojčík <mailto:herby at mailbox.sk>
>> January 22, 2012 11:42 AM
>> David Bruant wrote:
>>> I agree that Object.preventExtensions is defined as preventing addition
>>> of new properties. Likewise, Object.freeze and Object.seal only act on
>>> object properties (extended to private properties?).
>
> No, we agreed the property visiting under freeze and seal does *not*
> affect private-object-named properties.
Ok.

>>> But the broader problem they are addressing is reducing the mutability
>>> of objects. WeakMaps, maps and sets bring a new form of mutability
>>> which
>>> cannot be implemented in the form of private properties (I think at
>>> least). So the question is:
>>>
>>> Should Object.preventExtensions be extended to reduce WeakMaps, Maps
>>> and
>>> Sets mutability? Likewise for Object.seal|freeze?
>>
>> It would be special case. I'd say no.
>
> I agree so far as this goes.
>
> Mark has thought deeply about this topic, with the use-case of
> preventing extensions being the closing of covert or side channels in
> JS objects. For private names and weak maps, there is no channel to
> close via preventExtensions, since the attacker by definition doesn't
> have the key.
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?

I'm seeing that it is suggested [2] that WeakMap.prototype.set(k,v) and
WeakMap.prototype.delete(k) throw a TypeError (instead of trying to
mutate WeakMap.prototype). Instead of WeakMap.prototype being a
non-mutable weakmap, what about it being not a weakmap at all? (and
throw for .has and .get as well)

> For Maps and Sets, which support enumeration, the thread 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.

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

David

[1]
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/initSES.js#2237
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=656828


More information about the es-discuss mailing list