Weak References

Mark S. Miller erights at google.com
Sun Sep 6 16:11:13 UTC 2015

On Sun, Sep 6, 2015 at 3:37 AM, Gary Guo <nbdd0121 at hotmail.com> wrote:

> I think weak references are discussed before, and get postponed because it
> can cause information leaks between realms.

http://wiki.ecmascript.org/doku.php?id=strawman:weak_refs#security says

To plug this leak, a weak reference created within realm A should only
> point weakly within realm A. When set to point at an object from another
> realm, it should either point strongly or throw an error, depending on
> whether a surprising leak or a surprising error is expected to be more
> inconvenient for the caller. Security demands only that such inter-realm
> references not point weakly.

This requires an object model change: functions are already specific to
their realm of birth. This solution to the information leakage problem
requires that all objects that could be weakly pointed to are already
specific to the realm of their birth. Many implementations already do the
necessary bookkeeping to keep track of an object's birth realm, but we
would not need to mandate that bookkeeping and include it in the object

> See https://mail.mozilla.org/pipermail/es-discuss/2013-January/028542.html for
> a nice refinement for pointing weakly at objects from a set of realms.

Since then I have come to the opinion that an inter-realm weak reference
should silently point strongly, not throw an error.

The other security issue is how to make the WeakRef constructor available
at all within a realm, since it should not be available to unprivileged
code within a defensive realm. At

The loader is the third example of an (existing or proposed) primordial
> object that does grant authority:
>    - The global object, for which we rejected Reflect.global for the same
>    reason.
>    - The proposed WeakReference factory (e.g., WeakRef or makeWeakRef)
>    which makes GC observable, opening a covert channel. This is why we
>    carefully separated WeakMap from any notion of WeakRef.
>    - The default loader, which causes external I/O and internally has a
>    mutable mapping from module names to mutable module instances.
> We do need a good way to provide standard access to authority-providing
> primordials such as these. In particular, I think all three of these are
> well motivated and should somehow become standard. But, because they
> provide authority they should be clearly separated from the means of
> providing abstractions that are safely sharable.

>From the way the discussion proceeded, it seems an acceptable place to put
these is on a global System object, i.e.,




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150906/52774526/attachment.html>

More information about the es-discuss mailing list