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

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:

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

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:

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:

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.

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:

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:

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:

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