22 May 2005
Google Web Accelerator Aftermath
In case you didn’t notice the recent fuss, Google Web Accelerator is a bit of software designed to speed up your web browsing by preloading, caching and compressing content through Google’s servers. Negative commentary was triggered partly by obvious privacy concerns and partly because it effectively ‘clicks’ every link behind the scenes (so it can look ahead and preload content), which can perform destructive actions in many web applications (e.g. if a link is used to delete something).
I’m highly skeptical of anything that centralises web browsing, but some of the coverage of the latter issue has been too harsh. Yes, Google needs to consider the problems more carefully and perhaps reconsider their approach, but software that prefetches linked pages has been around for years, as have proxy servers and spidering tools; any problems are due to web applications not playing safe. Everyone’s been getting away with building sites incorrectly because no one as prominent as Google has promoted a tool like this before.
If you’re a web developer, think of Google Web Accelerator as a wake-up call and check if you’re doing the following:
- Use forms for actions, not links
- Links are meant to be used for safely retrieving information. Use a form submitted via
POSTfor anything which alters the state of the site’s data. This can make page layout tricky at times, and I reckon most developers have broken this rule (I know I’ve let things like links for logging-out creep into some sites). Also try to make sure sites aren’t vulnerable to CSRF.
- Discourage caching of personalised content
- Once pages effectively go from being public to private (e.g. when someone logs in, even if it only results in their name being displayed), make sure you serve HTTP headers to control caching (the PHP manual entry for
headercontains an anti-caching code snippet).
- Disable prefetching where it may be problematic
- Pages prefetched by GWA and Mozilla are requested with an additional header included. If you still have risky pages, or just don’t like the idea of extra load and distorted access stats from prefetching, you can detect this header and refuse such requests, as Rails developers are doing. Alternatively, make sure everything is accessed over SSL (encrypted pages aren’t prefetched).
I suspect Google will modify the software to prefetch fewer pages (e.g. avoiding pages with query strings, links containing certain phrases, etc.), but sites still need fixing.