Position Paper: Privacy and Policy in the DAP WG A DAP Perspective

Introduction

We presented a position paper at the W3C Workshop on Privacy for Advanced Web APIs held 12-13 July 2010 in London [1]. In that paper we noted that the application programming interfaces (APIs) work that the W3C Device APIs and Policy Working Group (DAP) [2] is chartered to perform represents a significant risk to users' privacy. This remains the case. Those APIs can enable arbitrary Web pages to have access to the user's contacts database, personal calendar, local file system, and todo list. They would be also be able to capture stills, video, and audio from the user's webcam and microphone as well as be able to send emails and SMSs on the user's behalf.

While not enough, access control security mechanisms are important to privacy. Although user interaction on every access is a form of access control, the WG charter specifically calls out the deliverable of defining a policy framework for access control [3]. In fact, the name of the WG is "W3C Device APIs and Policy Working Group", indicating the importance of policy. The WG already has started a draft of an API access control framework [4] but has decided to focus on implications for the wider web before progressing this work. The WG is taking a first step of defining relevant features and permissions [5]. A draft WG requirements document summarizes various use cases including general web pages, trusted and untrusted widgets, and delegated authority [6].

The DAP WG is taking privacy and security seriously. This paper summarizes the current status of the WG work on privacy and suggests some next steps. It also outlines the issues related to access control and approaches the WG is taking in this area.

Privacy Risks and Approach

In our paper for the previous W3C Privacy Workshop we noted that Web privacy risks are often not understood and are larger than might be expected. We highlighted that technologies can be used in unexpected ways introducing new privacy threats. During the workshop we discussed that the problem goes beyond minimization of the data returned by an API since subsequent risks include correlation of data over time and from different sources. An excellent example is using location information of an individual over time to intuit meaning (e.g. this must be "home"), combining it with other place information (e.g. knowing that a strip club is located at a place where the user was located), and making (possibly incorrect) deductions about individual behavior. Meaningful privacy involves the entire system of which APIs are only a part.

Doing what it can, the DAP WG is working toward designing the APIs to consider privacy from the outset. We have documented privacy requirements specific to our API development, including an architectural approach that emphasizes usability and principles encompassing notice, consent, minimization, control, access, retention, secondary use and sharing [7]. We did not document broader privacy principles such as "Privacy by Design" as our intent is to focus on specifics of our WG and not reiterate generally accepted privacy principles.

Preventing an open set of risks in a complex system is difficult if not impossible, as those who work in the security and privacy areas know. Thus non-technical legal and social mechanisms must work together with technical approaches to mitigate risks. From a technical perspective, we decided to start with basics, to minimize the data returned by APIs, and to examine carefully the the role of user interaction and consent. The WG is taking the approach that user interactions should be natural to the user's view of the workflow. This is to avoid the use of meaningless prompts to which a user would always respond "yes", not knowing what else to do.

We also are considering extensions to the APIs to share user privacy constraints, but in a simple and usable way. This would support legal and social mechanisms used to enhance privacy. Specifically the WG is evaluating the Ruleset approach that was presented at the previous W3C privacy workshop [8] [9]. This approach is promising in that it offers a usable and understandable mechanism for a user to specify in a broad stroke how they wish data to be retained, shared and used, drawing on Creative Commons experience. There is not consensus in the WG at this time whether this approach should be taken, due to concerns about the impact on browser and other implementations.

Access Control Policy

Access Control is important for controlling who can use specific information and device capabilities. It is not always desireable to require user interaction on every request, especially in an application that requires a number of device features, perhaps repeatedly. In some cases authority can be delegated and managed more effectively using a policy definition and enforcement mechanism.

The feasibility and value of declarative policy for access control depends on the use case. The trusted widget use case, for example, lends itself to policy designed to be portable across devices and providers. A trusted widget packages the various elements of a web application into one bundle that can be loaded into the device and use device APIs to provide useful functionality [10], [11]. Trust can be established in a variety of ways, including secure download from a trusted source, or verification of a signature on the widget package in conjunction with certificate trust chain validation [12], to give two examples.

In cases where trust in the application making the API requests can be established, declarative policy could be used to enable specification of access control rules portable across devices and services consistent with the DAP standard. This would give users freedom to avoid lock-in and make changes in devices and services. It would also eliminate the need for many cumbersome user interactions for permission, especially for applications that require many device resources and capabilities over a period of time.

A different use case is that of a web page that uses device APIs to provide a web based application. An example might be a page that uses the users contacts information to enable social networking aggregation, or perhaps to provide an email client. In such cases it might be difficult to bind policy with a specific application, if there is no pre-existing relationship and an arbitrary web site is visited by the user. An approach under consideration by the DAP WG is user-mediated introduction of web page applications to resource sources (on the device or web), enabling user control of the introduction [13]. This could be an alternative to declarative policy, or used in conjunction with it, perhaps using policy mechanisms after the initial introduction.

Declarative policy for access control is appropriate for some delegated authority cases, either where an organization such as an enterprise or mobile operator wishes to establish constraints on API use on users and devices associated with the organization, or where an individual would like to simplify their decisions by relying on a service provider for help managing their device. Declarative policy may also be appropriate for cases where a user wishes to remember decisions made earlier and perhaps apply them to new cases, without relying on a third party.

Concerns related to policy include the ability to deploy policy in a distributed system that encompasses a large variety of platforms for various use cases, some possibly conflicting. There are also fundamental concerns about users being able to understand and articulate policy correctly when authority is not delegated (or even to be able to clearly articulate policy in the delegated authority case).

The WG is considering the implications of policy for a variety of use cases, including web pages, trusted widgets and cases where policy can be managed through delegated authority. The latest draft of the Access Control Use Cases and Requirements discusses the various use cases and how they relate to policy [6], and the Policy Framework draft outlines a starting point for a policy framework based on contributions to the WG. The WG does not yet have consensus on the role of policy in solving the wider problem, to enable safe and privacy-respecting access to personal data from applications running in the Web at large and is working on understanding the broader picture before focusing on the details of a framework.

More questions and Next Steps

What is emerging is the thinking that there needs to be a fundamental safety net in APIs that does not rely on a universal policy framework. This requires basic APIs to be safe by default, or to require user interaction on a minimalistic set of APIs that are not safe. Unfortunately it is hard to define a "safe" API, if such a concept is even possible, due to the many potential uses of the API. Correlation and use of API data and functionality over time, place and among various parties makes it hard to establish what is safe. It is a complex problem that is unlikely to have a simple "silver-bullet" solution. We can, however, clearly identify simpler unsafe cases of API use and attempt to eliminate those.

We agree that user interaction should be a natural part of a workflow that is meaningful to a user, and not a dialog that asks permission to perform some low-level operation that has no meaning to the user. This enables permission in a usable manner while avoiding the security risk of answering "yes" to anything to get on with a task. The act of proceeding with a workflow implies user permission to continue, for example selecting contact for an operation rather than canceling the operations implies user consent to use that information in the operation. We would like to encourage this approach by being clear in API definitions where it is appropriate and necessary.

In order to understand how a policy framework might relate to various use cases, a first step is to define the permissions (or capabilities) that are appropriate to the various APIs and how they might be identified and used. We also need to clarify how APIs are themselves identified (presumably by method name, but granularity remains an issue here).

It seems clear that for usability we need the concept of an "application", not only for trusted widgets, but also for web pages that offer functionality based on various device APIs. We need to understand how such an application might be installed and obtain the permissions it needs, both for trusted and untrusted cases. In an untrusted case it might not be enough to grant no access, and a trusted case may require limitations. This is exactly the area policy is designed to address, but previous approaches were not designed for the web. We need to remain aware of the security issues that have occurred with the installations of applications on personal computers, suggesting the importance of trust. It may be that DAP does not cover all use cases, but focuses on those that are tractable to trust and policy, but the WG has not reached the point of making such decisions.

We note that privacy is always a concern, even in a trusted environment and even with delegated authority such as in an enterprise. In such environments APIs may offer more functionality using more API capabilities, but individual privacy will still need to be respected.

The DAP WG continues to work on privacy and policy requirements and mechanisms and is open to contributions and suggestions.

Notes

[1] Privacy Workshop Position Paper - The DAP Perspective,

W3C Privacy Workshop July 13-14, 2010 Robin Berjon, Frederick Hirsch, http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-11.html

[2] DAP Home Page

http://www.w3.org/2009/dap/

[3] Device APIs and Policy Working Group Charter

http://www.w3.org/2009/05/DeviceAPICharter

[4]Policy Framework for Device APIs

W3C Editor's Draft, 29 June 2010 Laura Arribas, Paddy Byers, Frederick Hirsch, David Rogers. http://dev.w3.org/2009/dap/policy/Framework.html

[5] Device API Features and Capabilities

W3C Editor's Draft, 25 August 2010 Paddy Byers, Frederick Hirsch http://dev.w3.org/2009/dap/features/

[6] Device API Access Control Use Cases and Requirements

W3C Editor's Draft, 25 August 2010 Laura Arribas, Paddy Byers, Frederick Hirsch, David Rogers. http://dev.w3.org/2009/dap/policy-reqs/

[7] Device API Privacy Requirements

W3C Editor's Draft, 23 June 2010 Alissa Cooper, Frederick Hirsch, John Morris http://dev.w3.org/2009/dap/privacy-reqs/

[8]Binding Privacy Rules to Data: Empowering Users on the Web.

W3C Privacy Workshop 4 June 2010. John Morris, Alissa Cooper, and Erica Newland Center for Democracy & Technology. http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-13.pdf

[9] Privacy Rulesets: A User-Empowering Approach to Privacy on the Web.

W3C Privacy Workshop July 13-14, 2010 Alissa Cooper, John Morris, and Erica Newland Center for Democracy & Technology http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-12.html

[10]Practical Privacy Concerns in a Real World Browser

W3C Privacy Workshop 4 June 2010. Ian Fette, Jochen Eisinger http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-24.pdf

[11]Widget Packaging and Configuration

W3C Candidate Recommendation 01 December 2009. Marcos Cáceres. http://www.w3.org/TR/widgets/

[12]Digital Signatures for Widgets

W3C Last Call Working Draft 11 May 2010. Marcos Cáceres, Frederick Hirsch, Mark Priestley. http://www.w3.org/TR/2010/WD-widgets-digsig-20100511/

[13]Powerbox Proposal

http://lists.w3.org/Archives/Public/public-device-apis/2010Jun/0020.html