Error stack

Brendan Eich brendan at mozilla.org
Mon Jun 11 18:17:24 PDT 2012


Mark S. Miller wrote:
> On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich<brendan at mozilla.org>  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.

With some kind of

   import getStack from "@reflect";

or similar, and SES uses a custom loader to censor @reflect?

>> 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.

I thought so too, but Charles is arguing both (a) no worse than today 
(not better than today); (b) useful for people who prefer non-strict 
code and a more useful stack-tracing API in the core language.

This is a matter of preference, not necessity, if we're talking about 
the language as it is. We won't be making "use strict" the default. We 
are trying to avoid more modes (1JS). We're not talking about SES. So I 
don't see how it can be argued logically that a non-strict-only 
arguments-disclosing stack-tracing API is either never helpful nor 
always helpful. YMMV.

>> 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<http://wiki.ecmascript.org/doku.php?id=strawman:weak_references>:
>> 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.

I see -- thanks. We should try to detail the privileged APIs and their 
module(s) a bit more. I used "@reflect" above but I didn't mean to 
equate it to Tom's Reflect.* used in conjunction with direct proxies. 
And not all reflection facilities are privileged -- more the reverse for 
the direct proxy stuff, right?

/be


More information about the es-discuss mailing list