- From: Dominique Hazael-Massieux via cvs-syncmail <cvsmail@w3.org>
- Date: Mon, 01 Mar 2010 13:49:43 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv4180
Modified Files:
Overview.html
Log Message:
adding section on privacy
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- Overview.html 22 Feb 2010 16:23:52 -0000 1.9
+++ Overview.html 1 Mar 2010 13:49:41 -0000 1.10
@@ -318,7 +318,7 @@
</p><p>
Although the role of any access control policy, and authority over it, are
beyond the scope of this particular issue, DAP's approach to prompting must
- take these possibilities into account.
+ take these possibilities into account.</p>
</li>
<li>Granularity of user decisions
<p class='issue'>
@@ -347,6 +347,52 @@
</section> <!-- open issues -->
</section> <!-- user control -->
<section>
+ <h2>Privacy considerations</h2>
+ <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 accomplishes 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>
+</li>
+<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>
+</li>
+<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 so, how can this information be conveyed without misleading the user in the trustiness of that information?</p>
+
+ </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
+information is hard;</li>
+<li>if users set their preferences in the user agent, they will expect the
+user agent the enforce these preferences while it cannot actually control
+the data once they've been transmitted;</li>
+<li>developers are very likely to ignore policy data sent along with the
+data they're actually interested in, and not be in a position to act
+upon these policies even if they wanted to</li>
+ </ul>
+ </div>
+ </section>
+ </section>
+
+ <section>
<h2>Identification</h2>
<section>
<h3>Requirements</h3>
@@ -382,7 +428,6 @@
application's private file, and a Bluetooth port needs to be distinguishable
from a USB serial port.
</p>
-</p>
</section>
<section class='informative'>
<h3>Open Issues for Resolution</h3>
Received on Monday, 1 March 2010 13:49:45 UTC