Standard JS debugging API
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.
-
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.
I don't see how this would help me debug Gmail and Google Maps for example.
On 4/28/07, Erik Arvidsson <erik.arvidsson at gmail.com> 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.
[snip...]
I think that if every ES4 implementation use Tamarin(avmplus) to run ES4/AS3 bytecode, then this is already covered no ?
here a sample ouptut from tamarin running the builtins (global.abc) in debug trace mode
D:\sources\opensource\Tamarin\sandbox>avmplus_sd -Dastrace 4 global.abc
33 AVMINF: MTHD global$init () 35 AVMINF: MTHD Object$cinit () 36 AVMINF: MTHD Class$cinit () 38 AVMINF: MTHD Function$/Function::emptyCtor () @ 0x03CD0000 41 AVMINF: MTHD Function$cinit () 41 AVMINF: MTHD Class/get prototype () @ 0x03CD0120 43 AVMINF: MTHD Class/get prototype () @ 0x03CD0120 46 AVMINF: MTHD Class/get prototype () @ 0x03CD0120 48 AVMINF: MTHD Class/get prototype () @ 0x03CD0120 50 AVMINF: MTHD Class/get prototype () @ 0x03CD0120 53 AVMINF: MTHD Object$/Object::_dontEnumPrototype (Function-35) @ 0x03CD0160 57 AVMINF: MTHD Object$/Object::_setPropertyIsEnumerable () @ 0x03CD0380 60 AVMINF: MTHD Object$/Object::_setPropertyIsEnumerable () @ 0x03CD0380 64 AVMINF: MTHD Object$/Object::_setPropertyIsEnumerable () @ 0x03CD0380 67 AVMINF: MTHD Object$/Object::_setPropertyIsEnumerable () @ 0x03CD0380 71 AVMINF: MTHD Function$/Function::emptyCtor () @ 0x03CD0000 74 AVMINF: MTHD builtin.as$0::MethodClosure$cinit () etc...
If Adobe indeed release the Flex SDK as open source, then having access to FDB (Flex Debugger) source would allow also to have an ES4 debugger or build your own.
But maybe I'm overlooking what can be done and/or what you're after.
On Sunday 29 April 2007 6:15 pm, zwetan wrote:
On 4/28/07, Erik Arvidsson <erik.arvidsson at gmail.com> 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.
[snip...]
I think that if every ES4 implementation use Tamarin(avmplus) to run ES4/AS3 bytecode, then this is already covered no ?
Why does that make sense? Unless you assume that ES4 will be significantly less successful than ES3, I can't see why this would be true.
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.
On 4/30/07, Alex Russell <alex at dojotoolkit.org> wrote:
On Sunday 29 April 2007 6:15 pm, zwetan wrote:
I think that if every ES4 implementation use Tamarin(avmplus) to run ES4/AS3 bytecode, then this is already covered no ?
Why does that make sense? Unless you assume that ES4 will be significantly less successful than ES3, I can't see why this would be true.
the way you turn your phrase make no sens...
I'm talking about the actionscript bytecode (~= ES4 bytecode) that already provide debug infos and hooks, and this can already be used in Tamarin and the Flex debugger, even if ES4 is not successfull it doesn't change the fact that this bytecode can already be debugged.
care to elaborate your comment ?
On Monday 30 April 2007 12:59 am, zwetan wrote:
On 4/30/07, Alex Russell <alex at dojotoolkit.org> wrote:
On Sunday 29 April 2007 6:15 pm, zwetan wrote:
I think that if every ES4 implementation use Tamarin(avmplus) to run ES4/AS3 bytecode, then this is already covered no ?
Why does that make sense? Unless you assume that ES4 will be significantly less successful than ES3, I can't see why this would be true.
the way you turn your phrase make no sens...
I'm talking about the actionscript bytecode (~= ES4 bytecode)
AFAICT, no bytecode specification has been proposed for ES4. Tamarin's internal representation of ES4 (and whatever debugging it provides from that) are only related to the problem of debugging ES4 in the wild insofar as it becomes a successful implementation in the marketplace.
that already provide debug infos and hooks, and this can already be used in Tamarin and the Flex debugger, even if ES4 is not successfull it doesn't change the fact that this bytecode can already be debugged.
Right, but that doesn't address what to me seemed the primary concern of the original note that Erik forwarded, namely that it would be desireable if all ES4 interpreters/runtimes provided a set of unified interfaces into this data.
That it can be done on Tamarin today doesn't imply that the problem of handling debugging across VMs is solved. If we expect ES4 to succeed, there will be (almost by definition) many more implementations than Tamarin.
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: 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]