On Tue, Jun 12, 2012 at 9:17 AM, Brendan Eich <bren...@mozilla.org> wrote: > Mark S. Miller wrote: >> >> On Tue, Jun 12, 2012 at 7:38 AM, Brendan Eich<bren...@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?
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? -- Cheers, --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
