This document is an editors draft and currently does not reflect consensus of the WG but rather is a starting point for further work. It is based on input documents and list discussion.
Privacy considerations are important to Device APIs, since misuse of information exposed by the APIs can have financial, physical safety, and reputation impacts, among others. Privacy needs a systemic solution that includes functional requirements on user agents, web sites and other components of the system, since any opportunity for misuse of private information is a risk. Addressing privacy may include functional requirements in technical standards, laws and regulations, and best practices.
While privacy is an important consideration for all APIs, privacy risks may vary according to the information exposed by an individual API. For example, inappropriate disclosure of contacts or location information could create serious personal safety issues in a broad range of cases, while disclosure of certain system information might create privacy risks in fewer contexts.
Privacy protections are frequently understood as a set of principles or elements (one such set is described in [[PRIVACY-ISSUES-GEO]]). The core elements of privacy that are relevant to Device APIs, user agents that support the APIs, and applications that use the APIs are as follows:
Notice:Informing users about the data collected through Device APIs
Consent:Obtaining user agreement to sharing data through Device APIs
Minimization:Limiting the amount and level of detail of data collected through Device APIs
Control:Allowing users to control access to their data once they have consented to having it collected through Device APIs
Access:Providing users with access to information about the data that has been collected about them through Device APIs
Retention:Limiting how long applications retain data that was collected through Device APIs
Secondary Use:Limiting applications from using data collected through Device APIs for purposes other than the purpose for which it was collected
Sharing:Limiting applications from sharing data collected through Device APIs with third parties
These elements will each need to be approached in different ways. Approaches include specific requirements on individual APIs, conveying user expectations together with the data itself, and/or documenting best practices for application and content developers. Certain approaches are better suited to safeguarding certain privacy elements than others.
This document provides specific requirements for individual APIs, addressing the elements that are most relevant to API definitions: notice, consent, minimization, control, and access. Requirements involving user expectations, which primarily address retention, secondary use, and sharing, will be documented separately. Best practices for developers will also be documented separately, covering notice, minimization, control, access, retention, secondary use, and sharing in the application developer context.
The following table summarizes the breakdown of how each element is covered:
| Privacy Element | Requirements for API Definitions | Requirements for user expectations conveyed with data | Best practices for developers |
|---|---|---|---|
| Notice | X | X | |
| Consent | X | ||
| Minimization | X | X | |
| Control | X | X | |
| Access | X | X | |
| Retention | X | X | |
| Secondary Use | X | X | |
| Sharing | X | X |
The privacy requirements for individual APIs are provided in the next section. The requirements described in this document are intended to be applicable to device APIs both in the context of widgets and web applications.
The breakdown described above foreshadows the idea of providing API hooks that allow users to attach their expectations/preferences/policies about privacy to the data they share through the APIs. Attaching policy rules to the data that get shared can provide a legal basis for enhancing the control users have over their data once they are shared; but doing so create the following challenges:
It seems like the overall architectural approach that we discussed in Prague (with user expectation/preference bundle URIs passed via API hooks) needs to be described somewhere. Is this doc the right place?
For most of the privacy elements that apply to APIs (except for minimization), the WG has not discussed what the specific requirements should be. Therefore most of the sections below simply list what requirements could address.
Requirements could address: Whether APIs should provide ways for UAs to notify users before their data is sent to applications; how that notification happens; what that notice should contain
Should the APIs have a hook for applications to convey the intended usage of the data? If they do, should it be a required parameter? And how can this information be conveyed without misleading the user about the trustworthiness of that information?
Is it possible to provide an indicator that user data is being used, and enable follow up action from the user to determine how it is being used? (e.g. visual indicator and means to access log)
Requirements could address: Whether APIs require UAs to obtain user consent before sending their data to applications; how robust that consent needs to be (i.e., "express," "affirmative," "implied," "implicit," or something else); how that consent is obtained; whether that consent should be remembered by the UA
The semantics of some APIs are defined such that user interaction is essential to make use of the API. An example is a camera API that enables the user to take a photograph, but is defined to require the user to press a shutter key to take the photograph. Another example is an API that produces a message template, but requires the user to press "send" to actually send the message.
Such user actions constitute implicit consent, since the user has a choice to perform them and doing so implies consent to use the associated Device Capabilities. Such implicit consent eliminates the need for a security access dialog for that action since it is implicit in the application semantics.
Device APIs may also be defined such that implicit consent is not implied. Examples are a camera API that takes a photograph without user involvement, or a messaging API that sends a message without the user pressing "send". In these cases policy and/or user dialogs may be required.
To reduce the risks of over-exposing users data, it is helpful to design APIs so that Web developers can request as little information as they need to accomplish their goals.
Requirements could address: API support for limiting the amount of information requested/returned, whether APIs require UAs to allow users to change or limit the amount or granularity of data sent to applications. Examples of potential requirements include:
APIs SHOULD make it easy to request as little information as required for the intended usage.
For instance, an API call should require specific parameters to be set to obtain more information, and should default to little or no information.
APIs SHOULD make it possible for user agents to convey the breadth of information that the requester is asking for.
For instance, if a developer only needs to access a specific field of a user addressbook, that field should be explicitly markable in the API call so that the user agent can inform the user that this single field of data will be shared.
APIs SHOULD make it possible for user agents to let the user select, filter, and transform information before it is shared with the requester.
The user agent can then act as a broker for trusted data, and will only transmit data to the requester that the user has explicitly allowed.
Requirements could address: Whether APIs require UAs to provide a mechanism for consent to be revoked; what revoking consent means; what the default settings are for whether and to whom user data is sent; what the default settings are for granularity of data collected; whether APIs require UAs to provide a mechanism for users to whitelist trusted applications or blacklist untrusted applications
Requirements could include: Whether APIs require UAs to allow users to view the applications with whom they've shared data and at what granularity; whether APIs require UAs to allow users to view the history of the user's data sharing with each application; whether APIs require UAs to allow users to delete history entries or whole histories