Breaking the Web's Cookie Jar

Atwood recommends only browsing 'anonymously' when on public, unencrypted networks, but that's a lot harder than it sounds. A facebook 'like' widget (even if you don't click it) on the news site you're using anonymously can be enough to get your Facebook info sent over the network.

"Lobby the websites you use to offer HTTPS browsing."

The irony is that codinghorror.com and stackoverflow.com (the two most prominent Jeff Atwood's web sites) do NOT support HTTPS.

https://www.codinghorror.com/ simply times out. https://stackoverflow.com/ greets me with "The site's security certificate is not trusted!" and then further with Access Denied.

This has nothing to do with HTTP, nothing to do with cookies, nothing to do with Wifi, nothing to do with capturing packets being 'easier' (?!?), nothing that is easier since 2003.

It has to do with a very simple concept that many do not seem to understand: If you are on the same network as somebody else, and you are not using an SSL connection, other users on the network will see everything. And further, even if you are using SSL, if you aren't checking the key sigs, they can again see everything.

Cookies are simple and elegant and are not the problem - the solutions have existed for almost 20 years.

Firesheep is great because it is not only switching on users who had no clue, but also developers who have no clue.

I think Atwood seriously understates the innovation behind Firesheep. The vulnerabilities are not new. Proof of concept code has been out there. It's all in the execution. Packaging an exploit as a voyeuristic game has made it rise to the top of securities discussions since it was released.

One mitigating measure would be to use secure VPN. Traffic from the VPN to the destination would still be unencrypted, but would eliminate drive-by hackers.