WeakMaps question ?

Mark S. Miller erights at google.com
Sat Nov 12 15:37:02 PST 2011

On Sat, Nov 12, 2011 at 11:56 AM, Brendan Eich <brendan at mozilla.com> wrote:

> WeakRef != WeakMap, we keep running into confusion between the two.
> WeakRefs are useful for systems-builders. They should not be exposed to
> unprivileged code. Is there an object-capability security model that would
> work on the web, by which "frameworks" with some higher degree of trust
> could be introduced to WeakRef as a capability, while ordinary web content
> could not access WeakRef at all? I don't know of such a model, but perhaps
> Mark has ideas.

Allen and Brendan are exactly correct about the distinction. I did write a
WeakRef strawman at <
http://wiki.ecmascript.org/doku.php?id=strawman:weak_references>. The rest
of that strawman is not in great shape. Since it was never on the table for
consideration in the ES.next timeframe, I have not really maintained it.
Allen's message is in terms of "weak arrays" rather than individual weak
references. Experience with Smalltalk suggests that this may make things
much lighter on an implementation without any significant inconvenience for
the normal uses cases. Allen can explain this further if he wishes. This is
a difference in how things are aggregated, rather than any real difference
on fundamental issues.

In agreements with Brendan's next point, that strawman says:

Note that makeWeakPtr is not safe for general access since it grants access
> to the non-determinism inherent in observing garbage collection. The
> resulting side channel reveals information that may violate the confidentiality
> assumptions <http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics>
>  <
> http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics#confidentiality
> > of other programs.

Previous ocap languages have faced this issue <
http://www.combex.com/papers/darpa-review/security-review.html>, <
http://www2.fiit.stuba.sk/~kosik/tamed-pict.html>, <
http://www.hpl.hp.com/techreports/2006/HPL-2006-116.html>, and I think the
patterns discovered by their solutions can be adapted to the web. I do have
further thoughts about this starting with <
but I think I'll wait until I have a better feel for how the ES-next module
loaders should be used in practice before trying to sketch anything

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111112/0272a693/attachment-0001.html>

More information about the es-discuss mailing list