The Associated Press reports a strange case in which a Facebook user logged into her account from her cell phone and wound up in someone else’s. Except it turns out that though strange, it is not unprecedented. A couple of people even wound up in each other’s accounts.
It’s a little hard to figure out what is going on, but it seems that the wrong cookie (code identifying the Facebook account) got installed on the user’s cell phone. According to the story, it’s AT&T’s fault, though it is hard to be sure since all the cases involve not just the same carrier but the same web service (Facebook) and the same Nokia phones. If, as reported, it’s a bug in AT&T’s cell-phone-to-Internet connection, it’s easy to imagine that a user might be taken to another’s Gmail account in the same way.
If the connection had been encrypted, that would probably have prevented the cookie bug from doing any harm. But Facebook does not use encrypted connections.
Which reminds me of something I should have mentioned earlier. In what was already a good week for Google on the privacy front, because of its announcement that it would stand up to the Chinese censors, Google announced in a much less publicized blog post that it was going to enable https by default for Gmail. That is, up to now, your Gmail has flowed to you in plaintext, available for sniffing and snooping anywhere in the Internet. There was always a way to change that default and have your Gmail encrypted, but it took a little digging to find the check box and few people bothered. The disadvantage to Google in making encrypted email the default is that the encryption takes time, so Google had to upgrade its systems, costing them money. Now they have decided to to exactly that, and once again, good for them!
Added a little later: The betting in the Slashdot comment thread is that it’s simpler than the AP story suggests. As one comment says,
My guess is that it’s as simple as this: the http returned by a request to “www.facebook.com” was cached by AT&T and delivered to other users who attempted to fetch that URL in an attempt to save bandwidth. The login credentials are irrelevant… once AT&T cached the page it thought of as “www.facebook.com” it would deliver it to anyone who asked for that URL. It probably only changed for the next person because someone insisted on logging out and back in, and the caching server detected the change then re-cached the NEW user’s page. This used to happen a lot on the internet to unencrypted streams that allowed log-ins. These days most caching servers are properly configured, but it’s still an easy mistake to make if you’re setting up a caching proxy.
That is, sometimes an ISP will cache (keep its own local copy) of a web page it retrieves from a server so the ISP can deliver it to multiple users who may request it without going back to the server for a fresh copy each time. Obviously this is the wrong thing to do if there is any possibility that the page may change in an important way in between requests that the ISP is receiving. Perhaps it was just delivering one party’s version of “facebook.com” (a logged in page) to another user who also asked for “facebook.com”. Whatever it was doing, it was wrong! And reminds us that nothing in a distributed system ever works better than the poorest code that gets invoked. Even retrieving a web page involves lots of parties.