WeakMap and WeakSet: state explicitly that you cannot modify an entry if you have not access to the key

[claudepache]

Currently, WeakMaps and WeakSets have the following "privacy" feature:

If you have not reference to a key, you cannot read, modify or delete the corresponding entry.

However, that does not follow from the specced description of WeakMap or WeakSet; but a strictly weaker requirement is given, namely that a key could not be observed unless one is able to provide it. Indeed, this requirement is compatible with the addition of a .clear() method, which would violate the privacy feature.

As I understand, that privacy feature is wanted by some people; or even if it were not by design, some people will rely on it. So, I think it is important to state explicitly in the spec that the privacy invariant must hold.

/cc @erights

[rossberg]

Let me refute again the claim that clear would violate privacy/encapsulation in any relevant way. I have yet to hear a plausible argument for that. Invoking clear is gated on getting a reference to the map itself. Once you have that reference, there are various serious ways in which you can tamper with any privacy protocol it might implement (e.g. forging trusted values by adding them to the map), such that in untrusted hands, clear is probably the least of your problems.

[rossberg]

Let me refute again the claim that clear would violate privacy/encapsulation in any relevant way. I have yet to hear a plausible argument for that. Invoking clear is gated on getting a reference to the map itself. Once you have that reference, there are various serious ways in which you can tamper with any privacy protocol it might implement (e.g. forging trusted values by adding them to the map), such that in untrusted hands, clear is probably the least of your problems.

[erights]

@rossberg What do you mean by "forging"? In JavaScript, unlike C++, object identity is unforgeable. This is so obvious that I am confident you mean something else but I refrain from guessing what.

[erights]

@rossberg What do you mean by "forging"? In JavaScript, unlike C++, object identity is unforgeable. This is so obvious that I am confident you mean something else but I refrain from guessing what.

[rossberg]

@erights, what I meant is if e.g. a map/set represents a trademark (or a set of trusted or own instances, like e.g. in a membrane), then anybody with access to the map/set can "forge" trademarks or similar entries.

[rossberg]

@erights, what I meant is if e.g. a map/set represents a trademark (or a set of trusted or own instances, like e.g. in a membrane), then anybody with access to the map/set can "forge" trademarks or similar entries.

[erights]

Yes, for those use cases, access to the weakmap or weakset would be fatal. Nevertheless, weakmaps/weaksets do have the useful privacy property Clause quotes:

If you have no reference to a key, you cannot read, modify or delete the corresponding entry.
[replaced "not" with "no"]

I agree we should specify that. This property also aids local reasoning about programs. More "A cannot influence B" reasoning steps will be apparent.

[erights]

Yes, for those use cases, access to the weakmap or weakset would be fatal. Nevertheless, weakmaps/weaksets do have the useful privacy property Clause quotes:

If you have no reference to a key, you cannot read, modify or delete the corresponding entry.
[replaced "not" with "no"]

I agree we should specify that. This property also aids local reasoning about programs. More "A cannot influence B" reasoning steps will be apparent.

[rossberg]

Okay, I can see what you mean. this is a kind of separation property then. Abstractly, I can see this as a nice property, but concretely, I have a tough time coming up with a use case for JS. Separation makes sense if you need to establish encapsulation and all you have is some form of global state space. But for JS apps, why would they want to construct such a global space in the first place, instead of separate maps/sets? Do you have a concrete scenario in mind?

[rossberg]

Okay, I can see what you mean. this is a kind of separation property then. Abstractly, I can see this as a nice property, but concretely, I have a tough time coming up with a use case for JS. Separation makes sense if you need to establish encapsulation and all you have is some form of global state space. But for JS apps, why would they want to construct such a global space in the first place, instead of separate maps/sets? Do you have a concrete scenario in mind?