Removal of WeakMap/WeakSet clear

Katelyn Gadd kg at luminance.org
Wed Nov 26 09:33:03 PST 2014


Is there a detailed rationale for this somewhere? Making typical
applications pay the cost here for a specific security scenario seems
really bizarre to me. Clearing standard library data structures is an
incredibly common operation. If you want to ensure that someone can't
clear the map/set, shouldn't you be handing them an encapsulated
version of the data structure? This seems like a corner case that
shouldn't justify removing an important primitive.

If you have a clear method, the security problem seems solved by
wrapping it in an object or using a proxy to deny the ability to clear
(you hide the actual map/set, so it can't be cleared - you expose only
the operations you want to expose).

If you don't have a clear method, anyone wanting to clear the data
structure has to throw it away and allocate a new one. This has
significant disadvantages:
The new structure starts empty at a default size, so repopulating it
will have to grow the buffer multiple times - this is undesirable for
cases where you are reusing a single data structure to store state for
a long-running application.
The allocation adds to GC and memory pressure for a long-running
application that needs to clear data structures frequently. Were it a
lightweight data type this would matter less, but a typical map
instance with data in it can occupy a considerable amount of space in
the heap.
Being able to clear the structure now requires that all consumers have
support for replacing their reference(s) to the old map with the new
one. This makes it harder to maintain encapsulation because you may
have saved a reference to the map in a private property or within a
closure. Now you need to add accessibility points to everything that
might retain the map so that you can update the reference. Or, you
have to encapsulate maps and sets just to recreate the clear operation
that should have been there to begin with.

In either case, encapsulation or shielding the container behind a
proxy is necessary. I insist that the common case is the one that
shouldn't have to encapsulate, because optimizing for that case will
benefit the vast majority of web applications that use it and the
penalty to security-sensitive cases is small.

-kg


More information about the es-discuss mailing list