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: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.

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.

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.