- From: Alissa Cooper via cvs-syncmail <cvsmail@w3.org>
- Date: Sat, 01 May 2010 17:33:27 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-reqs
In directory hutz:/tmp/cvs-serv3544
Modified Files:
Overview.html
Log Message:
Incorporated edits per ACTION-168
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-reqs/Overview.html,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- Overview.html 7 Apr 2010 16:31:28 -0000 1.13
+++ Overview.html 1 May 2010 17:33:25 -0000 1.14
@@ -39,9 +39,7 @@
</section>
<section id='introduction'>
<h2>Introduction</h2>
- <p>Privacy considerations are important to Device APIs, since misuse of
- information exposed by the APIs can have financial, physical safety, and reputation
- impacts, among others. Privacy needs a systemic solution that includes
+ <p>Privacy considerations are important to Device APIs, since misuse of information exposed by the APIs can have potentially harmful financial, physical safety, reputational and other impacts. Privacy needs a systemic solution that includes
functional requirements on user agents, web sites and other components
of the system, since any opportunity for misuse of private information
is a risk. Addressing privacy may include functional requirements in
@@ -66,7 +64,7 @@
identified the following pieces:
</p>
<dl>
- <dt>How to define APIs in such a way that they are “naturally” privacy-friendly</dt>
+ <dt>Defining APIs in such a way that they are as “naturally” privacy-respecting as possible</dt>
<dd><p>
This is similar to writing APIs in such a way that they are
security-friendly; you can't
@@ -78,41 +76,32 @@
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>
+ <dt>Requiring from user agents what they can realistically enforce</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>
+ User agents are crucial to ensuring that user privacy is protected, but this capability must take implementation and adoption considerations into account. User agent design decisions can be separated to a large degree from API design decisions.</p>
</dd>
- <dt>A License Approach to Privacy</dt>
+ <dt>Empowering users to express privacy preferences</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.
+ <p>This can be hard to manage technically but might be possible through a simpler approach of defining and agreeing upon a small set of privacy preferences, similar to
+ <a href='http://creativecommons.org/'>Creative Commons</a> copyright licenses, that users can attach to their data.
Defining a simple vocabulary
- for privacy could enable a "privacy license" that can be
+ for privacy could enable <a href="http://dev.w3.org/2009/dap/privacy-rulesets/">privacy rulesets</a> 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>
+
+<dt>Conducting education and 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 implementations are not perfect, 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, including making script libraries support the solution directly, or having various organizations enforce it internally).</p>
</dd>
</dl>
</section>
@@ -164,7 +153,7 @@
<td><a href="#privacy-consent">Consent</a></td>
<td style="text-align:center">X</td>
<td style="text-align:center"></td>
- <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
</tr>
<tr>
<td><a href="#privacy-minimization">Minimization</a></td>
@@ -213,55 +202,43 @@
<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>
- <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
+ <ul><li>getting the user to understand and set rules on sharing their information, and to understand that limits of those rules, is hard;</li>
+ <li>if users set their preferences in the user agent, they may 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
- data they're actually interested in, and may not be in a position to act
- upon these policies even if they wanted to</li>
+ <li>developers may ignore policy rules sent along with the data they're actually interested in (at the risk of encountering legal or market consequences)</li>
</ul>
</div>
-<div class="issue"><p>It seems like the overall architectural approach that we discussed in Prague (with user expectation/preference bundle URIs passed via API hooks) needs to be described somewhere. Is this doc the right place?</p></div>
</section> <!-- introduction -->
<section id="privacy-requirements">
<h3>Requirements for API Definitions</h3>
-<p class="issue">For most of the privacy elements that apply to APIs (except for minimization), the WG has not discussed what the specific requirements should be. Therefore most of the sections below simply list what requirements could address.</p>
-
+<p>Many of the requirements listed here are recommendations (SHOULDs) rather than absolute requirements (MUSTs). In many cases this is because making a requirement absolute is appropriate for only a subset of the APIs, but not every API. As appropriate, individual APIs may place stronger normative requirements on user agents than the requirements in this document place on APIs.</p>
<section id="privacy-notice">
<h4>Notice</h4>
-<p>Requirements could address: Whether APIs should provide ways for UAs to notify users before their data is sent
-to applications; how that notification happens; what that notice
-should contain</p>
+<p>Making sure that users understand the implications of using an application that relies on a Device API is fundamental to ensuring the protection of their data. The following requirements can help to make sure that users are properly notified:</p>
+
+<ul>
+ <li><p>
+APIs MUST make it possible for user agents to notify users that their data is being collected via the API. This notification MUST identify the application (for example, by displaying its document origin [[HTML5]]) and the precise data being collected.</p></li>
+<li><p>APIs SHOULD provide support for visual indicator(s) that data is being collected via the APIs.</li></p>
+</ul>
<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 about the trustworthiness of that information?</p>
-<p class="issue">Is it possible to provide an indicator that user
-data 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> <!-- notice -->
<section id="privacy-consent">
<h4>Consent</h4>
-
-<p>Requirements could address: Whether APIs require UAs to obtain user consent before sending 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>
The semantics of some APIs are defined such that user
interaction is essential to make use of the API. An example is
@@ -271,25 +248,27 @@
is an API that produces a message template, but requires the
user to press "send" to actually send the message.
</p><p>
- Such user actions constitute <dfn>implicit consent</dfn>, since the user
- has a choice to perform them and doing so implies consent to
- use the associated Device Capabilities. Such implicit consent
- eliminates the need for a security access dialog for that
- action since it is implicit in the application semantics.
+ Such user actions constitute <dfn>implicit consent</dfn> to collection of data via the API, since the user has a choice to perform these actions and doing so implies consent for the application to access the associated Device Capabilities. In such situations where it is obvious that performing the action involves sharing data with the application and the application’s intended use of the data is also obvious, additional dialogs that prompt users for consent may not be necessary.
</p><p>
- Device APIs may also be defined such that implicit consent is not
- implied. Examples are a camera API that takes a photograph without
- user involvement, or a messaging API that sends a message without the
- user pressing "send". In these cases policy and/or
- user dialogs may be required.
+ Device APIs may also be defined such that consent must be explicit, not implicit. Examples are a camera API that takes a photograph without user involvement, or a messaging API that sends a message without the user pressing "send." In these cases dialogs may be required.
</p>
+ <p>To ensure that data is not collected without users knowing or realizing, APIs should be designed with the presumption that the explicit consent model will be used, and should explain the specific circumstances under which implicit consent may be acceptable. This gives rise to the following requirements:</p>
+
+<ul>
+<li><p>APIs MUST make it possible for user agents to obtain user consent before sharing any data via the APIs. </li></p>
+
+<li><p>APIs MUST be defined in such a way that explicit consent is assumed, and they SHOULD articulate the circumstances under which implicit consent is acceptable. </p></li>
+</ul>
+
+ <p>An important caveat to the consent model supported by Device APIs relates to data about other people that the user may have on his or her device and be able to share via the APIs (other people’s contact or calendar information, for example). A user should not be able to consent through the Device APIs to use of other people’s information beyond the original interaction with the API. Thus, for example, a user should be able to consent to have an application contact another person mentioned in a calendar entry (perhaps to say “I am running late”), but the user should not also be able to consent to have the application make later use of the person’s contact information (perhaps to send marketing messages to that person). This caveat should be conveyed where appropriate in the APIs, best practices, and other Device APIs documents.</p>
+
</section> <!-- consent -->
<section id="privacy-minimization">
<h4>Minimization</h4>
-<p>To reduce the risks of over-exposing users data, it is helpful to
+<p>To reduce the risks of over-exposing users data, it is important 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
@@ -298,11 +277,10 @@
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>
+<p>This gives rise to the following requirements:</p>
<ul>
-<li><p>APIs SHOULD make it easy to request as little information as
+<li><p>APIs MUST 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
@@ -329,22 +307,28 @@
<section id="privacy-control">
<h4>Control</h4>
-<p>Requirements could address: Whether APIs require UAs 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 of data collected; whether APIs require UAs to provide a
-mechanism for users to whitelist trusted applications or blacklist
-untrusted applications</p>
+<p>Given the sensitivity of the data made available through Device APIs, it is important for users to be able to control which applications have access to that data. The following requirements ensure that (1) users have control over their data even after they have shared it with an application, and (2) users have robust controls over which applications can obtain their data to begin with:</p>
+
+<ul>
+ <li><p>
+APIs MUST make it possible for user agents to support the revokation of user consent to sharing of data via the APIs.</p></li>
+<li><p>
+APIs SHOULD support the ability for user agents to allow users to whitelist trusted applications and blacklist untrusted applications.</p></li>
+</ul>
</section> <!-- control -->
<section id="privacy-access">
<h4>Access</h4>
-<p>Requirements could include: Whether APIs require UAs to allow users to view the applications
-with whom they've shared data and at what granularity;
-whether APIs require UAs to allow users to view the history of the user's
-data sharing with each application; whether APIs require UAs to allow
-users to delete history entries or whole histories</p>
+<p>Notice and control cannot be fully implemented unless users can review how they have shared data in the past. The following requirements suggest how APIs can support users’ access to this information:</p>
+
+<ul>
+ <li><p>
+APIs SHOULD make it possible for user agents to allow users to view the applications with whom they have shared data.</p></li>
+<li><p>
+APIs SHOULD make it possible for user agents to allow users to view, edit, and delete the history of the user's data sharing with each.</p></li>
+</ul>
+
</section> <!-- access -->
</section>
@@ -359,6 +343,17 @@
expectations. A license approach similar to Creative Commons may
offer a simple manner to address these requirements.
</p>
+
+<div class="issue"><p>This section does not currently contain any requirements. Because retention, secondary use, and sharing are largely out of the control of the APIs, it's not entirely clear that it makes sense to have any API requirements about these aspects. On the other hand, one can envision a requirement that supports the ruleset model, such as:</p>
+
+<ul><li><p>
+APIs MUST support a mechanism for users to convey their preferences about retention, secondary use, and sharing to applications in the context of an API interaction.</p></li></ul>
+
+Likewise, if we wanted the APIs to support applications' ability to convey their intended policies about these aspects, we could have a requirement like:
+
+<ul><li><p>
+APIs MUST support a mechanism for applications to convey their policies about retention, secondary use, and sharing to users prior to or during API interactions.</p></li></ul>
+
<section id="privacy-retention">
<h4>Retention</h4>
<p>Retention is about to user expectations about how long data they
Received on Saturday, 1 May 2010 17:33:29 UTC