W3C home > Mailing lists > Public > public-dap-commits@w3.org > July 2011

2009/dap/privacy-practices Overview.src.html,NONE,1.1 Overview.html,1.1,1.2

From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
Date: Tue, 05 Jul 2011 21:07:23 +0000
To: public-dap-commits@w3.org
Message-Id: <E1QeCq3-0006lU-8B@lionel-hutz.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 patent 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"><span class="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-20100629/</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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 July 2011 21:07:31 GMT