Removal of WeakMap/WeakSet clear
michalwadas at gmail.com
Wed Dec 3 09:10:31 PST 2014
The same argument can be used for removing array.length setter - some code
can remove all entries from array important for your application.
Maybe we should think about WM methods .clone and cloneInto(otherWeakMap).
3 gru 2014 18:04 "David Bruant" <bruant.d at gmail.com> napisał(a):
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss