Mark S. Miller
erights at google.com
Tue Jun 12 04:20:01 PDT 2012
On Tue, Jun 12, 2012 at 9:17 AM, Brendan Eich <brendan at mozilla.org> wrote:
> 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
>>> 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?
Yes, that's the kind of thing I have in mind. Perhaps an @privileged?
> 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.
I'm not yet arguing that or the opposite, rather, I'm confused about
what "non-strict-only" means in this context. Actual stacks consist of
a mixture of strict and non-strict activations. How would the proposed
API deal with that?
> 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?
yup. JS is an amazingly reflective language. We've taken care in both
the ES5 and ES6 efforts that all reflective operations uphold the ocap
security of strict functions -- so far without needing a special
@privileged module. getStack and makeWeakRef are the first reflective
operations that do require some such privilege separation.
Given an @privileged module and a desire to inspect the arguments of
non-strict activations, we should consider whether @privileged should
also grant the ability to inspect the arguments of strict activations.
Is @privileged per global context (frame)? If so, does it only provide
privileges over objects from that same global context? Or is it more
like browser chrome js vs page js, where special chrome privileges
apply to all page js objects it encounters? Might we eventually
standardize a module that provides all the privileges needed to
implement a portable debugger? Is it appropriate for the language to
define multiple kinds of privilege-granting modules, or should the
language delegate this to the host?
More information about the es-discuss