Removal of WeakMap/WeakSet clear

Andreas Rossberg rossberg at google.com
Thu Dec 4 08:31:49 PST 2014


On 4 December 2014 at 13:58, David Bruant <bruant.d at gmail.com> wrote:
> Le 04/12/2014 09:55, Andreas Rossberg a écrit :
>>
>> On 4 December 2014 at 00:54, David Bruant <bruant.d at gmail.com> wrote:
>>>
>>> The way I see it, data structures are a tool to efficiently query data.
>>> They
>>> don't *have* to be arbitrarily mutable anytime for this purpose.
>>> It's a point of view problem, but in my opinion, mutability is the
>>> problem,
>>> not sharing the same object. Being able to create and share structured
>>> data
>>> should not have to mean it can be modified by anyone anytime. Hence
>>> Object.freeze, hence the recent popularity of React.js.
>>
>> I agree, but that is all irrelevant regarding the question of weak
>> maps, because you cannot freeze their content.
>
> The heart of the problem is mutability and .clear is a mutability
> capability, so it's relevant. WeakMap are effectively frozen for some
> bindings if you don't have the keys.

No, they are not. Everybody can enter additional keys, for example. In
the security or abstraction related examples I'm aware of, allowing
that would actually be more disastrous than doing a clear.

>> So my question stands: What would be a plausible scenario where
>> handing a weak map to an untrusted third party is not utterly crazy to
>> start with?
>
> Sometimes you call functions you don't have written and pass arguments to
> them. WeakMaps are new, but APIs will have functions with WeakMaps as
> arguments. I don't see what's crazy. It'd be nice if I don't have to review
> all NPM packages I use to make sure they dont use .clear when I pass a
> weakmap.

Sure, I should have added "security-related" to the above sentence.

> If you don't want to pass the WeakMap directly, you have to create a new
> object "just in case" (cloning or wrapping) which carries its own obvious
> efficiency. Security then comes at the cost of performance while both could
> have been achieved if the same safe-by-default weakmap can be shared.
>
>> In particular, when can giving them the ability to clear
>> be harmful, while the ability to add random entries, or attempt to
>> remove entries at guess, is not?
>
> I don't have an answer to this case, now.
> That said, I'm uncomfortable with the idea of seeing a decision being made
> that affects the language of the web until its end based on the inability of
> a few person to find a scenario that is deemed plausible by few other
> persons within a limited timeframe. It's almost calling for an "I told you
> so" one day.
> I would return the question: can you demonstrate there are no such scenario?
>
> We know ambiant authority is a bad thing, examples are endless in JS.
> The ability to modify global variable has been the source of bugs and
> vulnerabilities.
> JSON.parse implementations were modified by browsers because they used
> malicious versions of Array as a constructor which led to data leakage.
> WeakMap.prototype.clear is ambiant authority. Admittedly, its effects are
> less broad and its malicious usage is certainly more subtle.

Sure, but WeakMap.prototype.set is no different in that regard. When
you hand out a sensitive weak map you've already lost, with or without
clear. This really seems like a phantom discussion to me (and I'm
saying that although I do care a lot about abstraction and security!).

/Andreas


More information about the es-discuss mailing list