- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 18 Mar 2010 12:41:34 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/policy-reqs
In directory hutz:/tmp/cvs-serv26604
Modified Files:
Overview.html
Log Message:
remove material that is now in privacy draft
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/policy-reqs/Overview.html,v
retrieving revision 1.31
retrieving revision 1.32
diff -u -d -r1.31 -r1.32
--- Overview.html 18 Mar 2010 10:41:51 -0000 1.31
+++ Overview.html 18 Mar 2010 12:41:32 -0000 1.32
@@ -1,7 +1,7 @@
<!DOCTYPE html>
<html>
<head>
- <title>Device API Security, Privacy and Policy Requirements</title>
+ <title>Device API Policy Requirements</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src='../ReSpec.js/js/respec.js' class='remove'></script>
<script class='remove'>
@@ -18,7 +18,7 @@
</head>
<body>
<section id='abstract'>
- This document includes common use cases and security, privacy
+ This document includes use cases
and policy requirements for device APIs.
</section> <!-- abstract -->
@@ -130,256 +130,6 @@
taking a photograph.</p></dd>
</dl>
</section> <!-- definitions -->
- <section id='targets'>
- <h2>Conformance Targets</h2>
-<p>There are two conformance targets referred to in this document:</p>
-<ul>
-<li><p><code>User Agent</code></li>
-<li><p><code>Application/Content</code></li>
-</ul>
-</section>
-<section id="privacy-categorization">
-<h3>Privacy Requirement Categorization</h3>
-<ul>
-<li><p><code>UA-Functionality</code>: 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><code>App-Policy</code>: Requirements for policies to be provided by applications</p></li>
-<li><p><code>User-Policy</code>: Requirements for policies to be provided by users</p></li>
-<li><p><code>App-Data-Use</code>: Requirements for what applications can do with the data
-they receive</p></li>
-</ul>
-
-<p>An example of <code>UA-Functionality</code> would be akin to the Geolocation requirement that
-user agents must obtain express user permission before sending
-location. An example of <code>App-Policy</code> 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 <code>User-Policy</code> 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 <code>App-Data-Use</code>
-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 <code>App-Policy</code> or <code>User-Policy</code>, 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 <code>UA-Functionality</code>, <code>App-Policy</code>, and <code>App-Data-Use</code>, without automated
-support for <code>App-Policy</code> (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 id='privacy-areas'>
-<h3>Privacy Areas</h3>
-<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
-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
-the technical standards, laws and regulations, and best practices.</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
-have fewer issues.
-</p>
-<p>The sections below enumerate a set of privacy areas 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><code>UA-Functionality</code>: 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><code>App-Policy</code>: 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> <!-- notice -->
-
-<section>
-<h4>Consent</h4>
-
-<p><code>UA-Functionality</code>: 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-principle">User Control over
-Decisions</a> for a general discussion about requirements for
-obtaining user consent.</p>
-</section> <!-- consent -->
-
-<section id="privacy-minimization">
-<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><code>UA-Functionality</code>: 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 <code>UA-Functionality</code> 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
-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>
-
-<p><code>App-Policy</code>: Whether applications can specify their desired amount,
-granularity or frequency</p>
-
-<p><code>User-Policy</code>: Whether users can specify their desired amount, granularity or
-frequency to applications</p>
-
-<p><code>App-Data-Use</code>: Whether applications must request the minimal data necessary
-for their purposes</p>
-</section> <!-- minimization -->
-
-<section>
-<h4>Control</h4>
-
-<p><code>UA-Functionality</code>: 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> <!-- control -->
-
-<section id="privacy-access">
-<h4>Access</h4>
-
-<p><code>UA-Functionality</code>: 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> <!-- access -->
-
-<section id="privacy-retention">
-<h4>Retention</h4>
-
-<p><code>App-Policy</code>: Whether applications can specify how long they would like to
-retain user data</p>
-
-<p><code>User-Policy</code>: Whether users can specify how long they would like applications
-to retain their data</p>
-
-<p><code>App-Data-Use</code>: 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> <!-- retention -->
-
-<section id="privacy-identifiability">>
-<h4>Identifiability</h4>
-
-<p><code>App-Policy</code>: Whether applications can specify that they would like to link
-the requested data to the user's identity or identifier</p>
-
-<p><code>User-Policy</code>: Whether users can specify their preference about having
-requested data linked to their identities or identifiers</p>
-
-<p><code>App-Data-Use</code>: 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> <!-- identifiability -->
-
-<section id="privacy-secondary-use">
-<h4>Secondary Use</h4>
-
-<p> <code>App-Policy</code>: Whether applications can specify secondary purposes for which
-they would like to use the data (other than the primary purpose)</p>
-
-<p> <code>User-Policy</code>: Whether users can specify their preferences about having their
-data used for secondary purposes</p>
-
-<p> <code>App-Data-Use</code>: Whether applications can use data for secondary purposes</p>
-</section> <!-- secondary use -->
-
-<section id="privacy-disclosure">
-<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> <code>App-Policy</code>: Whether applications can specify that they would like to
-disclose user data, to whom, at what granularity, and at what
-identifiability</p>
-
-<p> <code>User-Policy</code>: Whether users can specify their preferences about having their
-data disclosed, to whom, at what granularity, and at what
-identifiability</p>
-
-<p> <code>App-Data-Use</code>: Whether applications can disclose data to third parties, to
-whom, at what granularity, and at what identifiability</p>
-</section> <!-- disclosure -->
-
-<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 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>
-</ul>
-
-</div>
-</section> <!-- privacy aspects -->
<section id="principles">
<h2>Principles</h2>
@@ -400,26 +150,6 @@
less inclined to take any security decision seriously, which further
undermines the effectiveness of a user-driven access control system.
</p><p>
- The semantics of some APIs are defined such that user
- interaction is essential to make use of the API. An example is
- a camera API that enables the user to take a photograph, but
- is defined to require the user to press a shutter key to take
- the photograph. Another example
- 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 implicit consent, 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.
- </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.
- </p><p>
It is important to note that modal prompts (i.e. prompts
that block all other user
interaction until
@@ -509,149 +239,6 @@
</section> <!-- user control -->
</section>
-<section id="privacy-use-cases">
-<h2>Privacy Use Cases</h2>
-<p>
-This section outlines privacy use cases.
-Notice, consent, and control are not
-included since they are not aspects about which
-applications or users will want/need to convey policies, but rather
-they are the required mechanisms for users to learn about policies and
-make decisions based on those policies. The aspects below could be
-conveyed by the application to provide notice to the user, and/or the
-aspects could be conveyed by the user to the app to impose limits on
-the app. The most privacy protective approach would allow policy
-conveyance in both directions.
-</p>
-<section>
-<h2>Minimization Privacy Use Case</h2>
-<p>Policies describe the desired amount, granularity, and
-frequency of data to be accessed (with the goal that the minimum
-amount of data needed for the primary service should be conveyed).
-</p>
-<section>
-<h3>Social Networking Example</h3>
-<dl>
-<dt>Application</dt>
-<dd>Uses the Contacts API to find address book contacts who are
-also members of a social network. Email addresses serve as the social
-network handles.</dd>
-<dt>Policy</dt>
-<dd> Only email addresses will be accessed (not any other
-contact fields). There is no reason the social network in this
-hypothetical should be able to get the home address or birthdates of
-entries in the contact list.</dd>
-</dl>
-</section>
-</section>
-<section>
-<h2>Access Privacy Use Case</h2>
-<p>Policies describe whether users will be able to access the
-data they share via APIs and in what form it will be accessible. (This
-is important because data on the device and data held by the app may
-not be in sync, so that when data is deleted from the device it is not
-necessarily deleted by the app.)
-</p>
-<section>
-<h3>Example: Messaging</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Messaging API to allow users to create and send
-messages.</dd>
-<dt>Policy</dt>
-<dd>Provides users with the ability to see and delete all sent
-messages from the app server.</dd>
-</dl>
-</section>
-</section>
-<section>
-<h2>Retention Privacy Use Case</h2>
-<p>Policies describe how long user data is retained.
-</p>
-<section>
-<h3>Example: Webcam service</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Capture API for a webcam service.
-</dd>
-<dt>Policy</dt>
-<dd>Video data is not retained.</dd>
-</dl>
-</section>
-<section>
-<h3>Example: Voice search</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Capture API for a voice search service.
-</dd>
-<dt>Policy</dt>
-<dd>Voice searches are retained for 90 days for use (for
-example) in optimizing search results.</dd>
-</dl>
-</section>
-</section>
-<section>
-<h2>Secondary Use Privacy Use Case</h2>
-<p>Policies describe uses of user data beyond the service
-requested by the user that caused the API call. Secondary uses might
-be immediate or time-shifted -- and there are different levels of
-privacy concern for immediate vs. delayed secondary uses.</p>
-<section>
-<h3>Example: Event reminders</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Calendar API to allow users to set reminders for
-upcoming events, and serves contextual ads when users set reminders
-about upcoming travels. (The contextual ad would be an "immediate"
-secondary use.)
-</dd>
-<dt>Policy</dt>
-<dd>Reminder information is used to target contextual ads.</dd>
-</dl>
-</section>
-<section>
-<h3>Example: Event reminders with ads</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Calendar API to allow users to set reminders for
-upcoming events, and serves ads based on the content of all of the
-user's reminders whenever he/she accesses his/her calendar.
-</dd>
-<dt>Policy</dt>
-<dd>Reminder information is used to create a profile for ad
-targeting purposes. (The ad targeting profile would be a time-shifted
-or delayed secondary use.)</dd>
-</dl>
-</section>
-</section>
-
-<section>
-<h2>Disclosure Privacy Use Case</h2>
-<p>Policies describe whether, to whom, and in what form user
-data is disclosed to third parties.
-</p>
-<section>
-<h3>Example: Integrate address book contacts with social network</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Contacts API to upload address book contacts to a
-social network.
-</dd>
-<dt>Policy</dt>
-<dd>Discloses names and email addresses from the address book
-to the social networking service, but not to any other third party.</dd>
-</dl>
-</section>
-<section>
-<h3>Example: Integrate address book contacts with social network and
- Third Party credit checking service</h3>
-<dl><dt>Application</dt>
-<dd>Uses the Contacts API to upload address book contacts to a
-social network, and shares them with a third-party service that
-performs credit checks based on social network data (see, e.g.,
- http://www.cdt.org/blogs/erica-newland/keeping-friends-close-and-friends-good-credit-scores-closer).
-</dd>
-<dt>Policy</dt>
-<dd>Discloses all contact information from the address book to
-the social networking service and the credit check service.</dd>
-</dl>
-</section>
-</section>
-</section>
<section>
<h2>Policy Use Cases</h2>
<p>
@@ -921,41 +508,6 @@
decisions using the policy markup language format.</li>
</ul>
</section> <!-- user control rqmts -->
- <section id='privacy-rqmts'>
- <h3>Privacy Requirements</h3>
-<p>Privacy concerns will need to be addressed in different ways,
- depending on the <a href='#privacy-areas'>privacy area</a>. Approaches include specific requirements
- on individual APIs, conveying user-expectations with
- data itself and/or documenting best practices for application
- and content developers.</p>
-<p> <a href="#privacy-minimization">Minimization</a> is closely related to API methods and what they
- return, so addressed in specific API definitions. <a href="#privacy-access">Access</a> to
- the history of which application (web content) obtained specific
- data may also be defined
- either for all APIs or individually.</p>
-<p> Requirements involving user expectations on specific data items,
- such as areas of data
- retention, secondary use and dislosure may require user parameters
- to be conveyed
- with data. (possible DAP v2 item). Finally, items that impact
- practices by application/content developers are out of the scope of
- API definition, but may benefit from Best Practice definitions.
-</p>
-<p>The following table summarizes this approach:</p>
-<table class='simple'>
- <tr><th>Address in specific API Definitions</th><th>Address by
- conveying additional information with Data</th><th>Address by
- describing Best Practices</th></tr>
- <tr><td><a href="#privacy-minimization">Minimization</a></td><td></td><td></td></tr>
- <tr><td><a href="#privacy-access">Access to usage
- history</a></td><td></td><td><a href="#privacy-access">Access</a></td></tr>
- <tr><td><a href="#privacy-minimization">Minimization</a></td><td><a href="#privacy-retention">Retention</a></td><td><a href="#privacy-retention">Retention</a></td></tr>
- <tr><td></td><td><a
-href="#privacy-secondary-use">Secondary Use</a></td><td><a
-href="#privacy-secondary-use">Secondary Use</a></td></tr>
- <tr><td></td><td><a href="#privacy-disclosure">Disclosure</a></td><td><a href="#privacy-disclosure">Disclosure</a></td></tr>
-</table>
- </section>
<section>
<h2>Security Framework Requirements</h2>
<ul>
Received on Thursday, 18 March 2010 12:41:37 UTC