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

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

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 !

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.

It started with an email from Henrik, a LBT reader who was concerned when he noticed his Facebook profile picture, as well as those of his friends, being included in advertisements within the site. These ads showed up next to a third-party Facebook application called “What Eukaryotic Organelle Are You?“, one of the many inane user-generated quizzes which are popular on the site. I followed the tip and tried it myself, and sure enough saw an ad telling me to log-in and see which of my friends had secret crushes on me, alongside photos and names of a few Facebook friends of mine. I went on to find dozens of such ads on similar quizzes.

Examining the page’s source, these ads were being served in an iframe within the third-party application’s canvas, with a quite suspicious URLs like:

http://sochr.com/i.php
&name=[Joseph Bonneau]&nx=[My User ID]&age=[My DOB]&gender=[My Gender]&pic=[My Photo URL]
&fname0=[Friend #1 Name 1]&fname1=[Friend #2 Name]&fname2=[Friend #3 Name]&fname3=[Friend #4 Name]
&fpic0=[Friend #1 Photo URL]&fpic0=[Friend #2 Photo URL]&fpic0=[Friend #3 Photo URL]&fpic0=[Friend #4 Photo URL]
&fb_session_params=[All of the quiz application's session parameters]

Three data leaks are happening here. The first (light orange) is bad, but expectable, as my personal data is getting sent to the ad server. The second (dark orange) is worse-4 of my friend’s names and photos are getting sent along to the ad server. Note the data-flow here: the third-party quiz application is querying Facebook for my friends’ data, then including it within the URL of the requested ads so the ad server gets the data too. Data is passed in the URL because this is the only way to communicate with content in an iframe. When I refreshed the page, a different set of friends’ information was passed, so the ad-server can slowly build up a database of user information.

The third bit (red) is the amazing part-all of my session parameters were sent to the ad server as well. Because I authorised the application, these parameters are a capability to query Facebook for my data and my friends’ data. Sure enough, the ad server then went on to query Facebook’s databases on my behalf! From its iframe, the ad-server’s JavaScript sends queries to Facebook with the application’s session parameters. The results are then sent back to the ad-server. You can watch all of this happen using a packet sniffer in real-time and it’s quite amazing. There’s a great writeup from a week ago by another security researcher investigating these matters with some example queries the ad server’s JavaScript is making, requesting things like the set of all friends who live in the same city, are single, and share interests with me.

This is all in direct violation of Facebook’s Terms of Service and Platform Guidelines, which clearly prohibit using user data for anything but the application it was given for as well as transferring session parameters to a third party. Yet this violation is occurring on an epic scale. This quiz was created by an application called QuizMonster which allows users to create their own quizzes. It’s incredibly popular, with almost 1 million users having created a quiz, meaning tens of millions have possibly taken a quiz and been subject to these ads. Many other applications no doubt used these ad severs as well.

The ads are mostly served from two domains, SocialHour and SocialReach, which both have websites claiming to be leading “social monetization platforms.” (SocialReach is currently down, but is still cached by Google). They seem quite dodgy though. Their domains are registered through anonymous DNS registrars, and the ads themselves lead to a scam: after taking a quiz users must enter their mobile number, and are later hit with surprise $20 per month subscription fee.

This hints at the root of the problem: it’s tough to make money even as a popular Facebook application, and so developers have been forced to resort to these sleazy ads because they pay well. SocialReach even promises on its web site to pay the highest CPM in the industry. Facebook similarly has an economic incentive to look the other way. They clearly state in their terms of service that they may fail to enforce some of the terms, so users have no recourse if Facebook is loose with the rules to keep the platform attractive. Most damningly, Facebook recently verified applications showing  ads like these.

This scheme may be a violation of Principle 7 of the UK Data Protection Act, as Facebook is transferring data to a data processor on its behalf who is not upholding Facebook’s privacy policy, but it’s unclear where the liability lies.  Unless users are complaining en masse, Facebook has little reason to police the platform, as they have crafted their terms and conditions to disclaim all liability.

Speaking of complaints, after communicating with Henrik he filed a complaint with Facebook through their standard interface over three weeks ago, clearly stating that his data was being sent places he hadn’t authorised. He received no response, but last night Facebook acted, most likely with threats of legal action, and both Social Reach and Social Hour have stopped showing ads on Facebook. Evidently Facebook received multiple complaints, probably more about the deceptive mobile phone subscription than the data theft, but it was enough to get Facebook to move.

While it’s a positive sign that Facebook eventually did step in, this had been going on for at least a month and millions of users’ data has probably already passed through these ad servers. The long-term problem is that the underlying security model is completely broken. Facebook applications get access to all data of users who sign up, though users sign up for dozens of one-time use applications like these quizzes without thinking twice. There are hundreds of applications springing up every day, and Facebook’s model of implementing no technical sandboxing  and policing applications when things go wrong is completely unscalable.

This isn’t a new problem-running untrusted applications with limited privileges has been a research topic in operating systems, browsers, and mobile phones for years. Mobile phones may be the closest parallel. The iPhone’s application dynamics are quite similar to Facebook’s but have been (mostly) successfully run at reduced privileges without issue. A nice research paper last year pointed out that it would be easy to isolate social networking applications from ever seeing user data, as most of them (like quizzes) don’t even need it.

Given the huge body of applications already out there, Facebook is probably stuck with its current model of user consent and legal policing with little real security. For all we complain about abstract notions of privacy, this technical shortcoming will probably be the biggest privacy headache for the foreseeable future.

Thanks to Henrik, Richard Clayton, and Ben Edelman for help with this report.

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.

For our experiment, we uploaded a test image onto 16 chosen sites with default permissions, then noted the URL of the uploaded image. Every site served the test image given knowledge of its URL except for Windows Lives Spaces, whose photo servers required session cookies (a refreshing congratulations to Microsoft for beating the competition in security). We ran our initial study for 30 days, and posted the results below. A dismal 5 of the 16 sites failed to revoke photos after 30 days:

Just for fun, we’ve also re-started the experiment to allow live viewing.

Most likely, the sites with revocation longer than a few hours aren’t actively revoking at all, but relying on the photos eventually falling out of the photo-server’s cache. This memory-management strategy makes sense technically, as photos are deleted from these types of sites too infrequently to justify the overhead and complexity of removing them from the content delivery network. This paradigm is usually reflected in sites’ Terms of Service, which often give leeway to retain copies for a ‘reasonable period of time.’ Facebook is actually quite explicit about this, stating that ‘when you delete IP content, it is deleted in a manner similar to emptying the recycle bin on a computer.’

This architecture is not only fundamentally wrong from a privacy standpoint, but likely illegal under the EU Data Protection Directive of 1995 and its UK implementation, the Data Protection Act of 1998, which both clearly ban keeping personally-identifiable data for longer than necessary given the data’s purpose. In the social web case, the purpose of keeping a photo is to share it. Since this is no longer possible after the photo is marked ‘deleted’ all copies of the photo must be removed. There’s also an interesting violation of the provision that a user should have access to all data stored about her, after marking a photo ‘deleted’ the user no longer access to it, as there is no way to see which user content is still cached.

Architecture matters, and though it may be more complicated, sensitive personal data must be stored and cached using reference counts to ensure it can be fully deleted, and not simply left to be garbage collected down the road. Unfortunately, as is common with with social networking sites, privacy is viewed as a legal add-on and not a design constraint. In the terminology of Larry Lessig, privacy is still considered a matter of law and not of code.  As a result a user can have no assurance about where their photos may be floating around in the cloud.

EDIT 22/05/2009: We originally reported that Xanga and LiveJournal left photos unrevoked. After corresponding with developers from both sites, this was revealed to be a UI problem and not a CDN problem in both cases. When a photo is included in a blog post which is deleted, the photo itself is not considered deleted but becomes one of the user’s photos. Unfortunately, in each site the normal photo interface did not reveal this: Xanga showing this in it’s ‘Photos’ interface, and LiveJournal showing showing this. In both cases, deleting photos which were included in blog posts requires a separate interface. In LiveJournal’s case the separate interface itself incorrectly stated I had “no galleries.” Due to this UI confusion, I thought the photos were deleted when they werent’t thus they weren’t revoked. Apologies for the confusion, I re-tested both and printed updated results, though this has led both sites to re-consider their UI’s which were admittedly confusing and outright buggy in LiveJournaI’s case.

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

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.

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