Weak event listener
brendan at mozilla.com
Wed Mar 27 18:09:57 PDT 2013
Sam Tobin-Hochstadt wrote:
> > Changing the disagreement to be about JS vs. its impls is off the
> mark. Can you re-defend enumerability of weakmaps now that I've
> pointed out the security risk does not apply only to SES users, to be
> addressed by SES removing the @iterator?
> I don't think this is quite the right equation.
I didn't mean to equate anything, but the issue in this thread that I
was getting back to was observable lifetimes through weak map enumeration.
> What Dion's attack shows is that conservative stack scanning, when
> combined with any ability to observe GC, will leak some information
> about the addresses of objects. This can almost certainly be
> generalized to any conservative scanning.
> I also think that JS will inevitably need some method for GC-sensitive
> references, and this shows that combining these with conservative GC
> tech is risky. That may well be a reason to be more careful in the
> design of weak references, and to delay shipping them until engines
> improve. But I think the real lesson is that engines need to be on
> notice that conservative GC is a potential security risk, rather than
> a cost that the language has to bear forever. Fortunately, it seems
> that other incentives are already pushing engines toward precise GC.
It's true that conservative scanning is on the outs, sometimes as a
matter of principle (David Ungar one remarked to me that he did not
consider conservative GC to be real GC). But engines do it and ECMA-262
does not rule it out.
What makes conservative scanning troublesome, in the present case, is
the design of weak maps as implemented in Tamarin (AS3 was the target
My conclusion is different from yours, which I suggest is unfairly
biased against conservative GC :-). I say we need careful weak ref
notification (end-of-turn with an empty stack may be sufficient), and
*no* enumeration of weakmaps. And that last conjunct is what David was
More information about the es-discuss