What is the status of Weak References?

Mark S. Miller erights at google.com
Thu Jan 31 20:11:02 PST 2013

Earlier today I discussed with Arv an approach for doing WeakRefs without
compromising security. (FWIW, I also posted this in my message near the end
of <https://groups.google.com/forum/m/?fromgroups#!topic/nodejs/fV8MDpkBauw>.
Thanks to Rick for the pointer.)

When a WeakRef from Realm A points at an object from Realm A, it points
weakly. When it points at an object from another Realm, it points strongly
(or throws an error -- take your pick). Within a Realm, SES can do what E
has always done -- treat the makeWeakRef function as privileged, not to be
made available by default to non-privileged code within that Realm (much as
we already do with document, window, XHR, etc). The problem is that SES is
not in a position to police other Realms, and we had not known how to solve
the cross-Realm problem. This restriction prevents the cross-Realm leak.

Arv and I came up with a nice refinement: when dealing with another Realm,
if you can obtain the makeWeakRef for that Realm, then you can use it to
point at its objects weakly. If you obtain makeWeakRefs for several Realms,
perhaps it makes sense to provide a makeWeakRef combiner that makes a
composite makeWeakRef function, which will point weakly at any of the
Realms of the leaf makeWeakRef functions. However, I think this is a
detail. Virtually all use cases of interest only need to point weakly
within a Realm.

On Thu, Jan 31, 2013 at 2:37 PM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:

> We have yet to find a solution that does not leak information between
> two actors that are not supposed to be able to communicate. At this
> point we have a lot of important work to do for ES6 and until someone
> comes up with a solution to the security issues WeakRefs are
> postponed.
> I'm not an expert in this field but I can try to explain the problem
> as I understand it.
> - Given a master actor M that can communicate with two independent
> actors A and B (but A cannot communicate with B).
> - M passes a frozen object O to A.
> - A then creates a WeakRef for O.
> - A also strongly holds on to O.
> - M then passes the same object to B.
> - B creates another weak ref to O.
> - Now B will get notified when A stops holding strongly to O leading
> to a communication channel.
> It is possible that we can accept this information leak and just have
> Caja etc blacklist use of WeakRefs but this is a discussion that we
> decided to postpone for now.
> On Thu, Jan 31, 2013 at 1:55 PM, Tab Atkins Jr. <jackalmage at gmail.com>
> wrote:
> > On Thu, Jan 31, 2013 at 1:48 PM, Kevin Gadd <kevin.gadd at gmail.com>
> wrote:
> >> A search shows some old discussions of the topic mentioning that they
> >> might be going in to future versions of the language, etc. But on the
> >> other hand I've been told in response to this question before that
> >> TC39 has a general policy against features that allow garbage
> >> collection to be visible to applications.
> >>
> >> There's still a strawman up on the wiki:
> >> http://wiki.ecmascript.org/doku.php?id=strawman:weak_references and
> >> while it appears to be a relatively simple, sane way to expose weak
> >> references, it looks like the strawman hasn't been touched since late
> >> 2011. Is that because it's dead? Or was it deprioritized because weak
> >> references are believed to not be needed by JS application developers?
> >
> > I believe that proposal was dropped in favor of just always using
> WeakMaps.
> >
> > ~TJ
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> --
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

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

More information about the es-discuss mailing list