# Some Perspectives on User Data Privacy

## W3C Workshop on Privacy for Advanced Web APIs

## 12-13 July, 2010, London

## Author: Bryan Sullivan, AT&T

### Introduction

This paper provides some perspectives, considerations, and recommended approaches toward support of user privacy, addressing some basic aspects of the subject:

- Privacy Policies as they exist today
- Privacy vs Security, and their support by Frameworks
- Responsibility of actors in the application ecosystem
- The Limits of Technology

### Privacy Policies

Most users if asked the question "what does privacy mean to you", would say something along the lines of "a lot". Nailing that down to specific preferences which can be expressed as policy, and that can effectively be indicated by the user in some concrete way, is a much more complex problem. In their most common and effective form, privacy policies today typically exist as accessible text documents that explain the key aspects of privacy to users, e.g. http://www.att.com/privacy which includes the following type of information:

- Defining private information
- Information collected, how it is collected, and how it is used
- Online privacy policy for children
- Policy on data protection and security
- Customer privacy controls and choices
- Who to contact for further information

Note that "users" refers at least to individuals that use device clients/user-agents (e.g. Web browsers, widget engines, or other user agents), applications, or services. Privacy policies should be defined by the parties responsible for each of these "used" things, e.g. developers of clients or applicatons, and service providers.

An accessible and comprehensive policy in text may seem like the least that can be done (and that's probably true), but it's a key starting point. Thus it should be a basic goal to establish best practices for consistent, accessible privacy policies as declared by all actors and entities in an application ecosystem, as applicable.

### Privacy vs Security, and Frameworks

It's been noted that privacy is not the same as security, which is correct. But both are concerned with user safety and choice, and the responsibility of those that act on behalf of the user. Thus privacy is enabled by similar fundamental capabilities as security, e.g.:

- Awareness of the user to risks
- Ability of the user to make implicit and explicit choices, including who/what to trust, and who to delegate trust decisions to
- Effectiveness of the methods for providing such awareness and choice
  - Ineffective methods will cause the user to make poor choices (e.g. ignore privacy risks) or undesirable choices (e.g. stop using an application or service).
- Ability to retain user choices as a record of the user's privacy preferences
  - This can be viewed as a facet of effective methods, but is also important for non-repudiation purposes, and to help build an "audit trail" of choices that can be used to change earlier choices.

Where these capabilities can be enabled through a common framework, e.g. a policy-based security framework as envisioned in W3C DAP, there is no need to develop a parallel framework for privacy. Thus a "privacy framework" may be whatever framework supports privacy objectives, and may be the same as a security framework. In particular the basic concepts as describe above can be expressed in a similar policy schema as defined by OMTP BONDI, in which some key policy elements can be expressed:

- The subject, being an entity which is accessing the private data for its own purposes, or the entity to which the private data is being exposed (note that if no specific entity is identified, e.g. private data is just stored somewhere without explicit access control, it effectively means exposure to anything)
- The resource, being the specific type of private data which is being accessed
- The condition, which is a limit placed upon the value or use of the private data
  - Note: the "use" is the key extension for privacy purposes, e.g. per the "Privacy Elements" as described in the current DAP Privacy Rulesets draft. If an interoperable private policy schema is defined and supported, the use descriptors (e.g. for sharing, secondary use, and retention) should be consistent between the policy framework schema and the private policy schema.
- The environment, which is a further modifier of the context in which the private data is being accessed or exposed
- The rule, which is the resulting permission that is allowed, and which may include an extended set of user prompt options, e.g. a set of multiple user-selectable options:
  - Allow for one day
  - Allow for two weeks
  - Allow forever
  - Allow only primary use
  - Allow secondary use
  - Allow sharing

### Responsibility

As with security, it's important to understand the nature of responsibility for protection of user privacy when accessing or exposing private data. The limits of responsibility vary depending upon who or what is accessing/exposing the data.

#### User Responsibilities

In the process of using services, users often have the option of directly exposing private information. That is an explicit choice, and the responsibility of the user to make wisely. Where a privacy framework can facilitate risk awareness, effective choice, and choice retention, it can help the user to make better decisions and to correct poor decisions. It should be a goal, but not a mandatory requirement, that a privacy framework support the user's explicit choices.

#### User Agent Developer Responsibilities

Developers of user agents (software that provide an environment in which applications can be used) have the responsibility to accurately implement any standards that they claim to support. This includes any privacy framework requirements for private data that is:

- accessed by the user agent for its own purposes in support of features offered directly to the user by the user agent, e.g. a personalizing feature
- accessed by the user agent on request of applications via an API exposed by the user agent
- exposed by the user agent for any purpose
  - Note: It is important that privacy framework requirements (e.g. as described the W3C DAP Device API Privacy Requirements) define clearly what "exposure" means. In general this is assumed to mean any delivery or storage of data in which the data is no longer in the direct control of the user agent.

It is assumed that privacy framework requirements will include avoidance of any redundancies in user notice and requirements for consent, to the extent possible, as part of the "effectiveness" goal.

- Note: How this can be achieved across API and interface boundaries needs further study, e.g. how the user agent knows whether prior consent has been given for the access to private data via its exposed APIs, if the user agent itself was not involved in the consent. The need to avoid redundancy also applies to all entities in an end-to-end privacy enablement system.

User agents are not responsible for any private data that is exposed directly by the user through the application.

#### Application Developer Responsibilities

Because applications are typically not measured for compliance to standards, but at most validated in an application ecosystem per their compliance with policies established by the ecosystem, developers of applications have the responsibility to accurately implement and comply with any best practices and privacy policies that they claim to support.

As for user agents however, application developers are not responsible for any private data that is exposed directly by the user through the application, e.g. associated with user input for which the nature of the user-supplied information is not specifically intended to be known by the application.

Application developers are responsible however for private data that is:

- accessed by the application for its own purposes in support of features offered directly to the user by the application, e.g. a personalizing feature
- exposed by the application for any purpose
  - Note: the need to define "exposed" also applies here.

#### Service Provider Responsibilities

Service providers have the responsibility at least to accurately implement and comply with best practices and privacy policies that they claim to support. To the extent that the service provider is responsible for any network elements that provide access to or expose private data, the service provider is also responsible for the privacy framework requirements affecting those network elements.

Similarly as for user agents and applications, service providers are not responsible for any private data that is exposed directly by the user, e.g. associated with user input for which the nature of the user-supplied information is not specifically intended to be known by the service provider or their operated network elements.

Service providers are responsible however for private data that is:

- accessed by services for their own purposes in support of features offered directly to the user by the service, e.g. a personalizing feature
- exposed by the services for any purpose
  - Note: the need to define "exposed" also applies here.

### The Limits of Technology

It is important to understand the limits of technology to address the overall objectives of privacy protection, in order to set reasonable expectations on what types of protection can be provided. For example, the ultimate goal for privacy protection may be that the user is always able to:

- Know that use of their information is actually limited to the disclosed use
- Know what information has been shared with whom (including who they have shared it with, etc), and where it still exists
- Revoke access to private information (including that which has already been shared) and force removal of retained information

These goals however are only partially achievable with current technology.

At most it may be possible to express intent for private data use/exposure, and consent of the user to that intent. Verification of actual compliance to the stated intent and consent may require unspecified audit processes.

### References

OMTP BONDI Approved Version 1.1

OMTP BONDI Architecture & Security Requirements (Appendices), Approved Version 1.1

W3C DAP Device API Privacy Requirements editor's draft

W3C DAP Privacy Ruleset editor's draft