- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 10 Mar 2010 10:53:36 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv16904
Modified Files:
Overview.html
Log Message:
integrating allisa's rewrite http://www.w3.org/mid/A4F11E1D-2865-43BA-9CCA-D1C72B132447@cdt.org
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -d -r1.16 -r1.17
--- Overview.html 2 Mar 2010 22:51:00 -0000 1.16
+++ Overview.html 10 Mar 2010 10:53:33 -0000 1.17
@@ -527,7 +527,8 @@
</section> <!-- open issues -->
</section> <!-- user control -->
<section>
- <h2>Privacy considerations</h2>
+<h2>Privacy considerations</h2>
+
<p>Privacy considerations are important to Device APIs, since misuse of
information can have financial, physical safety, and reputation
impacts, among others. Privacy needs a systemic solution, including
@@ -537,74 +538,250 @@
the technical standards, laws and regulations, and best practices.
When privacy concerns are not appropriately met, legal remedies in the
courts may be required after the fact. Thus it is important that
-privacy is addressed appropriately up-front.
-</p>
- <p>[[PRIVACY-ISSUES-GEO]] raises several aspects that APIs that
- expose user private data should take into consideration.
+privacy is addressed appropriately up-front.</p>
+
+<p>[[PRIVACY-ISSUES-GEO]] raises several aspects that APIs that
+expose user private data should take into consideration.
In general these concerns apply to all APIs, though the impact of
privacy risks may vary with individual API. For example, inappropriate
disclosure of contacts or location information could have serious
personal safety issues, while other system type information
- disclosures might
+disclosures might
have fewer issues.
</p>
- <section>
- <h3>Minimization</h3>
- <p>To reduce the risks of over-exposing users data, it is helpful to design APIs so that Web developers can request as little information as they need to accomplish their goals.</p>
- <p>To that end:</p>
- <ul>
- <li><p>APIs SHOULD make it easy to request as little information as required for the intended usage.</p>
-<p>For instance, an API call should require specific parameters to be set to obtain more information, and should default to little or no information.</p>
+
+<section>
+<h3>Types of Privacy Requirements</h3>
+
+<p>There are four potential types of privacy requirements for device
+APIs:</p>
+<ul>
+<li><p>T1: Requirements for functionality provided strictly by user
+agents (without relation to any policy information provided by an
+application or a user)</p></li>
+<li><p>T2: Requirements for policies to be provided by applications</
+p></li>
+<li><p>T3: Requirements for policies to be provided by users</p></li>
+<li><p>T4: Requirements for what applications can do with the data
+they receive</p></li>
+</ul>
+
+<p>An example of T1 would be akin to the Geolocation requirement that
+user agents must obtain express user permission before sending
+location. An example of T2 would be a requirement that applications
+provide information about the purpose, secondary uses, retention time,
+or other policies about the data they are requesting to the UA so that
+they may be accessible to users. An example of T3 would be a
+requirement that UAs provide a way for users to send information about
+their policy preferences -- "don't disclose my data to anyone" or
+"make my data public" for example -- to applications. An example of T4
+would be akin to the Geolocation requirement that applications must
+only use the location information for the task for which it was
+provided to them.</p>
+
+<p class="issue">Will the document support all four types of
+requirements, and if not, which subset will it support? If the
+document supports requirements of types T2 or T3, will it provide
+hooks to allow the exchange of policies to be automated? How each
+aspect of privacy gets addressed (or not) will depend on which kinds
+of requirements are included. The Geolocation WG ultimately decided to
+support only requirements of types T1, T2, and T4, without automated
+support for T2 (i.e., there are normative requirements for what
+applications are supposed to disclose to users on their own sites, but
+as [[PRIVACY-ISSUES-GEO]] points out, most sites implementing the API
+are not complying).</p>
+</section>
+
+<section>
+<h3>Aspects of Privacy</h3>
+<p>The sections below enumerate a set of privacy aspect and give
+examples of the kinds of issues that each of the four types of
+requirements could address for each aspect (where applicable -- not
+every type applies to every aspect). In some cases specific examples
+of potential requirements are provided.</p>
+
+<section>
+<h4>Notice</h4>
+
+<p>T1: Whether the UA needs to notify users before their data is sent
+to a application; how that notification happens; what that notice
+should contain; whether the UA needs to notify users as their data is
+sent to applications</p>
+
+<p>T2: Whether applications need to provide notice of the fact that
+they are collecting user data and the primary purpose for which it is
+being collected; how that notification happens; what that notice
+should contain</p>
+
+<p class="issue">Should the APIs have a hook for applications to
+convey the intended usage of the data? If they do, should it be a
+required parameter? And how can this information be conveyed without
+misleading the user in the trustiness of that information?</p>
+
+<p class="issue">Is it possible to provide an indicator that personal
+information is being used, and enable follow up action from the user
+to determine how it is being used? (e.g. visual indicator and means to
+access log)</p>
+</section>
+
+<section>
+<h4>Consent</h4>
+
+<p>T1: Whether the UA needs to obtain consent of users to send their
+data to applications; how robust that consent needs to be (i.e.,
+"express," "affirmative," "implied," "implicit," or something else);
+how that consent is obtained; whether that consent should be
+remembered by the UA</p>
+
+<p>See <a href="#user-control-over-decisions">User Control over
+Decisions</a> for a general discussion about requirements for
+obtaining user consent.</p>
+</section>
+
+<section>
+<h4>Minimization</h4>
+
+<p>To reduce the risks of over-exposing users data, it is helpful to
+design APIs so that Web developers can request as little information
+as they need to accomplish their goals.</p>
+
+<p>T1: Whether the UA needs to allow users to change or limit the
+amount, granularity and/or frequency of data sent to applications.
+Examples of potential requirements of type T1 include:</p>
+
+<ul>
+<li><p>APIs SHOULD make it easy to request as little information as
+required for the intended usage.</p>
+<p>For instance, an API call should require specific parameters to be
+set to obtain more information, and should default to little or no
+information.</p>
</li>
-<li><p>APIs SHOULD make it possible for user agents to convey the breadth of
+<li><p>APIs SHOULD make it possible for user agents to convey the
+breadth of
information that the requester is asking for.</p>
-<p>For instance, if a developer only needs to access a specific field of a user addressbook, that field should be explicitly markable in the API call so that the user agent can inform the user that this single field of data will be shared.</p>
+<p>For instance, if a developer only needs to access a specific field
+of a user addressbook, that field should be explicitly markable in the
+API call so that the user agent can inform the user that this single
+field of data will be shared.</p>
</li>
-<li><p>APIs SHOULD make it possible for user agents to let the user select
+<li><p>APIs SHOULD make it possible for user agents to let the user
+select
and filter information before it is shared with the requester.</p>
-<p>The user agent can then act as a broker for trusted data, and will only transmit data to the requester that the user has explicitly allowed.</p></li>
- </ul>
- </section>
- <section>
- <h3>Appropriateness</h3>
- <p>When making a decision about sharing or not some private data, the user needs to understand how these data will be used by the requester.</p>
- <p class="issue">Should the APIs have a hook to convey the intended usage of the data? If they do, should it be a required parameter? And how can this information be conveyed without misleading the user in the trustiness of that information?</p>
+<p>The user agent can then act as a broker for trusted data, and will
+only transmit data to the requester that the user has explicitly
+allowed.</p></li>
+</ul>
- </section>
- <section>
- <h3>User consent</h3>
- <p>See <a href="#user-control-over-decisions">User Control over Decisions</a>.</p>
- </section>
- <section>
- <h3>Data storage and redistribution</h3>
- <p>Once the data have been made available to the requester, the requester is in a position to store and redistribute these data, with or without the user consent.</p>
- <div class="issue"><p>Attaching policy rules to the data that get shared can provide a legal basis for enhancing the control users have over their data once they are shared; but doing so create the following challenges:</p>
- <ul><li>getting the user to understand and set rules on sharing their
+<p>T2: Whether applications can specify their desired amount,
+granularity or frequency</p>
+
+<p>T3: Whether users can specify their desired amount, granularity or
+frequency to applications</p>
+
+<p>T4: Whether applications must request the minimal data necessary
+for their purposes</p>
+</section>
+
+<section>
+<h4>Control</h4>
+
+<p>T1: Whether the UA needs to provide a mechanism for consent to be
+revoked; what revoking consent means; what the default settings are
+for whether and to whom user data is sent; what the default settings
+are for granularity and frequency; whether the UA needs to provide a
+mechanism for users to whitelist trusted applications or blacklist
+untrusted applications</p>
+</section>
+
+<section>
+<h4>Access</h4>
+
+<p>T1: Whether the UA needs to allow users to view the applications
+with whom they've shared data and at what granularity and frequency;
+whether the UA needs to allow users to view the history of the user's
+data sharing with each application; whether the UA needs to allow
+users to delete history entries or whole histories</p>
+</section>
+
+<section>
+<h4>Retention</h4>
+
+<p>T2: Whether applications can specify how long they would like to
+retain user data</p>
+
+<p>T3: Whether users can specify how long they would like applications
+to retain their data</p>
+
+<p>T4: Whether applications must dispose of collected data after
+fulfilling the purpose for which it was collected; whether
+applications are bound by some default retention period</p>
+</section>
+
+<section>
+<h4>Identifiability</h4>
+
+<p>T2: Whether applications can specify that they would like to link
+the requested data to the user's identity or identifier</p>
+
+<p>T3: Whether users can specify their preference about having
+requested data linked to their identities or identifiers</p>
+
+<p>T4: Whether applications must use data in the least identifiable
+format as possible; whether requesters must de-identify data as soon
+as it is no longer needed in identifiable form</p>
+</section>
+
+<section>
+<h4>Secondary Use</h4>
+
+<p> T2: Whether applications can specify secondary purposes for which
+they would like to use the data (other than the primary purpose)</p>
+
+<p> T3: Whether users can specify their preferences about having their
+data used for secondary purposes</p>
+
+<p> T4: Whether applications can use data for secondary purposes</p>
+</section>
+
+<section>
+<h4>Disclosure</h4>
+
+<p>Once the data have been made available to the requester, the
+requester is in a position to store and redistribute these data, with
+or without the user consent.</p>
+
+<p> T2: Whether applications can specify that they would like to
+disclose user data, to whom, at what granularity, and at what
+identifiability</p>
+
+<p> T3: Whether users can specify their preferences about having their
+data disclosed, to whom, at what granularity, and at what
+identifiability</p>
+
+<p> T4: Whether applications can disclose data to third parties, to
+whom, at what granularity, and at what identifiability</p>
+</section>
+
+<div class="issue"><p>Attaching policy rules to the data that get
+shared can provide a legal basis for enhancing the control users have
+over their data once they are shared; but doing so create the
+following challenges:</p>
+<ul><li>getting the user to understand and set rules on sharing their
information is hard;</li>
-<li>if users set their preferences in the user agent, they will expect the
+<li>if users set their preferences in the user agent, they will expect
+the
user agent to enforce these preferences while it cannot actually control
the data flow once the data has been transmitted;</li>
-<li>developers are very likely to ignore policy rules sent along with the
+<li>developers are very likely to ignore policy rules sent along with
+the
data they're actually interested in, and may not be in a position to act
upon these policies even if they wanted to</li>
- </ul>
- </div>
- </section>
- <section>
- <h3>Notice, Transparency and Feedback</h3>
- <p>When a requestor needs data, is the user informed how the data
- will be used, and in general how to access the privacy policy? Can
- the user specify rules on the use of their data, taking an active
- role in managing their privacy? Can
- the user access a log to determine how their information was used
- and by whom?</p>
- <div class="issue"><p>Is it possible to provide an indicator that
- personal information is being used, and enable follow up action
- from the user to determine how it is being used? (e.g. visual
- indicator and means to access log)
- </p> </div>
- </section>
- </section>
+</ul>
+
+</div>
+</section>
+
+</section>
<section>
<h2>Identification</h2>
Received on Wednesday, 10 March 2010 10:53:37 UTC