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" <[email protected]> napisał(a): > Le 03/12/2014 16:26, Jason Orendorff a écrit : > >> On Wed, Dec 3, 2014 at 8:35 AM, Andreas Rossberg <[email protected]> >> wrote: >> >>> (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 > proven. > > 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. > > David > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
