On Wed, Mar 12, 2014 at 5:04 PM, Fitzgerald, Nick
> On 3/12/14 2:40 PM, Brian Slesinsky wrote:
> > Interesting. I think the sticky part will be providing the
> > getLocals(), getDisplayValue(), and eval() functions. I think it's
> > by the compiler, since this allows a lot of flexibility. But which
> > to? I think it would have to be a sandbox of some sort and there may
> > be security implications for curious developers who run untrusted code
> > with the debugger window open.
> I was imagining it would run in the frame the debugger was paused in.
However that means the debugger's view of things could possibly be broken
by someone monkey-patching a prototype in the web page itself (or possibly
by an extension changing something). A debugger or a debugger plugin should
work even when things have gone very wrong in the program being debugged.
But it's hard to write code sufficiently paranoid to work in any
> Perhaps I am missing something, but if you are already running a site's
> code, why would they need to send the bad stuff via the debugging
developers wouldn't suspect it, which sounds like an interesting target for
It would be a problem if it somehow ran with higher privileges than the
code being debugged. For example, suppose the debugger called the plugin
code when it's looking at the local variables of a function that's running
in an iframe that came from a different origin? Now we have an interesting
way to get around same-origin restrictions.
So I think running each compiler's custom code as a separate low-privilege
extension makes the most sense, both to protect it from outside
interference and to make sure it can't do anything malicious.