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

2009/dap/privacy-practices FPWD.html,NONE,1.1

From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
Date: Wed, 20 Jul 2011 07:28:04 +0000
To: public-dap-commits@w3.org
Message-Id: <E1QjRCO-0002da-2h@lionel-hutz.w3.org>
Update of /sources/public/2009/dap/privacy-practices
In directory hutz:/tmp/cvs-serv10124

Added Files:
	FPWD.html 
Log Message:
FPWD

--- NEW FILE: FPWD.html ---
<!DOCTYPE html>
<html>
  <head>
    <title>Web Application 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: "FPWD",
      shortName:            "app-privacy-bp",
      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 for web
      applications, including those that might use 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 web
        applications, including those that might use 
        device APIs. This continues the work on privacy best practices
        in section 3.3.1 on "User Awareness and Control"  Mobile Web Application Best Practices [[MWABP]]. It does not repeat the privacy principles and
        requirements documented in the Device API Privacy Requirements Note
        [[DAP-PRIVACY-REQS]] which should also be consulted.
      </p>
    </section>
    <section id="privacybydesign">
      <h3>Privacy By Design</h3>
      <p>
        The principles of "Privacy by Design" should be reflected in the
        web application 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>
        <span id="bp-privacy-by-design" 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, 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 make informed decisions about
            sharing their personal information with a service.
        </span></p>
        <p class="practicedesc">
          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 at the
        appropriate time with the correct contextual information.
        </span></p> 
        <p class="practicedesc">
          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"> -->
<!--           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><span id="bp-sp-choices"
        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">
          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">Focus on usability and avoid needless prompting.
        </span></p> 
        <p class="practicedesc">
          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">
        <p><span id="bp-clarity"
        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><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.
        </span></p>
        <p class="practicedesc">
          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>
    <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><span id="bp-data-granularity"
          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><span id="bp-data-retention"
          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).
          </p>

        </div>
      </section>
    </section>
    <section id="data-confidentiality">
      <h2>Maintain the confidentiality of personal data</h2> 
      <div class="practice">
        <p><span id="bp-use-https"
        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 for sensitive personal
          information unless confidentiality can be assured by other means.
        </p> 
      </div>
      <div class="practice">
        <p><span id="bp-secure-storage"
        class="practicelab">
        Maintain the confidentiality of user data in
        storage.
        </span></p> 
        <p class="practicedesc">
          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>
    <section id='bp-summary'></section>
  </body>
</html>
Received on Wednesday, 20 July 2011 07:28:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 July 2011 07:28:13 GMT