Error stack

Mark S. Miller erights at
Mon Jun 11 16:51:39 PDT 2012

On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich <brendan at> wrote:
> Also, as you pointed out, even error.stack leaks information. Where do you
> draw the line?

Conservatively. I suggest that there be no error.stack, but rather
getStack(error), in order to avoid this information leak.

> I think Charles was arguing that anyone keeping secrets would need "use
> strict" to protect those secrets anyway, because otherwise
> arguments.caller.arguments[i] (given non-strict caller and callee) can get
> them.

Non-strict functions should not be assumed to be encapsulated, so it
would be ok if they leaked info in yet more ways. However, a stack
consists of a mixture of strict and non-strict activations, so I don't
see how this helps.

> This is a good argument for Error.getStack(errObj), indeed.

Not Error.getStack. Error is generally available, so if the amplifier
were Error.getStack, it would be generally available too.

This leaves open the question of where to get things that are not
generally available. I hope and expect that we can find good answers
in the module system. The getStack amplifier should be obtained by
importing a module that is not generally importable. We've already
encountered the need for such privileged imports...

>From <>:
> Pending an accepted modules proposal, we do not yet specify in what namespace this
> constructor [makeWeakRef] is found. Note that makeWeakRef is not safe for general
> access since it grants access to the non-determinism inherent in observing garbage
> collection. The resulting side channel reveals information that may violate the
> confidentiality assumptions of other programs.


More information about the es-discuss mailing list