- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Tue, 05 Jul 2011 21:07:23 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-practices
In directory hutz:/tmp/cvs-serv25990
Modified Files:
Overview.html
Added Files:
Overview.src.html
Log Message:
first draft of privacy best practices
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-practices/Overview.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -d -r1.1 -r1.2
--- Overview.html 13 Apr 2011 14:04:03 -0000 1.1
+++ Overview.html 5 Jul 2011 21:07:21 -0000 1.2
@@ -1,45 +1,195 @@
-<!DOCTYPE html>
-<html>
- <head>
- <title>Device API Privacy Requirements</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: "ED",
- shortName: "dap-privacy-practices",
- 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/configPolicy.js' class='remove'></script>
+<!DOCTYPE html PUBLIC '-//W3C//DTD HTML 4.01 Transitional//EN' 'http://www.w3.org/TR/html4/loose.dtd'>
+<html lang="en" dir="ltr">
+<head>
+ <title>Device API Privacy Best Practices</title>
+ <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+
+
+
- </head>
- <body>
- <section id='abstract'>
- This document provides privacy best practices relevant to device
+ <link href="http://www.w3.org/StyleSheets/TR/W3C-ED" rel="stylesheet" type="text/css" charset="utf-8"></head><body style="display: inherit; "><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a></p><h1 class="title" id="title">Device API Privacy Best Practices</h1><h2 id="w3c-editor-s-draft-05-july-2011">W3C Editor's Draft 05 July 2011</h2><dl><dt>This version:</dt><dd><a href="http://dev.w3.org/2009/dap/privacy-practices/">http://dev.w3.org/2009/dap/privacy-practices/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/dap-privacy-practices/">http://www.w3.org/TR/dap-privacy-practices/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dev.w3.org/2009/dap/privacy-practices/">http://dev.w3.org/2009/dap/privacy-practices/</a></dd><dt>Previous version:</dt><dd>none</dd><dt>Editor:</dt><dd><span>Frederick Hirsch</span>, <a href="http://www.nokia.com/">Nokia</a></dd>
+</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p><hr></div>
+ <div id="abstract" class="introductory section"><h2>Abstract</h2>
+ This document describes privacy best practices relevant to device
APIs.
- </section> <!-- abstract -->
-
- <section id='sotd'>
+ </div><div id="sotd" class="introductory section"><h2>Status of This Document</h2><p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
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>
+ <p>This document was published by the <a href="http://www.w3.org/2009/dap/">Device APIs and Policy Working Group</a> as an Editor's Draft. If you wish to make comments regarding this document, please send them to <a href="mailto:public-device-apis@w3.org">public-device-apis@w3.org</a> (<a href="mailto:public-device-apis-request@w3.org?subject=subscribe">subscribe</a>, <a href="http://lists.w3.org/Archives/Public/public-device-apis/">archives</a>). All feedback is welcome.</p><p>Publication as a Editor's 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.</p><p>This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a href="http://www.w3.org/2004/01/pp-impl/43696/status" rel="disclosure">public list of any patet disclosures</a> 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 <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a></li><li class="tocline"><a href="#generalprinciples" class="tocxref"><span class="secno">2. </span>General Principles</a><ul class="toc"><li class="tocline"><a href="#privacybydesign" class="tocxref"><span class="secno">2.1 </span>Privacy By Design</a></li><li class="tocline"><a href="#usercentric" class="tocxref"><spanclass="secno">2.2 </span>User Centric Design</a></li></ul></li><li class="tocline"><a href="#transparency" class="tocxref"><span class="secno">3. </span>Transparency</a><ul class="toc"><li class="tocline"><a href="#clarity" class="tocxref"><span class="secno">3.1 </span>Clarity of privacy issues</a></li><li class="tocline"><a href="#repetition" class="tocxref"><span class="secno">3.2 </span>One shot or repetition</a></li></ul></li><li class="tocline"><a href="#data-requests" class="tocxref"><span class="secno">4. </span>Requesting Data</a><ul class="toc"><li class="tocline"><a href="#minimization-considerations" class="tocxref"><span class="secno">4.1 </span>Consider the natural data granularity with respect to
+ minimization</a></li><li class="tocline"><a href="#data-reuse-considerations" class="tocxref"><span class="secno">4.2 </span>Consider ramifications of data re-use over time</a></li></ul></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">A. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">A.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">A.2 </span>Informative references</a></li></ul></li></ul></div> <!-- abstract -->
+
+
+
+ <div id="introduction" class="section">
+ <!--OddPage--><h2><span class="secno">1. </span>Introduction</h2>
+ <p>
+ This document outlines good privacy practices for implementers of
+ device APIs. It is a companion to the privacy principles and
+ requirements documented in the Device API Privacy Requirements Note
+ [<cite><a class="bibref" rel="biblioentry" href="#bib-DAP-PRIVACY-REQS">DAP-PRIVACY-REQS</a></cite>],
+ [<cite><a class="bibref" rel="biblioentry" href="#bib-GEOLOCATION-PRIVACY">GEOLOCATION-PRIVACY</a></cite>].
+ </p>
+ </div>
+ <div id="generalprinciples" class="section">
+ <!--OddPage--><h2><span class="secno">2. </span>General Principles</h2>
+ <div id="privacybydesign" class="section">
+ <h3><span class="secno">2.1 </span>Privacy By Design</h3>
+ <p>Privacy should be considered from the beginning of design and
+ implementation.</p>
+ <div class="practice">
+ <p><a id="bp-privacy-by-design"></a><span class="practicelab">Consider privacy as part of design</span></p>
+ <p class="practicedesc">
+ Consider privacy when designing a service at the very
+ beginning.
+ </p>
+ </div>
+ </div>
+ <div id="usercentric" class="section">
+ <h3><span class="secno">2.2 </span>User Centric Design</h3>
+ <p>Privacy should be user centric.</p>
+ <div class="practice">
+ <p><a id="bp-user-centric-privacy"></a><span class="practicelab">The user should drive decisions
+ that affect their privacy within the context of the service</span></p>
+ <p class="practicedesc">
+ The end user should know the privacy considerations
+ affecting the service, and be able to make choices
+ based on those considerings. Examples including
+ choosing the data to share, choices about data
+ retention and having enough information to know
+ whether or not to use the service.
+ </p>
+ </div>
+ <div class="practice">
+ <p><a id="bp-choices-in-context"></a><span class="practicelab">User decisions should be made in
+ context at the time of an operation requiring a
+ decision.</span></p>
+ <p class="practicedesc">
+ </p><p>
+ User decisions work well when the user knows what
+ they are deciding about and when they make the
+ decision in context (at the time) - earlier decisions
+ may have different effect
+ when making a decision in real-time there are
+ task-specific decisions that need to be related to a
+ default ancillary - who is in the best position to
+ interact with the user, for example when considering
+ secondary use.
+ </p>
+ </div>
+ <div class="practice">
+ <p><a id="bp-sp-choices"></a><span class="practicelab">A service provider should have the
+ opportunity to know a user privacy decision and respond
+ to it.
+ </span></p>
+ <p class="practicedesc">
+ </p><p>
+ Knowing the privacy preferences of a user in a given
+ context, a service provider may be able to offer
+ different options. As an example, a service provider
+ could remember certain information (e.g. shipping
+ address) or require re-entry, depending on the user
+ retention choices.
+ </p>
+ </div>
+ <div class="practice">
+ <p><a id="bp-usability"></a><span class="practicelab">User centric design requires usability.
+ </span></p>
+ <p class="practicedesc">
+ </p><p>
+ Minimal user interface interaction should be required
+ with minimal consent dialogs (to avoid known problem
+ of choosing to accept only to continue work).
+ </p>
+ </div>
+ </div>
+ </div>
+ <div id="transparency" class="section">
+ <!--OddPage--><h2><span class="secno">3. </span>Transparency</h2>
+ <div id="clarity" class="section">
+ <h3><span class="secno">3.1 </span>Clarity of privacy issues</h3>
+ <p>Services should be clear and transparent to users regarding
+ potential privacy concerns.</p>
+ <div class="practice">
+ <p><a id="bp-user-centric-privacy"></a><span class="practicelab">Clarify where collected information
+ is shared, especially when 3rd party services are
+ involved in a "mashup".
+ </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, for example a location provider.
+ </p>
+ </div>
+ </div>
+ <div id="repetition" class="section">
+ <h3><span class="secno">3.2 </span>One shot or repetition</h3>
+ <p>Services should be clear as to whether information is
+ needed on a one-time basis or is necessary for a period of time.
+ </p>
+ <div class="practice">
+ <p><a id="bp-user-centric-privacy"></a><span class="practicelab">Clear indicate whether information
+ is needed once or repeatedly, and if repeatedly whether
+ or not it will be saved.
+ </span></p>
+ <p class="practicedesc">
+ The end user should know if how collected information
+ could affect their experience over time.
+ </p>
+ </div>
+ </div>
+ </div>
+ <div id="data-requests" class="section">
+ <!--OddPage--><h2><span class="secno">4. </span>Requesting Data</h2>
+ <div id="minimization-considerations" class="section">
+ <h3><span class="secno">4.1 </span>Consider the natural data granularity with respect to
+ minimization</h3>
+ <p>Review the data and how it is structured and used.
+ </p>
+ <div class="practice">
+ <p><a id="bp-data-granularity"></a><span class="practicelab">Review the granularity of the data
+ and attempt to provide minimal data at the "natural"
+ granularity.</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>
+ <div id="data-reuse-considerations" class="section">
+ <h3><span class="secno">4.2 </span>Consider ramifications of data re-use over time</h3>
+ <p>Review whether data needs to be retained, for how long and
+ what the potential misuses of that data might be.
+ </p>
+ <div class="practice">
+ <p><a id="bp-data-retention"></a><span class="practicelab">Review what the minimim data that
+ needs to be retained and the minimum period it should
+ be retained. Consider potential misuses of the 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). A
+ downside of retaining information is the difficulty
+ of explaining what is retained, and why, to end users.
+ </p>
+
+ </div>
+ </div>
+ </div>
+
+
- <section id='introduction'>
- <h2>Introduction</h2>
- <p></p>
- </section>
- </body>
-</html>
+<div id="respec-err" style="position: fixed; width: 350px; top: 10px; right: 10px; border: 3px double #f00; background: #fff" class="removeOnSave"><ul><li style="color: #c00">There appears to have been a problem fetching the style sheet; status=0</li></ul></div><div id="references" class="appendix section"><!--OddPage--><h2><span class="secno">A. </span>References</h2><div id="normative-references" class="section"><h3><span class="secno">A.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">A.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-DAP-PRIVACY-REQS">[DAP-PRIVACY-REQS]</dt><dd>Alissa Cooper, Frederick Hirsch, John Morris. <a href="http://dev.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/"><cite>Device API Privacy Requirements</cite></a> 29 June 2010. W3C Note URL: <a href="http://dev.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/">http://dev.w3.org/TR/2010/NOTE-dap-privacy-reqs-2010069/</a>
+</dd><dt id="bib-GEOLOCATION-PRIVACY">[GEOLOCATION-PRIVACY]</dt><dd>Marcos Cáceres <a href="http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf"><cite>Privacy of Geolocation Implementations</cite></a>, "W3C Workshop on Privacy for Advanced Web APIs" paper, 12/13 July 2010. URL: <a href="http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf">http://www.w3.org/2010/api-privacy-ws/papers/privacy-ws-21.pdf</a>
+</dd></dl></div></div></body></html>
\ No newline at end of file
--- NEW FILE: Overview.src.html ---
<!DOCTYPE html>
<html>
<head>
<title>Device API 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: "ED",
shortName: "dap-privacy-practices",
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 relevant to 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 implementers of
device APIs. It is a companion to the privacy principles and
requirements documented in the Device API Privacy Requirements Note
[[DAP-PRIVACY-REQS]],
[[GEOLOCATION-PRIVACY]].
</p>
</section>
<section id="generalprinciples">
<h2>General Principles</h2>
<section id="privacybydesign">
<h3>Privacy By Design</h3>
<p>Privacy should be considered from the beginning of design and
implementation.</p>
<div class="practice">
<p><a id="bp-privacy-by-design"></a><span
class="practicelab">Consider privacy as part of design</span></p>
<p class="practicedesc">
Consider privacy when designing a service at the very
beginning.
</p>
</div>
</section>
<section id="usercentric">
<h2>User Centric Design</h2>
<p>Privacy should be user centric.</p>
<div class="practice">
<p><a id="bp-user-driven"></a><span
class="practicelab">The user should drive decisions
that affect their privacy within the context of the service</span></p>
<p class="practicedesc">
The end user should know the privacy considerations
affecting the service, and be able to make choices
based on those considerings. Examples including
choosing the data to share, choices about data
retention and having enough information to know
whether or not to use the service.
</p>
</div>
<div class="practice">
<p><a id="bp-choices-in-context"></a><span
class="practicelab">User decisions should be made in
context at the time of an operation requiring a
decision.</span></p>
<p class="practicedesc">
<p>
User decisions work well when the user knows what
they are deciding about and when they make the
decision in context (at the time) - earlier decisions
may have different effect
when making a decision in real-time there are
task-specific decisions that need to be related to a
default ancillary - who is in the best position to
interact with the user, for example when considering
secondary use.
</p>
</div>
<div class="practice">
<p><a id="bp-sp-choices"></a><span
class="practicelab">A service provider should have the
opportunity to know a user privacy decision and respond
to it.
</span></p>
<p class="practicedesc">
<p>
Knowing the privacy preferences of a user in a given
context, a service provider may be able to offer
different options. As an example, a service provider
could remember certain information (e.g. shipping
address) or require re-entry, depending on the user
retention choices.
</p>
</div>
<div class="practice">
<p><a id="bp-usability"></a><span
class="practicelab">User centric design requires usability.
</span></p>
<p class="practicedesc">
<p>
Minimal user interface interaction should be required
with minimal consent dialogs (to avoid known problem
of choosing to accept only to continue work).
</p>
</div>
</section>
</section>
<section id="transparency">
<h2>Transparency</h2>
<p>Services should be clear and transparent to users regarding
potential privacy concerns.</p>
<div class="practice">
<p><a id="bp-clarity"></a><span
class="practicelab">Clarify where collected information
is shared, especially when 3rd party services are
involved in a "mashup".
</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, for example a location provider.
</p>
</div>
<p>
</p>
<div class="practice">
<p><a id="bp-clarify-one-shot-or-repeated"></a><span
class="practicelab">Services should be clear as to whether information is
needed on a one-time basis or is necessary for a period of time and whether data retention is required.
</span></p>
<p class="practicedesc">
The end user should know if how collected information
could affect their experience over time.
</p>
</div>
</section>
<section id="data-minimization">
<h2>Minimizing Data</h2>
<section id="minimization-considerations">
<p>Review the data and how it is structured and used, minimizing what is required to provide a service.
</p>
<div class="practice">
<p><a id="bp-data-granularity"></a><span
class="practicelab">Review the granularity of the data
and attempt to provide minimal data at the "natural"
granularity.</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><a id="bp-data-retention"></a><span
class="practicelab">
Consider ramifications of data re-use over time, and review what minimum data
needs to be retained, and for how long.
Consider potential misuses of the 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). A
downside of retaining information is the difficulty
of explaining what is retained, and why, to end users.
</p>
</div>
</section>
</section>
</body>
</html>
Received on Tuesday, 5 July 2011 21:07:30 UTC