- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 20 Jul 2011 07:28:04 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-practices
In directory hutz:/tmp/cvs-serv10124
Added Files:
FPWD.html
Log Message:
FPWD
--- NEW FILE: FPWD.html ---
<!DOCTYPE html>
<html>
<head>
<title>Web Application Privacy Best Practices</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8' />
<script src='../ReSpec.js/js/respec.js' class='remove'></script>
<script class='remove'>
var respecConfig = {
specStatus: "FPWD",
shortName: "app-privacy-bp",
editors: [
{ name: "Frederick Hirsch", company: "Nokia", companyURL:
"http://www.nokia.com/" },
],
// publishDate: "2010-06-29",
// previousPublishDate: "1977-03-15",
edDraftURI: "http://dev.w3.org/2009/dap/privacy-practices/",
// lcEnd: "2009-08-05",
noRecTrack: true,
};
</script>
<script src='../common/config.js' class='remove'></script>
</head>
<body>
<section id='abstract'>
This document describes privacy best practices for web
applications, including those that might use device
APIs.
</section> <!-- abstract -->
<section id='sotd'>
This document 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.
</section>
<section id='introduction'>
<h2>Introduction</h2>
<p>
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.
</p>
</section>
<section id="privacybydesign">
<h3>Privacy By Design</h3>
<p>
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]].</p>
<div class="practice">
<p>
<span id="bp-privacy-by-design" class="practicelab">Follow "Privacy By Design" principles</span></p>
<p class="practicedesc">
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.
</p>
<p>These principles include the following:</p>
<ol>
<li>Proactive not Reactive; Preventative not Remedial</li>
<li>Privacy as the Default Setting</li>
<li>Privacy Embedded into Design</li>
<li> Full Functionality — Positive-Sum, not Zero-Sum</li>
<li>End-to-End Security — Full Lifecycle Protection</li>
<li>Visibility and Transparency — Keep it Open</li>
<li>Respect for User Privacy — Keep it User-Centric</li>
</ol>
</div>
</section>
<section id="usercentric">
<h2>User Centric Design</h2>
<p>Privacy should be user centric, giving the user understanding
and control over use of their personal data.</p>
<div class="practice">
<p><span id="bp-user-driven"
class="practicelab">Enable the user to make informed decisions about
sharing their personal information with a service.
</span></p>
<p class="practicedesc">
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).
</p>
</div>
<div class="practice">
<p><span id="bp-choices-in-context"
class="practicelab">Enable the user to make decisions at the
appropriate time with the correct contextual information.
</span></p>
<p class="practicedesc">
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.
</p>
<!-- <p class="practicedesc"> -->
<!-- Examples are the presentation of a "picker" -->
<!-- interface to a user for selecting contacts fields of -->
<!-- potential contacts returned from a find operation in -->
<!-- the contacts API [[CONTACTS-API]], or the selection -->
<!-- of a file in -->
<!-- response to HTML5 <code><input type="file"></code> markup -->
<!-- [[HTML5]]. In each of these cases a user makes a -->
<!-- decision of what to share in the context of their -->
<!-- current activity and indicates that decision through -->
<!-- the selection process. -->
<!-- </p> -->
<!-- <p class="practicedesc"> -->
<!-- Another similar example is -->
<!-- drag and drop in HTML5 where a user clearly indicates a -->
<!-- desired sharing of information. -->
<!-- </p> -->
<!-- <p class="practicedesc"> -->
<!-- These are examples of granting permission implicitly -->
<!-- through action.</p> -->
</div>
<div class="practice">
<p><span id="bp-sp-choices"
class="practicelab">When learning user privacy
decisions and providing defaults, allow the user to easily view and
change these previous decisions.
</span></p>
<p class="practicedesc">
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.
</p>
</div>
<div class="practice">
<p><span id="bp-usability"
class="practicelab">Focus on usability and avoid needless prompting.
</span></p>
<p class="practicedesc">
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 know how to
respond to prompts, choosing a choice that enables them to
continue their work
[[GEOLOCATION-PRIVACY]].
</p>
</div>
<div class="practice">
<p><span id="bp-clarity"
class="practicelab">Be clear and
transparent to users regarding
potential privacy concerns.
</span></p>
<p class="practicedesc">
The end user should know if information is being used
by the service itself or being shared with a third
party, especially when 3rd party services are
involved in a "mashup".
</p>
</div>
<div class="practice">
<p><span id="bp-clarify-one-shot-or-repeated"
class="practicelab">Be clear as to whether information is
needed on a one-time basis or is necessary for a period of
time.
</span></p>
<p class="practicedesc">
The end user should know whether information collected is
for a single use or will be retained and have an impact over time.
</p>
</div>
</section>
<section id="data-minimization">
<h2>Minimize collection and
transmission of personal data</h2>
<section id="minimization-considerations">
<p>Review the data and how it is structured and used, minimizing
the amount and detail of data required to provide a service.
</p>
<div class="practice">
<p><span id="bp-data-granularity"
class="practicelab">Request the minimum number of data
items at the
minimum level of detail needed to provide a service.</span></p>
<p class="practicedesc">
As an example, an address book record is not the
natural level of granularity as a user may wish to
share different individual address
book fields differently. Thus the natural level of
granularity in an address book is the field and no
more than the necessary fields should be returned in
an address book entry request.
</p>
</div>
<div class="practice">
<p><span id="bp-data-retention"
class="practicelab">
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.
</span></p>
<p class="practicedesc">
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).
</p>
</div>
</section>
</section>
<section id="data-confidentiality">
<h2>Maintain the confidentiality of personal data</h2>
<div class="practice">
<p><span id="bp-use-https"
class="practicelab">
Maintain the confidentiality of user data in
transmission, for example using <code>HTTPS</code> for
transport rather than <code>HTTP</code>.
</span></p>
<p class="practicedesc">
Use of <code>HTTPS</code> 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.
</p>
</div>
<div class="practice">
<p><span id="bp-secure-storage"
class="practicelab">
Maintain the confidentiality of user data in
storage.
</span></p>
<p class="practicedesc">
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).
</p>
</div>
</section>
<section id='bp-summary'></section>
</body>
</html>
Received on Wednesday, 20 July 2011 07:28:11 UTC