The other side of the moon

There have been many additions to boomerang over the last few months. Among them include:

• Full navigation timing API support added by Buddy Brewer (@bbrewer)
• Measure IPv6 support and latency with the ipv6 plugin
• Measure the performance of "Instant Pages" in Google Chrome (v13+)

NavigationTiming

With the navtiming.js plugin, boomerang will beacon back the entire navigation timing object for browsers that support it (Chrome 6+ and IE 9+ and Firefox 6+ at this time). Use this information to gain far more insight into the user's browsing experience.

Docs here: http://yahoo.github.com/boomerang/doc/api/navtiming.html and here: http://yahoo.github.com/boomerang/doc/howtos/howto-9.html

IPv6

World IPv6 day is past, but IPv6 support still isn't universal. The ipv6.js plugin will help you find out if your users can access content over IPv6 and how that latency compares to whatever you currently provide. This does require server side setup though.

Docs here: http://yahoo.github.com/boomerang/doc/api/ipv6.html

Instant Pages

Google Chrome 13 has taken Mozilla's prefetch technology to the next level, introducing "prerender" -- a method to download and render the most likely next page before the user clicks on it, giving the appearance of the page loading Instantly when the user does click.

Boomerang is now prerender aware, and will check to see if a page was loaded through prerender or not. If it was, then boomerang measures a few more interesting times like the actual load time, the perceived load time, and the time from prerender completing to the page becoming visible.

Caveat: The measurement code causes current builds of Chrome 13 to crash. This bug appears to have been fixed in the nightlies (Chrome 14 Canary).

Docs here: http://yahoo.github.com/boomerang/doc/howtos/howto-10-page%231.html

I was recently pointed to scrumy.com by a group that wants to use the scrum agile method. A quick look around the site showed that they were doing a lot in JavaScript. In particular, they took the name of the current scrum (or sprint if you prefer) from the URL and wrote it into the HTML, JavaScript and a few URLs. So, if your sprint were named hello-dolly, your URL would be http://scrumy.com/hello-dolly/

Here's the sad part... they almost got their filtering right. When written into the HTML, they correctly encoded used HTML entities and when written into URLs, they correctly URI encoded the data. They even did this for URIs that were written into JavaScript variables.

Where they didn't encode, was a JavaScript variable not used in any of these contexts. A small part of their JavaScript for the hello-dolly example reads like this:

window.projectName="hello-dolly";

Change the URL to http://scrumy.com/%22%3balert(0)%3b%22 and this is what gets written into the page:

window.projectName="";alert(0);"";

Resulting in an XSS.

Now I only looked at a single page on the site, so can't comment on whether there are more holes or not.

I emailed them as soon as I found the bug and a few hours later it was fixed. Good job folks!