Security Fears Over Google Accelerator

Espectr0 writes "A software tool launched by Google on Wednesday that speeds up the process of downloading Web sites (covered recently on Slashdot) has caused some users to worry about their privacy. A ZDNet article discusses problems that users have been experiencing with the information that is cached by the software. On a Google Labs discussion group, one user said that 'I went to the Futuremark forums and noticed that I'm logged in as someone I don't know...'" Commentary also available on Signal vs. Noise and BlogNewsChannel.

Comments

Does this surprise anyone?

[Jailbrekr]

Its a caching proxy server for crying out loud. It caches web pages and feeds you the cached version. This is not new nor is it surprising, especially for a new service offering.

Re:Does this surprise anyone?

[44BSD]

It is more than a caching proxy.

The client-side portion of the architecture aggressively prefetches content. It's a two-stage proxy, really, and the issue some people have with it is that the content in the portion on the end-user's hard drive is not content that the user asked for, but content that the proxy predicts the user will soon ask for.

Had to remove it from my computer

[PenguinBoyDave]

I had to remove it from my system. It hijacked my browser, and I was not able to browse my companies internal websites because it over-rode our proxy. Bummer too...it worked great

Re:Had to remove it from my computer

[Chyeld]

Why didn't you just tell it not to get in ivolved when browsing that domain? It does have exclusion rules built in.

Bigger problems with web accelerator

[alphakappa]

The accelerator prefetches the links on web pages, in effect clicking on all of them (except ads), which includes links that say 'delete this' or 'unsubscribe' etc. Many webpages use GET links to do these actions, and this is causing pages to disappear. Until web apps are rewritten to take note of the prefetch header, it's probably unsafe to use the accelerator. (Which seems to be offline at the moment - the page redirects you to the toolbar)

Bad caching directives

[Sebby]

We encounted similar problems when we implemented aggressive caching on our site; mostly that we didn't set the headers properly.

this site was pretty useful for information. So was AOL webmaster resources info.

Cache-Control is your friend.

[oneiros27]

If Google is ignoring Cache-Control headers, then that's one thing to complain about. There's also a good chance that some of these sites are using improper systems for session control (eg, using HTTP_ADDR without checking X_FORWARDED_FOR, and not setting Cache-Control on their response).

For more info about these known issues with HTTP caching, see the following

• RFC 3143 - Known HTTP Proxy/Caching Problems
• RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 (see sections 8.1.3 and 13, 14.9 and 15)

caching personalized content != caching cookies

[SuperBanana]

How does caching your cookies to the internet help speed up your local browsing?

Who said it was a cookie that was cached, and not the page content? Much of the discussion thusfar seemed based off what an anonymous quote in a ZDnet article. Far as I can tell, the guy saw "Welcome back, Bob!" and freaked, when he wasn't -actually- logged in as Bob. Furthermore, who says it isn't Futuremark (or their forum software- because we all know how security-conscious PHP/MySQL forum software is) tagging their pages as cacheable when they shouldn't be? If Google is ignoring "don't cache this page", now yes, we have a problem- but the ZDnet story is of a technical level I'd expect of a community newspaper, so it's kind of hard to tell. It's like a story in your city newspaper that read "somebody killed by a cop!" and going off on a rant about police brutality...only to find out later the guy was a bank robber with an Uzi.

Before you get all excited about bank sites etc- keep in mind those often use very unique URLs for each page and other tricks.

Futuremark's problem, not Google's

[Temporal]

I assume Google has properly implemented the HTTP/1.1 caching mechanisms. Among these, it is possible for a server to mark a page as being "private", meaning that it should never be cached in a public cache like Google's. Another thing the server can do is set "Vary: Cookie", which indicates that the server will produce different pages for people who give it different cookies.

Here are the headers that the Futuremark forums give me when I am logged in:

HTTP/1.1 200 OK
Date: Fri, 06 May 2005 18:10:16 GMT
Server: Apache/1.3.29 (Unix) mod_perl/1.29
Transfer-Encoding: chunked
Content-Type: text/html

As you can see, neither "Cache-Control: private" nor "Vary: Cookie" is given. In fact, the server doesn't even give an expiration date for the content. Under these conditions, the HTTP/1.1 protocol says that it is perfectly OK for a cache to keep this page for awhile and serve it to other people.

This problem is firmly the fault of the people who wrote Futuremark's forums. This constitutes a major security hole in the WWWThreads forum package, because this problem will occur when using any standards-compliant HTTP cache. I would strongly recommend against the use of these forums on any web site until they fix their security problems.

(I do not know if other forum software has this problem, but frankly it would not surprise me. It seems lots of PHP developers and other high-level web programmers have no idea how HTTP/1.1 works, and assume that headers are completely unimportant. I have written a web server and forum software myself, though, and I made damned sure that mine produces the right headers.)

Response

[Otto]

The web accelerator ignores robots.txt.

The web accelerator is not a robot, so this is correct behavior.

The web accelerator ignores the NOARCHIVE meta.

NOARCHIVE is a Google specific extension to the robots.txt specification, and again, this is not a robot.

I believe, but have yet to confirm, that it ignores any no-cache pragma headers.

I'd be absolutely shocked if that were actually the case. I also believe it respects the Expires header as well as the Cache-Control header.

It avoids prefetching anything with a question mark in the URL, but what about all those PATH_INFO dynamic links we've been installing for the last four years so that our dynamic pages look like static URLs? Google prefetches many of these, and there are numerous reports that this prefetching, along with some cookie mishandling by Google, is breaking sites out there. Does Google care?

If they're following the proper standards, then it's not their place to care or not. If your website doesn't properly specify cache-control (many don't) then you get what you get.

For any pages with user-specific content, add the "Cache-Control: private" header and voila, problem solved for you.

If you want to opt out entirely, then a simple "Cache-Control: no-cache" header in your HTTP responses would do the trick, as would "Pragma: no-cache", I bet.

Furthermore, there is no cookie-mishanding I've actually seen, and I've tested it. It passes cookies through just fine, without caching them, near as I can tell.