Data.Driven()

While investigating privacy, I read a fantastic book by Daniel Solove called The Future of Reputation: Gossip, Rumor and Privacy on the Internet. Daniel is a professor of law at the George Washington University Law School who has written extensively about privacy.

Yesterday, I found this video lecture given by him at Google. Check it out! It covers a lot of things that are in the book.

I’ll just say, it’s a little bit sad to see such few people in the audience. Also, the questions from Google employees are very defensive. In my opinion, Daniel is right to say that people should have more control over Google results about themselves, specially if those results are slanderous.

With iOS 4.0 around the corner, its probably timely to get this post out now. This little post is part of my position paper, “Privacy of Geolocation Implementations”. I’m taking sections out that paper and republishing them here for comment.

A website viewed in Safari on iPhone 3.0 requesting to use the end-user's current location. But what will the data be used for? And where is the application getting the data from?

As can be seen in the screenshot on the right, when a web page attempts to access geolocation services on Mobile Safari, the browser presents the end-user with a dialog that states “[URL] Would Like To Use Your Currrent Location” with two options: “Don’t Allow” and “OK”.

This “click to confirm” model suffers from a number of  privacy issues: For one, the confirmation dialog does not give any indication to the end-user how their location is being derived: Is the location-provider the GPS? or is it the WIFI, or the cellular network, or a Web service? or a combination of those? and under what privacy policy does the location-provider provide that information? The iPhone provides no accessible means of viewing or changing the geolocation provider; hence an end-user has no control over the geolocation provider or even of knowing if their data is being encrypted on request.

Another privacy issue of Mobile Safari is that the confirmation prompts are modal: the user cannot fully view or interact with the underlying application to make an assessment of what the application might do with the positioning data, without first rejecting geolocation access to the website. Also, it is generally accepted that this kind of modal confirmation dialog lead to ‘click fatigue’: whereby users simply become accustomed to clicking “OK” to every prompt without grasping the consequences of their actions, and without having any real control over what personally identifiable data gets used, what it will be used for, or how long that data will be kept, or even if it will be made available (sold) to third parties. The privacy policies that govern geolocation services are buried three-levels deep in the “Settings” menu of the iPhone, under the “Legal” option, which contains about 50 a lot of pages of legalese and no searchable index!

The Iphone 3.0 "Legal" screen does not contain an index. Nor are hypelinks active.

Similar confirmation dialogs are found in the iPhone’s native applications (e.g., the Camera and Maps applications). If a user changes their mind about allowing location services, there is usually no way in the application  for them to revoke geolocation access without either quitting the application, uninstalling the application, or finding some other convoluted way to revoke access to geolocation services (e.g., having to globally disable location services on the device through the “Settings” menu). What is worst is that  once a user grants an application access to geolocation services three times, the system grants access to location services forever – or until the device is “reset”, meaning resetting back to factory default settings.

UPDATE: @andreasbovens pointed out to me on Twitter that the iPhone does, in fact, contain a way to reset location warnings. Go to “Settings > Reset > Reset Location Warnings”. My bad.

Iphone reset location warnings, which I didn't find the first time around

Applications that get granted access then do not generally provide an end-user with a means to revoke that access on an individual basis. This is also true on Mobile Safari: even after clearing the cache, history, and cookies Mobile Safari still grants websites access to geolocation without prompting the user.

In summary, Apple’s Mobile Safari browser (and iPhone 3.0 in general) provides end-users with limited access to privacy controls. It also provides no means of seeing which Websites have access to geolocation, nor once granted can that access be easily revoked by an end-user. The OS, however, provides means of achieving confidentiality by allowing the end-user to globally disable location services, WIFI, and cell-tower communication (via “Airplane Mode”). INSERT: The iPhone OS also provides a “Reset Location Warnings” option for all applications.

iPhone Airplane mode: anonymity?

Here is my position paper, “Privacy of Geolocation Implementations” (PDF ~500K), that I prepared for the W3C Workshop on Privacy for Advanced Web APIs.

UPDATE: the presentation slides are now available.

It’s a little bit drafty, so any feedback or comments welcomed. I will republish as a HTML file soon.

Investigating privacy in depth has been one of the most interesting things I’ve done in a long time… though it has left me a little bit creeped out. Hopefully I’ll get around to writing a bit more about what I read, what I’ve learned, and what practical changes I’ve made.

The following part of my forthcoming position paper for the W3C Workshop on Privacy and advanced APIs. Because my paper focused on implementation of geo-location, this sections had to be cut out. However, I think the following is relevant to the discussion about privacy and packaged Web applications, which is why I am publishing it here.

When it comes to privacy, it is obviously insufficient to simply define an API in terms of an Interface Definition Language (IDL), such as  WebIDL and OMGIDL, within specifications. IDLs are limited in that they only allow one to express simple inputs, outputs, and data type constraints. Nevertheless, implementations exist based on specifications that only provide IDL definitions, which are agnostic to privacy.  To overcome these limitations, some implementers leverage  digital signatures as the means of enabling privacy-sensitive APIs in an application. For example, if application “X” is signed by company “Y” then allow application “X” to access API “Z”.

Java treats an application as unsigned, and reduces its privileges: meaning some APIs will not be available.

Such an approach to privacy is limited in that it hands control of privacy matters over to a third-party (the signer) and implicitly assumes that the end-users unquestionably, or via a End User License Agreement (EULA), trusts the signer as the authority to enable an API without necessarily informing an end-user as to what is going on “under the hood” – such a model is commonly seen in the Java application space.

Feature Requests

Others have extended the digital signature to enable API model by having software developers explicitly declare what functionality an application will use (lets call them “feature requests“). Upon installation, the end-user is presented with a dialog informing them of the capabilities the application will use, and if they wish to proceed. An example is Chrome’s browser extensions, seen on the right.

Chrome's browser extensions show the capabilities of a packaged application, but lacks information about consequences.

From a privacy perspective, this model is significantly better then simply enabling APIs based on digital signatures. However, this model is also problematic in that it often does not provide any meaningful information about, for instance, what “can access your browsing history” coupled with “access your data on all websites” means. It can be argued that this model unfairly puts the consequences of consent on the end-user, by entering them into an agreement with an application without recourse (i.e., “Yes website/application X, you can access my history data even though I don’t know what you will do with it.”).

The W3C is hosting a workshop on Privacy for Advanced Web APIs and is currently calling for position papers. Although I don’t know what an “advanced Web API” is, it’s great to see members of the W3C taking an active interest in privacy, and emphasizing that the architectural design of APIs have a fundamental role to play in protecting the privacy of individuals.  The W3C has opened the workshop up to the public: it would be great to get a diverse range of people together to discuss the role and limits of APIs in protecting privacy, particularly from the academic community.  I don’t know how much marketing drive there was behind the workshop, but hopefully a variety of people will submit papers.

Papers are  due on the 7th of June. I’m currently trying to put a position paper together which I will post here once I’m done.