On Sat, Mar 9, 2013 at 4:56 PM, Kevin Gadd <kevin.g...@gmail.com> wrote:
> I really don't understand why the debugger thing is being trotted out > again. It was addressed at the beginning of the thread: There are lots > of real world applications that use debugger-style introspection (in > particular, stack walking) for purposes that are not debugging. > > Now, to be fair, that may not justify exposing any of those features > if the security threat posed by having introspection is so incredibly > dire. But 'just use a debugger API' isn't really a solution for any of > these applications. Debugger APIs are heavyweight and usually have > tremendous performance consequences, preventing their use for solving > Application Problems. Another way to view the phrase "debugging API" is "properly stratified privileged reflection API". Indeed, the famous Mirrors paper used JPDA as an example of a properly stratified reflection system. The key thing about debugging APIs is they get the privilege separation right -- because they must. A well designed mirror system or mirror-like system could as well. I have discussed this repeatedly with the co-authors of that paper -- Dave Ungar and Gilad Bracha (cc'ed) -- and IIRC they enthusiastically agree. The KeyKOS operating system had an operation for rights-amplifying a "start key" or "resume key" to a "domain key". In our terms, a start key is like a closure reference and a domain key is like a reference to the reified lexical environment captured by that closure, i.e., a mirror on the state of that closure. A resume key is like a continuation, so reflecting on resume keys -- if you have the privileges needed to do so -- enables one to effectively walk back the stack of outstanding IPC requests. The logic by which KeyKOS (and its descendants EROS, CapROS, GuardOS, Coyotos) managed the right-to-reflect could be a good starting point for doing likewise with language-based mirrors. This would be an excellent research topic for someone to take on. If someone takes it on seriously, I may well be interesting in advising the effort. However, the work of TC39 is not the right place to do this kind of research (unless its crucial to an urgent goal, which this one isn't). Once such research bears fruit, we can then consider whether to take this to TC39 as a proposal for ESx, for some future x. > In reality, the answer will have to be 'you > can't do that in JavaScript', which probably isn't the end of the > world since that's the current answer to anything that needs weak > references. > I expect to propose weak references for ES7. I think I have an adequate answer to the security issues that took this off the table for ES6. More later. > > -kg > > On Sat, Mar 9, 2013 at 4:54 PM, Andrea Giammarchi > <andrea.giammar...@gmail.com> wrote: > > I do NOT want to write a debugger and yet I need caller, can you imagine > ? > > > > Andrea > > > > > > On Sat, Mar 9, 2013 at 10:44 AM, David Bruant <bruan...@gmail.com> > wrote: > >> > >> Le 08/03/2013 22:19, Andrea Giammarchi a écrit : > >> > >>> This opens doors to debuggers (introspection) and APIs magic quite a > lot. > >> > >> If you want to write a debugger, use a debugger API [1] which is only > >> executed in privileged environments, no? > >> > >> Debuggers are useful, but pierce encapsulation which is useful for > program > >> integrity. I don't think making a debugger API available to all > programs is > >> a good idea. > >> > >> David > >> > >> [1] > >> > https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Guide > > > > > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > -- > -kg > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
