Privacy Workshop Position Paper - The DAP Perspective
Introducing the DAP WG
The application programming interfaces (APIs) work that the W3C Device APIs and Policy Working Group (DAP)  is chartered to perform represents the largest and most thorough assault on users' privacy ever undertaken by a single working group. A user agent supporting all of the DAP's APIs would enable arbitrary Web pages to have access to the user's contacts database, personal calendar, local file system, todo list, would be able to capture stills, video, and audio from the user's webcam and microphone, and would be able to send emails and SMSs on the user's behalf.
Application of this technology should enable a large number of new use cases relying on the integration of personal data into services, interactions based on device capabilities, far more fluid information sharing, and a much more immersive experience for the end user. Locally installed applications are likely to become progressively obsolete as the Web acquires the functionalities to reach ever deeper into our digital lives. To put it in today's lingo, if you don't go to the cloud, DAP will bring the cloud to you.
The traditional view on Web privacy is that it is most frequently and patently violated when users voluntarily provide information which is then reused. That view is only partially true (as we shall see below) but even if it were, the breadth of the new abilities that DAP is heralding and the vastly increased fluidity in sharing information that will likely accompany it risk being the cause of a major increase in the distribution of private information. Furthermore we should not fool ourselves that public awareness of privacy issues or regulation will, on their own, be sufficient to face up to this challenge. Such integrated services simplify common tasks, increase convenience to the user and provide for richer and more elaborate interactions that users will want. The simplicity of posting a picture or a video blog directly from inside of the page, of directly sharing one's contacts and calendar with a social network will beckon, and successfully at that.
Privacy: It's Worse Than Most Think
The new risks involved in opening up new functionality in the way that DAP endeavors to are generally well understood: A Web site might surreptitiously start capturing a video on the user's device, without consent, perhaps in the bedroom or in a private meeting; a rogue Web application could scan the contacts list to create spam or to post private information; a messaging API could be used to generate SMS messages to a premium number, incurring unwanted billing charges on a user. Each of these APIs that enable interesting and useful use cases can also enable abuse cases through misuse.
The types of privacy violations that are in practice today, without DAP, are however not as well understood by the Web community at large. Most Web developers, including those who create Web standards, tend to believe that privacy issues mostly stem from users volunteering information (typically through input forms) which one merely needs not to do, or through ad-related tracking which are routinely blocked. They generally react with surprise (followed, as they realize how easy such things are at the technical level, by dismay) at the fact that most operations that one performs on an arbitrary page are not private. Every movement of the mouse cursor, the speed at which the page is scrolled, whether the user actually finished reading the page, in some cases whether it was bookmarked or printed, or when some content is selected or copied can all be tracked. And in more than a few cases, they actually are, typically by analytics services not routinely blocked.
This is further compounded by the fact that the now common buttons that are added to web pages that offer "Share on Twitter" as well as "Bookmark", "Print", "Copy", or "Send to a friend", are the preferred way of performing these operations for the vast majority of lay users, over the ones provided by the browser or OS. These are very reliably trackable (and tracked). Yet it is not uncommon for Web developers who claim to be privacy conscious to include services such as AddThis to their Web sites.
Steps Towards a Solution
Given that its work on opening up new functionality can have potentially devastating effects, it is only natural that the DAP WG would have in its core mission preventing unwarranted collection, use, transfer and deletion of personal data, and more generally helping protect users' privacy. DAP goals include supporting the user value proposition related to privacy concerns, such as minimization of data provided, limits on redistribution and use of data, etc. as well as the value proposition of web developers and web intrastructure providers, including usability and interoperability.
The first step in attempting to enable sharing and using information effectively while limiting its spread and misuse, is to make privacy an immediate part of the security architecture. This approach builds on the notion that privacy, like security, should be dealt with systematically, from the initial design ("Privacy by Design" ). It is an “intermediate good”, something that people expect to be built-in, much like an engine in a car . Users expect it by default and will be surprised if it is not there. It cannot be bolted on after the fact.
What this translates to at the technical level is that all API calls that request access to potentially sensitive information are designed to be asynchronous. This enables the user agent to acquire the user's consent without blocking the user's action through a modal prompt. It is well acknowledged in the security community that prompts to accept potentially dangerous operations will be systematically acquiesced to by users (in fact, it is known that users do not even read the content of the prompt, even when insulting). By adopting the same approach for privacy, we enable implementations to adopt the best privacy-enhancing strategy available to them, be it non-modal prompting, prearranged policies, or a Web of trust approach.
The second step is minimization. An API doesn't need to be exposed to more information than it needs to function. In the simplest case, this is just a matter of only including in the API what has a solid use case justifying its presence — which is good design to start with. In more interesting situations, this involves making the user aware of which information is being requested, and offering the ability to control it. For instance, an application wanting to show the many fun anagrams that can be generated from one's friends' names could benefit from accessing the user's contacts database (since that prevents having to type them in) but it doesn't need to see the phone or email details. That is precisely the approach taken by DAP's Contacts API: the Web application requests the fields that it needs, and the user gets to choose which people to include, and potentially which fields to exclude (if several were requested.)
This negotiated process has multiple advantages. It makes it clear to users what information they are sharing without requiring much additional work for them. It encourages developers to only ask for the information that they actually need, and not go overboard lest they risk making users suspicious. Finally, it helps introduce the notion that justified access and blanket access are different, and can be supported separately.
Where applicable, another dimension that we have been working on is the standardization of an access
control policy framework that supports different rules for
various trust domains
. This enables declarative rules to be created to
directly control the ability to use APIs or obtain information. This framework includes the means to define
trust domains as well as a policy language to define access
control to device information and services
based on those domains. In some cases these rules may be defined by a
third party, such as a network operator in a mobile environment, or they may be learned based on user
We have also been investigating a user-mediated approach toward introducing consumers and providers of information to one another, the Powerbox . How it combines with the policy framework is still an open question; it is possible that they may simplify and enhance one another, or on the other hand that they may compete for the same space. Given the complexities involved in addressing privacy issues, a systematic solution may require more than one component to the solution and some promising approaches might not be suitable when better understood. For this reason the group is exploring and experimenting with many options. Given the breadth and depth of the challenge, the Working Group is seeking as much involvement from the developer and privacy communities as possible.
The DAP WG has reviewed privacy and policy use cases, is developing requirements, and is exploring technical solutions as well as advancing work on contributions that have been made. The WG is aware of privacy discussions in the W3C Geolocation WG related to privacy and GeoPriv, some of which have been summarized in a recent research paper . The DAP WG continues to learn as it works through issues and invites broad community participation, both in reviewing our work and contributing to the WG. All our discussions are open to the public on our public mailing list.
How You Can Help
The DAP WG is making progress on the details of the APIs, has written draft requirements on policy and privacy, has a draft policy framework intended to support privacy, a contribution on user-mediated introduction of information providers to consumers, and a first cut at expressing more complicated privacy expectations in a usable manner (Privacy Rulesets). We are actively seeking feedback on these efforts, participation in our work by any interested party, and any suggestions and assistance in helping us make great APIs that enable far more powerful Web applications while consistently enabling privacy protection.
We believe the work of the DAP WG is important to the future of the Web, both in the functionality and usability that it will offer, as well as the privacy risks that it may create. We need your participation to make this work a success. Come join us.
-  DAP Home Page
-  Device API Policy Requirements
-  Privacy By Design
-  Wikipedia
-  Device API Privacy Requirements
-  Privacy Issues of the W3C Geolocation API
-  Powerbox
-  Geographic Location/Privacy (geopriv), IETF
-  Privacy Rulesets
-  AddThis
-  Panopticlick