- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 07 Apr 2010 12:29:09 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-reqs
In directory hutz:/tmp/cvs-serv16180
Modified Files:
Overview.html
Log Message:
revision posted by Alissa, http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0010.html for ACTION-153 and ACTION-112
Index: Overview.html
===================================================================
RCS file: /sources/public/2009/dap/privacy-reqs/Overview.html,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -d -r1.8 -r1.9
--- Overview.html 24 Mar 2010 13:55:25 -0000 1.8
+++ Overview.html 7 Apr 2010 12:29:07 -0000 1.9
@@ -20,6 +20,7 @@
};
</script>
<script src='../common/configPolicy.js' class='remove'></script>
+
</head>
<body>
<section id='abstract'>
@@ -38,99 +39,147 @@
</section>
<section id='introduction'>
<h2>Introduction</h2>
- <p>
- The privacy requirements described in this document are intended
- to be applicable to device APIs both in the context of widgets and web applications.
+ <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
+ 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
+ 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>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>
+ </ul>
+ </p>
+
+ <p>These elements will each need to be approached in different ways. Approaches include specific requirements
+ on individual APIs, conveying user expectations together with
+ the data itself, and/or documenting best practices for application
+ and content developers. Certain approaches are better suited to safeguarding certain privacy elements than others.</p>
+ <p>This document provides specific requirements for individual APIs, addressing the elements that are most relevant to API definitions: notice, consent, minimization, control, and access. Requirements involving user expectations, which primarily address retention, secondary use, and sharing, will be documented separately. Best practices for developers will also be documented separately, covering notice, minimization, control, access, retention, secondary use, and sharing in the application developer context. </p>
+
+ <p>The following table summarizes the breakdown of how each element is covered:</p>
+
+ <table class="simple">
+ <tr>
+ <th>Privacy Element</th>
+ <th>Requirements for API Definitions</th>
+ <th>Requirements for user expectations conveyed with data</th>
+ <th>Best practices for developers</th>
+ </tr>
+ <tr>
+ <td><a href="#privacy-notice">Notice</a></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ </tr>
+ <tr>
+ <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>
+ </tr>
+ <tr>
+ <td><a href="#privacy-minimization">Minimization</a></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ </tr>
+ <tr>
+ <td><a href="#privacy-control">Control</a></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ </tr>
+ <tr>
+ <td><a href="#privacy-access">Access</a></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ </tr>
+ <tr>
+ <td><a href="#privacy-retention">Retention</a></td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center">X</td>
+ </tr>
+ <tr>
+ <td><a href="#privacy-secondary-use">Secondary Use</a></td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center">X</td>
+ </tr>
+ <tr>
+ <td><a href="#privacy-sharing">Sharing</a></td>
+ <td style="text-align:center"></td>
+ <td style="text-align:center">X</td>
+ <td style="text-align:center">X</td>
+ </tr>
+ </table>
+
+
+<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>
+
+ <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
+ 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>
+
+<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-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); for instance, the Geolocation requirement that
-user agents must obtain express user permission before sending
-location</p></li>
-<li><p><code>App-Policy</code>: Requirements for policies to be provided by applications; for instance, 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</p></li>
-<li><p><code>User-Policy</code>: Requirements for policies to be provided by users; for instance, 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</p></li>
-<li><p><code>App-Data-Use</code>: Requirements for what applications can do with the data
-they receive; for instance, the Geolocation requirement that applications must
-only use the location information for the task for which it was
-provided to them</p></li>
-</ul>
+<section id="privacy-requirements">
+<h3>Privacy Requirements for APIs</h3>
-<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>
+<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>
-<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>
+<section id="privacy-notice">
<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
+<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 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>
+misleading the user about the trustworthiness 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
+<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>
+<section id="privacy-consent">
<h4>Consent</h4>
-<p><code>UA-Functionality</code>: Whether the UA needs to obtain consent of users to send their
+<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
@@ -156,6 +205,7 @@
user pressing "send". In these cases policy and/or
user dialogs may be required.
</p>
+
</section> <!-- consent -->
<section id="privacy-minimization">
@@ -165,9 +215,8 @@
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>
+<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>
<ul>
<li><p>APIs SHOULD make it easy to request as little information as
@@ -185,30 +234,21 @@
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>
+select, filter, and transform 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>
+<section id="privacy-control">
<h4>Control</h4>
-<p><code>UA-Functionality</code>: Whether the UA needs to provide a mechanism for consent to be
+<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 and frequency; whether the UA needs to provide a
+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>
</section> <!-- control -->
@@ -216,278 +256,22 @@
<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
+<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>
</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="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>
-<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>Privacy Requirements</h2>
- <section id='privacy-rqmts'>
-<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></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>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
+
</p>
</section>
</body>
</html>
+
Received on Wednesday, 7 April 2010 12:29:10 UTC