This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a First Public Working Draft of a document that is expected to be further updated based on both Working Group input and public comments. The Working Group anticipates to eventually publish a stabilized version of this document as a W3C Working Group Note.
This document was published by the Device APIs and Policy Working Group as a Working Draft. If you wish to make comments regarding this document, please send them to firstname.lastname@example.org (subscribe, archives). All feedback is welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document outlines good privacy practices for web applications, including those that might use device APIs. This continues the work on privacy best practices in section 3.3.1 on "User Awareness and Control" Mobile Web Application Best Practices [MWABP]. It does not repeat the privacy principles and requirements documented in the Device API Privacy Requirements Note [DAP-PRIVACY-REQS] which should also be consulted.
The principles of "Privacy by Design" should be reflected in the web application design and implementation, including the use of device APIs. These are enumerated below and in more detail in the reference [PRIVACY-BY-DESIGN].
Best Practice 1: Follow "Privacy By Design" principles.
Proactively consider privacy, make preservation of privacy the default, including privacy in a user-centric and transparent design without making tradeoffs against privacy for other features as privacy is possible along with other functionality.
These principles include the following:
Privacy should be user centric, giving the user understanding and control over use of their personal data.
Best Practice 2: Enable the user to make informed decisions about sharing their personal information with a service.
The end user should have enough information about a service and how it will user their personal information to make an informed decision on whether to share information with that service. This should include understanding of the data to be shared, clarity about how long data will be kept and information with whom it will be shared (and for what purpose).
Best Practice 3: Enable the user to make decisions at the appropriate time with the correct contextual information.
The user should have the opportunity to decide whether to share information (and what to share) at the time it is needed. This is necessary as the decision can depend on the context, including the details of what the user is trying to accomplish, the details of that task, and differences in how the service will operate, use and share data.
Best Practice 4: When learning user privacy decisions and providing defaults, allow the user to easily view and change these previous decisions.
A service may learn and remember personal information of a user in order to improve a service. One example is remembering a billing address, another might be remembering payment information. When doing so the service should make it clear to a user which information is retained, how it is used, and give the user an opportunity to correct or remove the information.
Best Practice 5: Focus on usability and avoid needless prompting.
Focus on usability should improve a service as well as making it easier for a user to understand and control use of their personal information. Minimize use of modal dialogs as they harm the user experience and many users will not understand how to respond to prompts, choosing a choice that enables them to continue their work [GEOLOCATION-PRIVACY].
Best Practice 6: Be clear and transparent to users regarding potential privacy concerns.
The end user should understand if information is being used by the service itself or being shared with a third party, especially when third party services are involved in a "mashup".
Best Practice 7: Be clear as to whether information is needed on a one-time basis or is necessary for a period of time and for how long.
The end user should understand whether information collected is for a single use or will be retained and have an impact over time.
Review the data and how it is structured and used, minimizing the amount and detail of data required to provide a service.
Best Practice 8: Request the minimum number of data items at the minimum level of detail needed to provide a service.
As an example, an address book entry is not the natural level of granularity as a user may wish to share various individual address book fields independently. Thus the natural level of granularity in an address book is a field and no more than the necessary fields should be provided in response to an address book entry request.
Best Practice 9: Retain the minimum amount of data at the minimum level of detail for the minimum amount of time needed. Consider potential misuses of retained data and possible countermeasures.
As an example, retaining user payment information entails the risk of this information being stolen and misused. Perhaps it does not need to be retained but if it is (with user permission) perhaps it should be encrypted (to give one possible countermeasure).
Best Practice 10:
Maintain the confidentiality of user data in
transmission, for example using
transport rather than
HTTPS can provide confidentiality of
personal data in
transport when an appropriate cipher suite is
required. This should be done for sensitive personal
information unless confidentiality can be assured by other means.
Best Practice 11: Maintain the confidentiality of user data in storage.
The confidentiality of personal information should be maintained when in storage, to prevent inadvertent or malicious loss (e.g. break in to a server, theft of backups or other threats).
Best Practice 12: Control and log access to data.
Control access to information through access controls and log access.
HTTPSfor transport rather than
No normative references.