Weak event listener

Brendan Eich brendan at mozilla.com
Wed Mar 27 18:47:56 PDT 2013

Sam Tobin-Hochstadt wrote:
> However, I think this demonstration makes a much stronger case against
> conservative GC.  Dion's attack requires, fundamentally, three things:
> 1. Conservative GC (of any form).
> 2. Some data structure that the browser holds weakly if at all, but
> can be held strongly from JS.
> 3. Some way to tell if that data is collected.
> I think that there's no way to eliminate 2&  3 from the browser.  For
> example, 2 could be a large array, and 3 could be a `currentMemoryUse`
> function (which doesn't currently exist, but might).

Such a currentMemoryUse function would not be easy to standardize, just 
on interop and complexity of implementation grounds, if not on the 
"liveness channel" attack.

But you are right in general: Dion tried a weakmap timing channel 
attack, since SpiderMonkey's WeakMap is based on doubling a HashMap when 
it fills to a certain load factor. However, he couldn't get that attack 
to work.

These channels may be noisy. The problem with weak refs with prompt 
notification, or enumerable weakmap, is that those leak much more 
precise liveness info.

Security is always like this, a set of cross-cutting (non-modular) 
properties -- safety properties in Fred Schneider's formulation 
(predicates over all future program states). So I don't see how we can 
look at conservative GC with an evil eye but not look at other parts of 
the system.

Let's say we ban conservative GC as part of ECMA-262's normative 
language. We still have interop and capability or "authority" problems 
with enumerable weakmaps. Those are not concerns only for SES.

I agree conservative GC makes the system more vulnerable, since (2) 
happens (even if under the hood, but in ES6 code "above the hood"), and 
(3) is an endless stream of weaknesses and hard-to-close channels.


More information about the es-discuss mailing list