What is the status of Weak References?

Kevin Gadd kevin.gadd at gmail.com
Thu Jan 31 14:57:49 PST 2013

Thank you for the detailed explanation of the information leak - I had
never seen an explanation of why GC visibility creates an issue.

Is there a page on the wiki somewhere that explains why information
leaks are such a huge concern in JavaScript? I've never been under the
impression that it is designed to be a secure/sandboxed language - I
always was under the impression that for such uses you would need a
layer like Caja.

Postponing work on Weak References due to an information leak feels to
me like prioritizing theoretical security concerns over the real
usability/implementation obstacles for existing applications that need
a weak reference equivalent. Those applications will stay outside the
domain of JS (in something like Native Client or the JVM instead)
until it is available, or at best, end up as worse-performing JS
applications that don't actually leverage any large part of the JS API
and spec that you guys work so hard on. I have to imagine that's not
the case though and these security concerns are a real pressing issue
for a subset of the JS userbase I don't know about?


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

More information about the es-discuss mailing list