Non-extensible WeakMaps

David Bruant bruant.d at
Mon Jan 23 12:37:09 PST 2012

Le 23/01/2012 17:25, Brendan Eich a écrit :
>> David Bruant <mailto:bruant.d at>
>> January 22, 2012 12:54 PM
>> I'm not sure to understand what you're calling "/the/ key".
>> WeakMap.prototype, being itself a weakmap, does provide a covert
>> channel (since everyone has access to the same primordial objects
>> identities). Of course, it can be repaired [1], but it's quite
>> unfortunate to have to "repair" a feature that isn't part of a
>> standard yet, isn't it?
> Yes, you're right -- the prototypes require special handling for some
> of these classes. We've talked about this at past meetings. It's
> unfortunate that in JS, a prototype is not instanceof the objects of
> its kind.
> There is a tension between making prototypes be blank Object instances
> and making them as if they were the first of their kind. For the
> built-ins, we did the latter up till ES3, where RegExp.prototype was
> spec'ed as Object. No implementation followed that part of ES3, and
> ES5 matched reality.
> We would like a principled way for built-in constructors that have
> such covert channel hazards to opt out of their prototype being of
> their kind.
Can you elaborate on this last point? Do you mean a run-time way?
Does "opt-out" mean that the default would be that Constr.prototype is
always an instance of Constr?
It's been standardized this way to match reality, but it doesn't mean it
was a good design decision. It's not too late to change this.

A "spec" principle could be that no new built-in (any built-in, not just
the Constr.prototype) provide an irrevocable access to a shared mutable
"built-in" here, actually refers to anything 2 scripts can irrevocably.

Mutable state of objects available to everyone are almost systematically
a source of covert chanel. It's true for Date.prototype,
WeakMap.prototype, Map.prototype, etc.
2 scripts having access to the same built-ins and these built-in having
a mutable state is what starts troubles.

For the record, this rule (no irrevocable access by default to objects
with mutable state) was applied in the design of Joe-E [1], a subset of
Java designed to allow object capabilities.

>>> For Maps and Sets, which support enumeration, the threa[t] model is
>>> different.
>> Allowing any type to be a key also changes the threat model, because it
>> means that prior arrangement can be enough to communicate.
> True but it's only with such arrangement, which would be a different
> kind of bug from any in the case where a key could be forged. In the
> forged key case, there's no defense.
I think that wrapping the object in a proxy and passing this proxy can
save from pretty much any situation. Just an intuition.
It assumes that the party I want to give access to an object via a proxy
doesn't already have access to it (if it's global for instance).



More information about the es-discuss mailing list