Standard JS debugging API

[Brendan Eich]

On Apr 29, 2007, at 4:54 PM, Erik Arvidsson wrote:

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

It would be the long way 'round, and very expensive. It would hit  
every page load performance test that encounters scripts. There's no  
free lunch, and normally no call to retain ASTs (represented in JSON  
no less).

A set of standard interfaces based on existing debugger APIs is  
probably something we could standardize -- after ES4.

/be

>
> 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
> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss