Removal of WeakMap/WeakSet clear
kg at luminance.org
Wed Dec 3 14:42:40 PST 2014
'It remains possible to create clearless weakmaps to pass around (by
wrapping a weakmap, etc.), but it makes security (aka code robustness)
an opt-in and not the default.'
Seeing this sort of security-first argument when discussing a
user-space data structure is really confusing to me. If the stated
goal of WeakMap is security, and this is a noble goal, why isn't the
same true for the non-weak new containers like Map and Set? Immutable
containers built-in to the standard library would certainly be a
useful thing to have - people implement them in JS libraries all the
time because they need them - so if that's in scope it seems like it
should be a goal that's applied more evenly.
As stated before, I believe the benefit of protecting people from
having maps accidentally cleared may not outweigh the damage caused by
having many applications out there with catastrophically bad
performance due to clearing maps incorrectly (or expecting map
clearing to be a sensible operation at all, when it isn't.) The
underlying implementation and characteristics of WeakMaps are *really,
profoundly strange* to anyone who doesn't know a lot about GCs and JS
runtimes, if you ask me. A data structure that isn't understood is
more likely to be misused. If we're talking about promoting overall
code robustness, minimizing surprises in general seems like it should
be a priority, and the underlying behavior of a transposed WeakMap -
contained to everything else in the stdlib - is surprising.
On 3 December 2014 at 09:04, David Bruant <bruant.d at gmail.com> wrote:
> Le 03/12/2014 16:26, Jason Orendorff a écrit :
>> On Wed, Dec 3, 2014 at 8:35 AM, Andreas Rossberg <rossberg at google.com>
>>> (Back to the actual topic of this thread, you still owe me a reply
>>> regarding why .clear is bad for security. ;) )
>> I'd like to hear this too, just for education value.
> Unlike Map.prototype.clear, WeakMap.prototype.clear is a capability that
> cannot be userland implemented.
> With WeakMap.prototype.clear, any script can clear any weakmap even if it
> knows none of the weakmap keys.
> 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.
> WeakMap.prototype.clear is ambiant authority which necessity remains to be
> It remains possible to create clearless weakmaps to pass around (by wrapping
> a weakmap, etc.), but it makes security (aka code robustness) an opt-in and
> not the default.
> Opt-ins are cool, but are often forgotten, like CSP, like "use strict", like
> cookie HttpOnly, like HTTPS, you know the list :-) It would be cool if they
> were by default and people didn't have to learn about them all.
> Security by default is cooler in my opinion.
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss