- From: Frederick Hirsch via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 17 Mar 2010 15:02:21 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/privacy-reqs
In directory hutz:/tmp/cvs-serv22088
Added Files:
Overview.html
Log Message:
initial privacy requirements draft, material from policy-reqs
--- NEW FILE: Overview.html ---
<!DOCTYPE html>
<html>
<head>
<title>Device API Privacy 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'>
var respecConfig = {
specStatus: "ED",
shortName: "dap-privacy-reqs",
// publishDate: "2009-10-23",
// previousPublishDate: "1977-03-15",
edDraftURI: "http://dev.w3.org/2009/dap/privacy-reqs/",
// lcEnd: "2009-08-05",
};
</script>
<script src='../common/configPolicy.js' class='remove'></script>
</head>
<body>
<section id='abstract'>
This document provides definitions, use cases, and requirements
for device APIs.
</section> <!-- abstract -->
<section id='introduction'>
<h2>Introduction</h2>
<p>
This document is an editors draft and currently does not
reflect consensus of the WG but rather is a starting point for
further work. It is based on input documents and list
discussion.
</p>
<p>
The security framework described in this document is intended
to be applicable both to widgets and web applications (web
site access to Device APIs).
</p>
</section> <!-- introduction -->
<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="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>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 border='1'>
<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>
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
</p>
</section>
</body>
</html>
Received on Wednesday, 17 March 2010 15:02:24 UTC