Please be aware however that auto-updating is not yet implemented, so if you want to keep up with changes to the extension you’ll have to subscribe to the blog, or keep an eye on that page until it is. Once I have auto-updating sorted I’ll put the extension on http://addons.mozilla.org.

I want to thank Steve Souders for his work on YSlow. His documentation in the YSlow code was one of the major things that helped me get this project as far as it is. I hope to help continue improving the rather abysmal state of Firebug documentation so other people can create more extensions to what is one of my favourite web development tools.

Technorati Tags:
yui, yui event lister, firebug, yahoo, web development, debug, yslow, steve souders, firefox, mozilla, javascript, events, bookmarklet

In order to get something like the functionality in the accessibility toolbar for YUI Event library listeners I’ve made a bookmarklet that uses some of the functionality of the YUI Event library. The YUI Event List Bookmarklet will show you a list of all the elements on the page that have listeners attached and what those listeners are. You can also view the functions that will be called when the event fires. It’s perfect for tracking down that elusive listener that’s using event propagation to hook onto stuff.

Technorati Tags:
yui, javascript, yahoo, web development, event listener

The reason I find this interesting is because of a conversation we had a my work about how to optimise some AJAX by using either an XML data source or a JSON one. The discussion about the best way to deal with parse trees in the browser made me wonder if most of the “Web 2.0″ site really need it at all.

The implementation of AHAH I like is one which wraps some HTML in a JSON object along with a status code. The application then requests data to render, using the status code to define how it renders it, either as a valid return or as an error. This minimal logic approach avoids the parsing and speed issues on the client, and instead makes the optimisation barrier the HTTP request and the server response time.

I would say that in all but the most hyper-functional of applications the amount of interaction a user does, with the amount of data the server can return in a given request means that this option is most preferable. Really only the spreadsheet, datagrid, etc type application can anticipate the data the user will need next and in volumes to justify using AJAX in it’s purest form.

Technorati Tags:
AJAX, JSON, Javascript, AHAH

According to the article Google allowed someone to gain control of pages on a sub-domain of google.com. Aside from the obvious dumbness of allowing that to happen (surprising given the usual calibre of their people) it raises an interesting point about cookies. Tony Ruscoe was able to gain control of another Google user’s account by having the victim visit the compromised ghs.l.google.com page and reading all his Google cookies with Javascript. He then used the victim’s cookies as the authentication tokens he needed to access the victim’s account himself.

This implies to me that we, as web developers, make some assumptions about trust with the user agent. We assume any user agent with the correct authentication tokens is trustworthy. However, this is obviously not the case. My thought is that when we issue tokens we should look at other factors which isolate one computer from another. The obvious one would be location.

For example, when an HTTP request comes in, we need to know where it came from in order to send a reply. Since we know the IP address of the originating computer (or at least it’s primary upstream NAT address) then why not look all session based authentication to that? In the example above this would have caused the authentication tokens to have failed from the compromised browser because the token was being used from an invalid location. This assumes that your authentication tokens are encrypted to stop tampering, but I would really hope they are anyway.

It wouldn’t be 100% fool proof (what is?), but it would reduce the attack vectors considerably. To compromise a user, the attacker would have be attempting to use the cookies from the same computer (if they can do that, they could probably steal the cookies straight off the hard drive), from the same NAT (not much to do about this case), or have a compromised router some place. If they did have a router upstream from either Google or the victim they could capture the cookies on-route anyway in a regular request. One simple thing would reduce a lot of issues.

Would this cause any problems with users? I don’t think so. The changes associated with an IP address tend to be physical anyway, a different computer, a changed wireless lan connection, etc. In this context it actually makes sense to a user to re-authenticate when they move. The physical aspect is important to help users understand the reason why they are having to authenticate a new access token.

Technorati Tags:
Security, Javascript, cookies, google

While it is well known that it is possible to exploit the return of a JavaScript array, I've been trying to establish if it is also possible with generic objects conforming to the JSON standard.

This is the example JSON provided by json.org. If you encapsulate this directly in <script> tags then browsers will throw an error.

I have tried to overwrite the object constructor in all the major browsers. None of Yahoo's A-grade browsers will call the constructor for these object returns, because of the object exception.

I have come to the conclusion that browsers parse { } because as a script block not an object, but will not parse an actual object without a label. Tim and I were talking about this and agreed that the parser allows [] without a label for the construction of anonymous arrays to make multi-dimensional arrays. Good thinking Batman Tim!

What does all this mean? In effect that means that using a JSON return in as per the example wrapped in { } means it can't be used for XSS. Using a simple array return is still as vulnerable as ever.

Technorati Tags:
AJAX, JSON, Security, Javascript

Whoops! I don't do Firebug enough credit. Just click on the 'script' tab and select 'Break on all errors' in the options menu. Now it breaks on any and all errors. Sweet.

So I did (with a little help from Heilmann).

Here it is in all it's glory