Standard JS debugging API

[Erik Arvidsson]

I don't see how this would help me debug Gmail and Google Maps for example.

On 4/28/07, Daniel C. Wang <danwang74 at gmail.com> wrote:
> I would much rather have a standard hook that lets me intercept
> javascript before it's executed. You can  expose the javascript syntax
> tree encoded as JASON, or just give people a string representing of the
> code that's  going to be executed. This would let you write a generic
> debugger that worked via dynamic instrumentation, and also have an
> official way to implement the following approach to avoid XSS attacks.
>
> http://www2007.org/paper595.php
>
> * Paper Title:*
> Defeating Script Injection Attacks with Browser-Enforced Embedded Policies
>
> * Authors:*
>
>     * Trevor Jim (AT&T Labs Research)
>     * Nikhil Swamy (University of Maryland)
>     * Michael Hicks (University of Maryland)
>
> * Abstract:*
> Web sites that accept and display content such as wiki articles or
> comments typically filter the content to prevent injected script code
> from running in browsers that view the site. The diversity of browser
> rendering algorithms and the desire to allow rich content makes
> filtering quite difficult, however, and attacks such as the Samy and
> Yamanner worms have exploited filtering weaknesses. To solve this
> problem, this paper proposes a simple mechanism called Browser-Enforced
> Embedded Policies (BEEP). The idea is that a web site can embed a policy
> inside its pages that specifies which scripts are allowed to run. The
> browser, which knows exactly when it will run a script, can enforce this
> policy perfectly. We have added BEEP support to several browsers, and
> built tools to simplify adding policies to web applications. We found
> that supporting BEEP in browsers requires only small and localized
> modifications, modifying web applications requires minimal effort, and
> enforcing policies is generally lightweight.
>
>
> Erik Arvidsson wrote:
> > I'm just forwarding this from an internal company mailing list:
> >
> > Short version:
> > JS/ECMA should have a standard interface that JS-VM writers can
> > implement, so that third-party tool-vendors can write debuggers that
> > will work for any browser (or other JS-VM host) that supports this
> > debugging interface.  This would create a market for debugger
> > products, and would make web development much more attractive than it
> > is today.
> >
> >
> > Long version:
> > There are lots of JS debugging tools, like Firebug, Venkman, IE script
> > debugger, JS shell, Safari's new Drosera, etc.  I believe each is
> > tightly coupled own JS VM.
> >
> > Java doesn't have a debugger UI, but it has a low-level debugging
> > interface, wire protocol, and high-level interface:
> > http://java.sun.com/j2se/1.4.2/docs/guide/jpda/architecture.html.
> > Each JVM vendor (Sun, IBM, whatever) implements the debugging
> > interface, without worrying about the debugging UI.  Tool developers
> > (Eclipse, IntelliJ, CodeGuide, etc) write debugging UIs that can debug
> > on any such JVM on any machine, locally and remotely.
> >
> > The API includes stuff like adding and removing breakpoints and
> > watchpoints, execution control, an event system, queries, callstacks,
> > all the standard stuff.
> >
> > That seems like a really good model.  But as far as I can tell,
> > there's not even a proposed spec for a standard JS debugging
> > interface.  Having such a standard spec, and a reference
> > implementation, would make web development much more attractive.
> > [snip]
> >
> >
>
>


-- 
erik