The Economics of Privacy in Social Networks

We often think of social networking to Facebook, MySpace, and the also-rans, but in reality there are there are tons of social networks out there, dozens which have membership in the millions. Around the world it’s quite a competitive market. Sören Preibusch and I decided to study the whole ecosystem to analyse how free-market competition has shaped the privacy practices which I’ve been complaining about. We carefully examined 45 sites, collecting over 250 data points about each sites’ privacy policies, privacy controls, data collection practices, and more. The results were fascinating, as we presented this week at the WEIS conference in London. Our full paper and complete dataset are now available online as well.

We collected a lot of data, and there was a little bit of something for everybody. There was encouraging news for fans of globalisation, as we found the social networking concept popular across many cultures and languages, with the most popular sites being available in over 40 languages. There was an interesting finding from a business perspective that photo-sharing may be the killer application for social networks, as this features was promoted far more often than sharing videos, blogging, or playing games. Unfortunately the news was mostly negative from a privacy standpoint. We found some predictable but still surprising problems. Too much unnecessary data is collected by most sites, 90% requiring a full-name and DOB. Security practices are dreadful: no sites employed phishing countermeasures, and 80% of sites failed to protect password entry using TLS. Privacy policies were obfuscated and confusing, and almost half failed basic accessibility tests. Privacy controls were confusing and overwhelming, and profiles were almost universally left open by default.

The most interesting story we found though was how sites consistently hid any mention of privacy, until we visited the privacy policies where they provided paid privacy seals and strong reassurances about how important privacy is. We developed a novel economic explanation for this: sites appear to craft two different messages for two different populations. Most users care about privacy about privacy but don’t think about it in day-to-day life. Sites take care to avoid mentioning privacy to them, because even mentioning privacy positively will cause them to be more cautious about sharing data. This phenomenon is known as “privacy salience” and it makes sites tread very carefully around privacy, because users must be comfortable sharing data for the site to be fun. Instead of mentioning privacy, new users are shown a huge sample of other users posting fun pictures, which encourages them to  share as well. For privacy fundamentalists who go looking for privacy by reading the privacy policy, though, it is important to drum up privacy re-assurance.

The privacy fundamentalists of the world may be positively influencing privacy on major sites through their pressure. Indeed, the bigger, older, and more popular sites we studied had better privacy practices overall. But the desire to limit privacy salience is also a major problem because it prevents sites from providing clear information about their privacy practices. Most users therefore can’t tell what they’re getting in to, resulting in the predominance of poor-practices in this “privacy jungle.”

Static Consent and the Dynamic Web

Last week Facebook announced the end of regional networks for access control. The move makes sense: regional networks had no authentication so information available to them was easy to get with a fake account. Still, silently making millions of weakly-restricted profiles globally viewable raises some disturbing questions. If Terms of Service promise to only share data consistent with users’ privacy settings, but the available privacy settings change as features are added, what use are the terms as a legal contract? This is just one instance of a major problem for rapidly evolving web pages which rely on a static model of informed consent for data collection. Even “privacy fundamentalists” who are careful to read privacy policies and configure their privacy settings can’t be confident of their data’s future for three main reasons:

  • Functionality Changes: Web 2.0 sites add features constantly, usually with little warning or announcement. Users are almost always opted-in for fear that features won’t get noticed otherwise. Personal data is shared before users have any chance to opt out. Facebook has done this repeatedly, opting users in to NewsFeed, Beacon, Social Ads, and Public Search Listings. This has generated a few sizeable backlashes, but Facebook maintains that users must try new features in action before they can reasonably opt out.
  • Contractual Changes: Terms of Service documents can often be changed without notice, and users automatically agree to the new terms by continuing to use the service. In a study we’ll be publishing at WEIS next month evaluating 45 social networking sites, almost half don’t guarantee to announce changes to their privacy policies. Less than 10% of the sites commit to a mandatory notice period before implementing changes (typically a week or less). Realistically, at least 30 days are needed for fundamentalists to read the changes and cancel their accounts if they wish.
  • Ownership Changes: As reported in the excellent survey of web privacy practices by the KnowPrivacy project at UC Berkeley, the vast majority (over 90%) of sites explicitly reserve the right to share data with ‘affiliates’ subject only to the affiliate’s privacy policy. Affiliate is an ambiguous term but it includes at least  parent companies and their subsidiaries. If your favourite web site gets bought out by an international conglomerate, your data is transferred to the new owners who can instantly start using it under their own privacy policy. This isn’t an edge case, it’s a major loophole: websites are bought and sold all the time and for many startups acquisition is the business model.

For any of these reasons, the terms under which consent was given can be changed without warning. Safely disclosing personal data on the web thus requires continuously monitoring sites for new functionality, updated terms of service, or mergers, and instantaneously opting out if you are no longer comfortable. This is impossible even for privacy fundamentalists with an infinite amount of patience and legal knowledge, rendering the old paradigm of informed consent for data collection unworkable for Web 2.0.

Open letter to Google

I am one of 38 researchers and academics (almost all of whom are far more important and famous than I will ever be!), who has signed an Open Letter to Google’s CEO, Eric Schmidt.

The letter, whose text is released today, calls upon Google to honour the important privacy promises it has made to its customers and protect users’ communications from theft and snooping by enabling industry standard transport encryption technology (HTTPS) for Google Mail, Docs, and Calendar.

Google already uses HTTPS for sign-in, but the options to make the whole of the session secure are hidden away where few people will ever find them.

Hence, at the moment pretty much everyone who uses a public WiFi connection to read their Gmail or edit a shared doc has no protection at all if any passing stranger decides to peek and see what they’re doing.

However, getting everyone to change their behaviour will take lots of explaining. Much simpler to have Google edit a couple of configuration files and flip a default the other way.

The letter goes into the issues in considerable detail (it’s eleven pages long with all the footnotes)… Eric Schmidt can hardly complain that we’ve failed to explain the issues to him !

Security and Human Behaviour 2009

I’m at SHB 2009, which brings security engineers together with psychologists, behavioral economists and others interested in deception, fraud, fearmongering, risk perception and how we make security systems more usable. Here is the agenda.

This workshop was first held last year, and most of us who attended reckoned it was the most exciting event we’d been to in some while. (I blogged SHB 2008 here.) In followups that will appear as comments to this post, I’ll be liveblogging SHB 2009.

How Privacy Fails: The Facebook Applications Debacle

I’ve been writing a lot about privacy in social networks, and sometimes the immediacy gets lost during the more theoretical debates. Recently though I’ve been investigating a massive privacy breach on Facebook’s application platform which serves as a sobering case study. Even to me, the extent of unauthorised data flow I found and the cold economic motivations keeping it going were surprising. Facebook’s application platform remains a disaster from a privacy standpoint, dampening one of the more compelling features of the network.

Continue reading How Privacy Fails: The Facebook Applications Debacle

Attack of the Zombie Photos

One of the defining features of Web 2.0 is user-uploaded content, specifically photos. I believe that photo-sharing has quietly been the killer application which has driven the mass adoption of social networks. Facebook alone hosts over 40 billion photos, over 200 per user, and receives over 25 million new photos each day. Hosting such a huge number of photos is an interesting engineering challenge. The dominant paradigm which has emerged is to host the main website from one server which handles user log-in and navigation, and host the images on separate special-purpose photo servers, usually on an external content-delivery network. The advantage is that the photo server is freed from maintaining any state. It simply serves its photos to any requester who knows the photo’s URL.

This setup combines the two classic forms of enforcing file permissions, access control lists and capabilities. The main website checks each request for a photo against an ACL, it then grants a capability to view a photo in the form of an obfuscated URL which can be sent to the photo-server. We wrote earlier about how it was possible to forge Facebook’s capability-URLs and gain unauthorised access to photos. Fortunately, this has been fixed and it appears that most sites use capability-URLs with enough randomness to be unforgeable. There’s another traditional problem with capability systems though: revocation. My colleagues Jonathan Anderson, Andrew Lewis, Frank Stajano and I ran a small experiment on 16 social-networking, blogging, and photo-sharing web sites and found that most failed to remove image files from their photo servers after they were deleted from the main web site. It’s often feared that once data is uploaded into “the cloud,” it’s impossible to tell how many backup copies may exist and where, and this provides clear proof that content delivery networks are a major problem for data remanence. Continue reading Attack of the Zombie Photos

Location privacy

I was recently asked for a brief (4-page) invited paper for a forthcoming special issue of the ACM SIGSPATIAL on privacy and security of location-based systems, so I wrote Foot-driven computing: our first glimpse of location privacy issues.

In 1989 at ORL we developed the Active Badge, the first indoor location system: an infrared transmitter worn by personnel that allowed you to tell which room the wearer was in. Every press and TV reporter who visited our lab worried about the intrusiveness of this technology; yet, today, all those people happily carry mobile phones through which they can be tracked anywhere they go. The significance of the Active Badge project was to give us a head start of a few years during which to think about location privacy before it affected hundreds of millions of people. (There is more on our early ubiquitous computing work at ORL in this free excerpt from my book.)
The ORL Active Badge

Location privacy is a hard problem to solve, first because ordinary people don’t seem to actually care, and second because there is a misalignment of incentives: those who could do the most to address the problem are the least affected and the least concerned about it. But we have a responsibility to address it, in the same way that designers of new vehicles have a responsibility to address the pollution and energy consumption issue.

Security economics video

Here is a video of a talk I gave at DMU on security economics (and the slides). I’ve given variants of this survey talk at various conferences over the past two or three years; at last one of them recorded the talk and put the video online. There’s also a survey paper that covers much of the same material. If you find this interesting, you might enjoy coming along to WEIS (the Workshop on the Economics of Information Security) on June 24-25.

Reducing interruptions with screentimelock

Sometimes I find that I need to concentrate, but there are too many distractions. Emails, IRC, and Twitter are very useful, but also create interruptions. For some types of task this is not a problem, but for others the time it takes to get back to being productive after an interruption is substantial. Or sometimes there is an imminent and important deadline and it is desirable to avoid being sidetracked.

Self-discipline is one approach for these situations, but sometimes it’s not enough. So I wrote a simple Python script — screentimelock — for screen which locks the terminal for a period of time. I don’t need to use this often, but since my email, IRC, and Twitter clients all reside in a screen session, I find it works well for me,

The script is started by screen’s lockscreen command, which is by default invoked by Ctrl-A X. Then, the screen will be cleared, which is helpful as often I find that just seeing the email subject lines is enough to act as a distraction. The screen will remain cleared and the terminal locked, until the next hour (e.g. if the script is activated at 7:15, it will unlock at 8:00).

It is of course possible to bypass the lock. Ctrl-C is ignored, but logging in from a different location and either killing the script or re-attaching the screen will work. Still, this is far more effort than glancing at the terminal, so I find the speed-bump screentimelock provides is enough to avoid temptation.

I’m releasing this software, under the BSD license, in the hope that other people find it useful. The download link, installation instructions and configuration parameters can be found on the screentimelock homepage. Any comments would be appreciated, but despite Zawinski’s Law, this program will not be extended to support reading mail 🙂