- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 13 Jul 2011 18:16:49 +0000
- To: public-dap-commits@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><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><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><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><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 UTC