- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Fri, 15 Jul 2011 20:27:03 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-practices
In directory hutz:/tmp/cvs-serv17981
Modified Files:
Overview.html
Log Message:
review and update practices
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-practices/Overview.html,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -d -r1.12 -r1.13
--- Overview.html 14 Jul 2011 16:03:52 -0000 1.12
+++ Overview.html 15 Jul 2011 20:27:01 -0000 1.13
@@ -77,77 +77,84 @@
</section>
<section id="usercentric">
<h2>User Centric Design</h2>
- <p>Privacy should be user centric.</p>
+ <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 decisions
- that affect their privacy within the context of the service</span></p>
+ 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 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
+ 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 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>
+ class="practicelab">Enable the user to make decisions at the
+ appropriate time with the correct contextual information.
+ </span></p>
<p class="practicedesc">
- Another similar example is
- drag and drop in HTML5 where a user clearly indicates a
- desired sharing of information.
+ 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">
- These are examples of granting permission implicitly
- through action.</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">Attempt to learn user privacy
- decisions and respond to them.
+ 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">
- 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.
+ 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">Create a service that enables user
- choices and control by making it usable
+ class="practicelab">Focus on usability and avoid needless prompting.
</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]].
+ 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">
@@ -167,11 +174,11 @@
<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 and whether data retention is required.
+ time.
</span></p>
<p class="practicedesc">
- The end user should know if how collected information
- could affect their experience over time.
+ 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>
@@ -210,9 +217,7 @@
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.
+ encrypted (to give one possible countermeasure).
</p>
</div>
@@ -231,8 +236,9 @@
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>
+ 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"
@@ -241,10 +247,10 @@
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.
+ 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>
Received on Friday, 15 July 2011 20:27:08 UTC