- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 07 Apr 2010 16:17:45 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-reqs
In directory hutz:/tmp/cvs-serv11472
Modified Files:
Overview.html
Log Message:
Add new section on architectural approach, rewriting Robin's draft and
fitting it into introduction. Add new section "Requirements related to
User Expectations of Data Use" and sub-sections for relevant privacy
elements. Link privacy principles bullets to sections. Add use case to
minimization section as second paragraph.
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-reqs/Overview.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- Overview.html 7 Apr 2010 12:29:07 -0000 1.9
+++ Overview.html 7 Apr 2010 16:17:43 -0000 1.10
@@ -47,18 +47,88 @@
is a risk. Addressing privacy may include functional requirements in
technical standards, laws and regulations, and best practices.</p>
-<p>While privacy is an important consideration for all APIs, privacy risks may vary according to the information exposed by an individual API. For example, inappropriate disclosure of contacts or location information could create serious personal safety issues in a broad range of cases, while disclosure of certain system information might create privacy risks in fewer contexts.</p>
+<p>While privacy is an important consideration for all APIs, privacy
+ risks may vary according to the information exposed by an individual
+ API. For example, inappropriate disclosure of contacts or location
+ information could create serious personal safety issues in a broad
+ range of cases, while disclosure of certain system information might
+ create privacy risks in fewer contexts.</p>
+
+ <section>
+ <h2>Architectural Approach</h2>
+ <p>
+ Privacy is a broad topic with various aspects that involve
+ different parties in a system. In order to be clear which
+ aspects are addressed and how, we take an architectural
+ approach of breaking down the problem into smaller
+ pieces. This should provide clarity and enable
+ privacy-respecting solutions that can be adopted. We have
+ identified the following pieces:
+ </p>
+ <dl>
+ <dt>How to define APIs in such a way that they are “naturally” privacy-friendly</dt>
+ <dd><p>
+ This is similar to writing APIs in such a way that they are
+ security-friendly; you can't
+ keep people from making mistakes, but you can make it easier
+ and more natural to be privacy-respecting through the API
+ design.
+An example is supporting the concept of
+<a href="#privacy-minimization">Minimization</a> by designing APIs
+ that return the minimum data needed for a task, such as
+ only obtaining address fields when an address is needed.</p>
+ </dd>
+ <dt>Only require from user-agents what, if anything, they can realistically enforce</dt>
+ <dd><p>
+ Understanding how user-agents can help with privacy is
+ important, however implementation and adoption
+ considerations are important in this area. This can be
+ separated to a large degree from API design decisions.</p>
+ </dd>
+ <dt>Education & Outreach, similar to the accessibility efforts</dt>
+ <dd><p>
+ WAI and the Web community at large have done a great job
+ raising awareness about accessibility
+ issues, and while we certainly do not live in a perfect
+ world their effort has had a very
+ measurable impact. There is therefore experience to be
+ tapped in such an approach for the parts
+ of the problem that depend on convincing people to do the
+ right thing (which in some cases can
+ be wide-ranging such as making script libraries support the
+ solution directly, or various organizations
+ enforce it internally).</p>
+ </dd>
+ <dt>A License Approach to Privacy</dt>
+ <dd>
+ <p>Some aspects of privacy require agreements among parties
+ as to their expectations. This can be hard to manage
+ technically but might be possible through a simpler approach
+ of defining and agreeing upon conditions, similar to a
+ <a href='http://creativecommons.org/'>Creative Commons</a> license.
+ Defining a simple vocabulary
+ for privacy could enable a "privacy license" that can be
+ referenced by URI.
+ <a href='http://www.azarask.in/blog/post/is-a-creative-commons-for-privacy-possible/'>Other
+ people
+ have had this idea</a> as well.
+ </p>
+ </dd>
+ </dl>
+ </section>
+ <section>
+ <h2>Privacy Principles relevant to APIs</h2>
<p>Privacy protections are frequently understood as a set of principles or elements (one such set is described in [[PRIVACY-ISSUES-GEO]]). The core elements of privacy that are relevant to Device APIs, user agents that support the APIs, and applications that use the APIs are as follows:
<ul>
- <li><p><code>Notice:</code>Informing users about the data collected through Device APIs</p></li>
- <li><p><code>Consent:</code>Obtaining user agreement to sharing data through Device APIs</p></li>
- <li><p><code>Minimization:</code>Limiting the amount and level of detail of data collected through Device APIs</p></li>
- <li><p><code>Control:</code>Allowing users to control access to their data once they have consented to having it collected through Device APIs</p></li>
- <li><p><code>Access:</code>Providing users with access to information about the data that has been collected about them through Device APIs</p></li>
- <li><p><code>Retention:</code>Limiting how long applications retain data that was collected through Device APIs</p></li>
- <li><p><code>Secondary Use:</code>Limiting applications from using data collected through Device APIs for purposes other than the purpose for which it was collected</li></p>
- <li><p><code>Sharing:</code>Limiting applications from sharing data collected through Device APIs with third parties</p></li>
+ <li><p><code><a href="#privacy-notice">Notice</a>:</code>Informing users about the data collected through Device APIs</p></li>
+ <li><p><code><a href="#privacy-consent">Consent</a>:</code>Obtaining user agreement to sharing data through Device APIs</p></li>
+ <li><p><code><a href="#privacy-minimization">Minimization</a>:</code>Limiting the amount and level of detail of data collected through Device APIs</p></li>
+ <li><p><code><a href="#privacy-control">Control</a>:</code>Allowing users to control access to their data once they have consented to having it collected through Device APIs</p></li>
+ <li><p><code><a href="#privacy-access">Access</a>:</code>Providing users with access to information about the data that has been collected about them through Device APIs</p></li>
+ <li><p><code><a href="#privacy-retention">Retention</a>:</code>Limiting how long applications retain data that was collected through Device APIs</p></li>
+ <li><p><code><a href="#privacy-secondary-use">Secondary Use</a>:</code>Limiting applications from using data collected through Device APIs for purposes other than the purpose for which it was collected</li></p>
+ <li><p><code><a href="#privacy-sharing">Sharing</a>:</code>Limiting applications from sharing data collected through Device APIs with third parties</p></li>
</ul>
</p>
@@ -131,7 +201,7 @@
<p> The privacy requirements for individual APIs are provided in the next section. The requirements described in this document are intended
to be applicable to device APIs both in the context of widgets and web applications.</p>
</p>
-
+</section>
<div class="issue"><p>The breakdown described above foreshadows the idea of providing API hooks that allow users to attach their expectations/preferences/policies about privacy to the data they share through the APIs. 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>
@@ -214,7 +284,12 @@
<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>An example use case is a social networking case where the contacts
+ API is used to contacts who are also members of a
+ social network. Email addresses serve as the social network
+ handles. In this case limiting results to the addresses and not
+ other personal information is an example of minimization.
+</p>
<p>Requirements could address: API support for limiting the amount of information requested/returned, whether APIs require UAs to allow users to change or limit the amount or granularity of data sent to applications.
Examples of potential requirements include:</p>
@@ -229,7 +304,8 @@
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
+of a user address book, it should be possible to explicitly mark that
+ field in the
API call so that the user agent can inform the user that this single
field of data will be shared.</p>
</li>
@@ -264,8 +340,44 @@
</section> <!-- access -->
</section>
+<section id="privacy-user-expectations">
+<h4>Requirements related to User Expectations of Data Use</h4>
+<p>Users may have expectations of how their data is used, in
+ particular related to data retention, use for other purposes, and
+ sharing.
+How applications specify how they plan to meet these expectations
+ (application policy), how users express their desires (user policy)
+ and contrstraints on data use may all be related to managing these
+ expectations. A license approach similar to Creative Commons may
+ offer a simple manner to address these requirements.
+</p>
+<section id="privacy-retention">
+<h4>Retention</h4>
+<p>Retention is about to user expectations about how long data they
+ provide will be retained, and whether applications must dispose of
+ collected data after
+fulfilling the purpose for which it was collected.</p>
+</section> <!-- retention -->
+
+<section id="privacy-secondary-use">
+<h4>Secondary Use</h4>
+<p>Secondary Use is about to user expectations regarding whether
+ applications can use data for purposes other than that for which
+the data was collected.</p>
+</section> <!-- secondary use -->
+<section id="privacy-sharing">
+<h4>Sharing</h4>
+<p>Sharing is about user expectations on how data will be shared. Once
+ data have been made available to a requester, the
+requester is in a position to store and redistribute these data, with
+or without the user consent. Granularity of data shared is an
+ important aspect of sharing.</p>
+
+</section> <!-- sharing -->
+
+</section>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
Received on Wednesday, 7 April 2010 16:17:47 UTC