On Tue, Jun 12, 2012 at 10:14 AM, Charles Kendrick <char...@isomorphic.com> wrote: > On Mon, Jun 11, 2012 at 5:55 PM, Mark S. Miller <erig...@google.com> wrote: >> On Tue, Jun 12, 2012 at 7:59 AM, Charles Kendrick >> <char...@isomorphic.com> wrote: >>> I'm reading this as saying that stack traces in general should not be >>> available unless the code is privileged in some way. This can't be >>> what you mean, so could you clarify? >> >> That is exactly what I mean. > > The only way I can see this working is if there is a way for a given > piece of code to trap an error and ask some kind of (elevated > privilege) logging system to provide diagnostic information that a > (privileged) end user can see.
I'm not sure what you mean by "trap to an error", but the rest of your description seems close to how SES's console.log, console.warn, etc work. They are endowed with access to the privileged getStack function and use it to display stack traces on the console's output. See http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#28 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/logger.js#157 http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/useHTMLLogger.js#116 We assume that unprivileged code generally has no way to read the console's output. > It also seems like, in addition to > this, you should be able to get to stack information programmatically > so long as you stay within your module or modules that have the same > privilege. If we're talking about code with some privilege to see some stacks, why not reify such privilege in a getStack function importable from some @privileged module? If you don't reify this distinction, then you're suggesting above that an access be dependent on the module from which the access is directly made. What if the access is made indirectly through some intermediary? Does it then fail, even though all other accesses can be delegated to the same intermediary? If the access is simply a property access, function intermediary(base, name) { return base[name]; } defined in some other module. > This doesn't sound like something that could be reasonably > standardized into ECMAScript in the near future, and, without all > those pieces in place, it doesn't seem like ECMAScript should just > disallow the ability to get stack traces. In this thread, we've already considered APIs other than ".stack". Given anything else, why is getStack(err) is any worse than introducing a novel property name? Regarding near future, any such proposal -- whether ".stack", getStack, or whatever -- has already missed the boat for ES6. getStack certainly could be considered in an ES7 timeframe. > Brendan brought up SES - I know little about it, but for its sake I > hope this critical use case is taken into account. Yes. The code I link to above dates from February. > On Mon, Jun 11, 2012 at 6:17 PM, Brendan Eich <bren...@mozilla.org> wrote: >> 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. > > Just to clarify, I prefer *some* of the ideas behind "use strict" and > in fact we built a subset of "use strict" into our in-house tools long > before JSLint existed. > > But if it's going to impose a security boundary between my own methods > and reduce the utility of stack traces which are sometimes the only > thing you have to go on.. no thank you. That seems to me to conflate > useful error checking and security; there is overlap, but not 100% > overlap by any means. How do getStack and @privileged reduce the utility of stack traces? Regarding access to arguments, depending on how much privilege @privileged should give (see questions at end of my previous email), it is conceivable that it should give access to strict arguments as well. Or that there be an @turbo_privileged that grants this additional level of access. Until we have some experience using the module system on both browser and server, these issues are hard to think about. -- Cheers, --MarkM _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
