Removal of WeakMap/WeakSet clear

David Bruant bruant.d at
Wed Dec 3 15:54:49 PST 2014

Le 03/12/2014 19:10, Jason Orendorff a écrit :
> On Wed, Dec 3, 2014 at 9:04 AM, David Bruant<bruant.d at>  wrote:
>> A script which builds a weakmap may legitimately later assume the weakmap is
>> filled. However, passing the weakmap to a mixed-trusted (malicious or buggy)
>> script may result in the weakmap being cleared (and break the assumption of
>> the weakmap being filled and trigger all sorts of bugs). Like all dumb
>> things, at web-scale, it will happen.
> OK. I read the whole thing, and I appreciate your writing it.
> There's something important that's implicit in this argument that I
> still don't have yet. If you were using literally any other data
> structure, any other object, passing a direct reference to it around
> to untrusted code would not only be dumb, but obviously something the
> ES spec should not try to defend against. Right? It would be goofy.
Object.freeze and friends were added to the ES spec for the very purpose 
of being able to pass direct reference to an object and defend against 
unwanted mutations. à propos d'une
Is Object.freeze goofy?

> The language just is not that hardened. Arguably, the point of a data
> structure is to be useful for storing data, not to be "secure" against
> code that **has a direct reference to it**. No?
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.

> So what's missing here is, I imagine you must see WeakMap, unlike all
> the other builtin data structures, as a security feature.
I'm not sure what you mean by "security feature". Any API is a security 
feature of sort.

> Specifically, it must be a kind of secure data structure where
> inserting or deleting particular keys and values into the WeakMap does
> *not* pose a threat, but deleting them all does.
> Can you explain that a bit more?
> I see the invariant you're talking about, I agree it's elegant, but to
> be useful it also has to line up with some plausible security use case
> and threat model.
The ability to clear any WeakMap anytime needs to be equally justified 
in my opinion. I'm curious about plausible use cases.

What about making 'clear' an own property of weakmaps and make it only 
capable of clearing the weakmap it's attached to?


More information about the es-discuss mailing list