Google Web Accelerator offers web developers an important opportunity

Tom Moertel — Fri, 06 May 2005 21:55:00 -0400

Google Web Accelerator offers web developers an important opportunity There has been a lot of heat lately about Google’s Web Accelerator (GWA) exposing serious problems in some popular web applications. The problem, in short, is that these applications use GET-based links that when followed perform dangerous actions such as deleting records in a database. According to web standards going back a decade, that is a no-no: Links should be safe to follow. Thus GWA, expecting links to be safe, tries to help you out by pre-fetching various resources that are linked to by the pages you visit. Unfortunately, if the page you happen to be visiting contains lots of dangerous links, GWA will innocently try to pre-fetch the “resources” that the links point to, and in doing so will accidentally delete a bunch of stuff. Oops.

That’s the backdrop for our real story, which is the response from the community of web developers. What I find fascinating, and somewhat disheartening, is the number of people who say the problem is Google’s to fix. Yes, there are a lot of broken web apps out there, and Google could have been smarter about working around the minefields those apps represent. But that’s a side problem. The real problem is that there are a lot of broken web apps out there, and they do represent minefields. Worse, a lot of web developers think it is acceptable to brush aside fundamental conventions of the web going back a decade when they find it sexier to use GET instead of POST.

What these developers overlook is that the web is not a bunch of colorful pages with buttons, clickable links, and pretty pictures. Rather the web is a distributed collection of hypertext documents, each of which has a meaning that is given by standards that most people have agreed to follow. While the collection may look like a bunch of colorful pages in one particular visual presentation, it really, truly is not.

Nevertheless, many web applications are designed with the prevailing mindset that the meaning of the web is nothing more than how it looks and behaves in a web browser. Even if those web applications are not intended for use outside of a few approved browsers – the escape hatch that is often used to justify departures from the standards – this mindset is wrong.

The reason it is wrong is because, like it or not, web applications are implemented in terms of protocols and languages that mean something. The bits and pieces of a web application each mean something, even if what they mean is not in harmony with the designer’s overall vision. What a web designer may see as a bold, red link that says “delete” and is protected by a Javascript confirmation dialog, is actually a hypertext reference – a pointer to another resource that the standards say should not be dangerous to follow. Thus there is a fundamental mismatch between what the designer is trying to say – “follow this link only if you really, no-kidding want to delete something” – and what his markup actually means: “this link is safe to follow.”

The bottom line is that hypertext links are supposed to be safe. Dangerous links can’t be made “safe” by layering tricks on them. Wrapping them with Javascript confirmation dialogs doesn’t make them safe. This trick fails fundamentally because the meaning of a link doesn’t change when there is Javascript associated with it. It fails practically because not all consumers of hypertext evaluate Javascript, nor do any standards suggest that they should. (This is also why client-side validation cannot be trusted on the server side.)

Hiding dangerous links in authorization-controlled portions of a web application does not make them safe, either. This trick might shield the links from external spiders, but the standards allow for any number of intermediary agents (such as Google’s Web Accelerator) to work on behalf of an authorized user. Anything the user is authorized to do, so are the user’s agents. If the user can click the “delete” link, so can the agents.

Let’s answer the wake-up call.

GWA is only the first of a new breed of smarter user agents that promise to make the web a better place for all of us. If you’re a web developer, take the slew of problems that GWA uncovered as a wake-up call. Even if Google works around your problems, other user agents may not. As developers, it’s time to admit our mistakes and fix the stupid things that our web applications do.

First, let’s drive a stake in the notion that dangerous links are OK if we’re “careful.” They’re not. Dangerous links are lazy. “Confirming” them with Javascript or “hiding” them behind authorization doesn’t work.

Second, let’s clean house. Let’s find those places where we have laced our web applications with dangerous links and remove them. Break out the forms! Long live the POST!

Third, let’s take a look at how we got into this mess and try to learn from our mistakes. Do we value sexiness more than substance? We like to think that form follows function and that good design and good implementation go hand in hand, but the reality of this debacle suggests otherwise. I think the truth is that on the web, sexiness and hype are what gets attention, and we seek attention more than we like to admit.

Maybe the best thing for us is a good dose of humility. And, come to think of it, that’s just what Google’s Web Accelerator offered us.

Tom Moertel's Weblog: Google Web Accelerator offers web developers an important opportunity

Google Web Accelerator offers web developers an important opportunity

Let’s answer the wake-up call.