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

2009/dap/privacy-practices Overview.html,1.9,1.10

From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 13 Jul 2011 18:16:49 +0000
To: public-dap-commits@w3.org
Message-Id: <E1Qh3zN-0004zA-Na@lionel-hutz.w3.org>
Update of /sources/public/2009/dap/privacy-practices
In directory hutz:/tmp/cvs-serv19150

Modified Files:
	Overview.html 
Log Message:
fix validation errors


Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-practices/Overview.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- Overview.html	13 Jul 2011 18:05:05 -0000	1.9
+++ Overview.html	13 Jul 2011 18:16:47 -0000	1.10
@@ -49,203 +49,205 @@
     <section id="privacybydesign">
       <h3>Privacy By Design</h3>
       <p>
-The principles of "Privacy by Design" should be reflected in the
-service 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><a id="bp-privacy-by-design"></a><span
-               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:
-<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></p>
-
-            </div>
-      </section>
-      <section id="usercentric">
+        The principles of "Privacy by Design" should be reflected in the
+        service 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><a id="bp-privacy-by-design"></a>
+        <span 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.</p>
-            <div class="practice">
-               <p><a id="bp-user-driven"></a><span
-               class="practicelab">Enable the user to decisions
-               that affect their privacy within the context of the service</span></p>
-               <p class="practicedesc">
-                 The end user should know the privacy implications of
-                 the service, and be able to make choices 
-                 based on them. Examples include 
-                 choosing the data to share, making choices about data
-                 retention and having enough information to know
-               </p>
-            </div>
-            <div class="practice">
-               <p><a id="bp-choices-in-context"></a><span
-               class="practicelab">Enable the user to make decisions in
-               context at the time of an operation requiring the
-               decision.</span></p> 
-               <p class="practicedesc">
-                 User decisions work well when the user  makes the
-                 decision in context (at the time of an
-                 action). Attempting to make decisions earlier 
-                 can be difficult since without the context can make a
-                 difference. An example is when the decision involves
-                 sharing data with a third party who could change.
-               </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>&lt;input type="file"&gt;</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><a id="bp-sp-choices"></a><span
-               class="practicelab">Attempt to learn  user privacy
-               decisions and  respond to them.
-               </span></p> 
-               <p class="practicedesc">
-                 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's
-                 retention choices.
-               </p>
-            </div>
-            <div class="practice">
-               <p><a id="bp-usability"></a><span
-               class="practicelab">Create a service that enables user
-               choices and control by making it usable
-               </span></p> 
-               <p class="practicedesc">
-                 Minimal user interface interaction should be required
-                 with minimal consent dialogs (to avoid known problem
-                 of choosing to accept only to continue work)
-                 [[GEOLOCATION-PRIVACY]].  
-               </p>
-            </div>
-            <div class="practice">
-               <p><a id="bp-clarity"></a><span
-               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><a id="bp-clarify-one-shot-or-repeated"></a><span
-               class="practicelab">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>
+      <div class="practice">
+        <p><a id="bp-user-driven"></a><span
+        class="practicelab">Enable the user to decisions
+        that affect their privacy within the context of the service</span></p>
+        <p class="practicedesc">
+          The end user should know the privacy implications of
+          the service, and be able to make choices 
+          based on them. Examples include 
+          choosing the data to share, making choices about data
+          retention and having enough information to know
+        </p>
+      </div>
+      <div class="practice">
+        <p><a id="bp-choices-in-context"></a><span
+        class="practicelab">Enable the user to make decisions in
+        context at the time of an operation requiring the
+        decision.</span></p> 
+        <p class="practicedesc">
+          User decisions work well when the user  makes the
+          decision in context (at the time of an
+          action). Attempting to make decisions earlier 
+          can be difficult since without the context can make a
+          difference. An example is when the decision involves
+          sharing data with a third party who could change.
+        </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>&lt;input type="file"&gt;</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><a id="bp-sp-choices"></a><span
+        class="practicelab">Attempt to learn  user privacy
+        decisions and  respond to them.
+        </span></p> 
+        <p class="practicedesc">
+          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's
+          retention choices.
+        </p>
+      </div>
+      <div class="practice">
+        <p><a id="bp-usability"></a><span
+        class="practicelab">Create a service that enables user
+        choices and control by making it usable
+        </span></p> 
+        <p class="practicedesc">
+          Minimal user interface interaction should be required
+          with minimal consent dialogs (to avoid known problem
+          of choosing to accept only to continue work)
+          [[GEOLOCATION-PRIVACY]].  
+        </p>
+      </div>
+      <div class="practice">
+        <p><a id="bp-clarity"></a><span
+        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><a id="bp-clarify-one-shot-or-repeated"></a><span
+        class="practicelab">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>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><a id="bp-data-granularity"></a><span
-               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><a id="bp-data-retention"></a><span
-               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). A
-                 downside of retaining information is the difficulty
-                 of explaining what is retained, and why, to end users.
-               </p>
+      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><a id="bp-data-granularity"></a><span
+          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><a id="bp-data-retention"></a><span
+          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). A
+            downside of retaining information is the difficulty
+            of explaining what is retained, and why, to end users.
+          </p>
 
-            </div>
-    </section>
+        </div>
+      </section>
     </section>
     <section id="data-confidentiality">
       <h2>Maintain the confidentiality of personal data</h2> 
-            <div class="practice">
-               <p><a id="bp-use-https"></a><span
-               class="practicelab">
-               Maintain the confidentiality of user data in
-               transmission, for example using HTTPS for
-               transport rather than HTTP.
-               </span></p> 
-               <p class="practicedesc">
-                 Use of HTTPS can provide confidentiality of personal data in
-                 transport when an appropriate cipher suite is
-                 required.  This should be done unless an alternative
-                 means of transport confidentiality is provided. </p> 
-            <div class="practice">
-               <p><a id="bp-secure-storage"></a><span
-               class="practicelab">
-               Maintain the confidentiality of user data in
-               storage.
-               </span></p> 
-               <p class="practicedesc">
-                 Store data in encrypted form or take other means to protect
-                 confidentiality of data in storage, even in the event
-                 of a security 
-                 breakin of the server.
-               </p> 
+      <div class="practice">
+        <p><a id="bp-use-https"></a><span
+        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 unless an alternative
+        means of transport confidentiality is provided. </p> 
+      </div>
+      <div class="practice">
+        <p><a id="bp-secure-storage"></a><span
+        class="practicelab">
+        Maintain the confidentiality of user data in
+        storage.
+        </span></p> 
+        <p class="practicedesc">
+          Store data in encrypted form or take other means to protect
+          confidentiality of data in storage, even in the event
+          of a security 
+          breakin of the server.
+        </p> 
+      </div>
+    </section>
   </body>
 </html>
 
Received on Wednesday, 13 July 2011 18:16:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 13 July 2011 18:16:51 GMT