When sites promise privacy but deliver leaks instead – a designer’s view on Firesheep

The release of Eric Butler’s Firesheep, a browser add-on allowing to hijack browser sessions over unsecured wireless networks without any technical expertise, has triggered a flood of commentary how users may protect themselves. However, while protecting their own connection makes a user safe from having their account hijacked, this leaves the core issue unsolved: As long as even one single peer of a social network user is subject to an exploit like this, the “protected” user’s private data is at risk as well.

A chain is as strong as its weakest link – if a social network site (SNS) does not enforce the use of a secure protocol for all its communications, a user’s personal data may leak, regardless whether or not they have protected their own connection. For the social interaction designer, this implicates that it is more than legitimate to put a requirement for enforced HTTPS encryption on any SNS concept document. In big red letters!

Why Firesheep and Wi-Fi are not the issue

The vector of attack Butler’s tool is exploiting is by no means new, but in providing a one-click solution for everybody to use he has launched a welcome discussion on privacy and data security. The pattern of HTTP session hijacking is easy to explain: When using the internet over an unsecured wireless LAN (such as in a cafe or other public space), other computers in the same network can monitor the data each machine transmits.

The attacker intercepts the data on the unsecured Wi-Fi network and steals the identification token.
Image caption: The attacker intercepts the data on the unsecured Wi-Fi network and steals the identification token.

Even though login data is often sent over an encrypted HTTPS connection and thereby secured, once the user is logged in many sites transfer their data using the unencrypted HTTP protocol. Since the identification of a logged-in user happens through a temporarily stored key (in a cookie file), this key is transmitted with every request the browser sends to the server. By stealing and applying that key, an attacker is able to access a web site using the identity of some other person – which is what Firesheep allows to do easier than ever before.

Nevertheless, the real problem is not that data transmitted over an open WLAN can be sniffed by others (and as he explains, Butler has not discovered this, his Firesheep tool only makes it easier), but that web sites use an insecure protocol like HTTP to transfer personal content which they encourage their users to upload by promising limited audience.

Data in an SNS is never “private”

While the different solutions proposed for self-protection (never use unencrypted WiFi, use VPNs or SSH tunnels, force your browser to connect to certain sites only through HTTPS etc.) indeed may eliminate the risk of having one’s own account hijacked, this is only an apparent solution. The core issue is a major flaw in the technical design of SNSs that encourage their users to share “private” information by offering all kind of privacy settings whilst at the same time leaving a back door wide open.

Tech blogs and boulevard media all over the world are now pushing instructions how to “protect yourself”. Still, only a small share of SNS users is likely to even read these news; an even smaller fraction will understand the measures needed or bother to do anything about it. But – ironically – those who understand and implement the steps to secure their own connections better are those who are most at risk: With the delusive feeling to have protected themselves, they keep posting private data to a network where it can be accessed by all their contacts through, yes, possibly unprotected connections.

Social interaction design thinks for the user’s benefit

This brings up questions related to digital literacy. The majority of “expert users” is likely to be aware that privacy settings in an SNS are nothing to be trusted beyond their role as an obfuscating layer; that any information that may cause whatever kind of (undesired) trouble if leaked should not be posted online. But observing the current patterns of use by the masses, even this is hard to communicate to the majority of users.

An image transferred securely by the uploader can be intercepted on the viewer's side.
Image caption: An image transferred securely by the uploader can be intercept on the viewer’s side.

As designers, we inevitably have to ask ourselves what is our responsibility for the security of our users – individuals that we cannot assume to have the same digital literacy as ourselves? For sure, launching a successful SNS would be hard when having red “mind your privacy” stickers all over the place, while the competition not warning its users appears to be the safer environment. And that may not be required either: Responsible social interaction design is partially about thinking “on behalf” of our users on all levels – from the concept to its implementation. Maximising the technically possible protection would be an important step.

But giving a user the possibility to limit the visibility of a possibly sensible photograph to half a dozen of close friends and at the same time making it accessible to any random stranger sitting in the same cafe with one of those friends is definitely not the way to go.

  • tlaturi on Twitter:

    RT @sebastiangreger: My take on #firesheep: "When sites promise privacy but deliver leaks - a designer's view" http://bit.ly/9vNahF #sxd

    2010-10-28

  • Timo Koola on Twitter:

    RT @sebastiangreger: My take on #firesheep: "When sites promise privacy but deliver leaks - a designer's view" http://bit.ly/9vNahF #sxd

    2010-10-28

  • Icon Webmention from Making the case for “Privacy-Aware Design” // Sebastian Greger:

    […] protected? (see my earlier writing on why HTTPS should be considered a compulsory feature of any SNS design) […]

    2014-02-06

Responding with a post on your own blog? Submit the URL as webmention (?)