- 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