Per the above action, please find below the suggested text for the
privacy considerations section of the policy requirements. I more or
less rolled together what was already in the spec with my email from
last week, http://lists.w3.org/Archives/Public/public-device-apis/2010Mar/0027.html
, with minor clarifying edits. Although I left the mark-up in so it
can more easily be inserted into the doc, I think it's pretty readable.
<h2>Privacy considerations</h2>
<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.
When privacy concerns are not appropriately met, legal remedies in the
courts may be required after the fact. Thus it is important that
privacy is addressed appropriately up-front.</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>
<section>
<h3>Types of Privacy Requirements</h3>
<p>There are four potential types of privacy requirements for device
APIs:</p>
<ul>
<li><p>T1: 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>T2: Requirements for policies to be provided by applications</
p></li>
<li><p>T3: Requirements for policies to be provided by users</p></li>
<li><p>T4: Requirements for what applications can do with the data
they receive</p></li>
</ul>
<p>An example of T1 would be akin to the Geolocation requirement that
user agents must obtain express user permission before sending
location. An example of T2 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 T3 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 T4
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 T2 or T3, 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 T1, T2, and T4, without automated
support for T2 (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>
<h3>Aspects of Privacy</h3>
<p>The sections below enumerate a set of privacy aspect 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>T1: 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>T2: 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>
<section>
<h4>Consent</h4>
<p>T1: 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-over-decisions">User Control over
Decisions</a> for a general discussion about requirements for
obtaining user consent.</p>
</section>
<section>
<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>T1: 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 T1 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>T2: Whether applications can specify their desired amount,
granularity or frequency</p>
<p>T3: Whether users can specify their desired amount, granularity or
frequency to applications</p>
<p>T4: Whether applications must request the minimal data necessary
for their purposes</p>
</section>
<section>
<h4>Control</h4>
<p>T1: 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>
<section>
<h4>Access</h4>
<p>T1: 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>
<section>
<h4>Retention</h4>
<p>T2: Whether applications can specify how long they would like to
retain user data</p>
<p>T3: Whether users can specify how long they would like applications
to retain their data</p>
<p>T4: 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>
<section>
<h4>Identifiability</h4>
<p>T2: Whether applications can specify that they would like to link
the requested data to the user's identity or identifier</p>
<p>T3: Whether users can specify their preference about having
requested data linked to their identities or identifiers</p>
<p>T4: 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>
<section>
<h4>Secondary Use</h4>
<p> T2: Whether applications can specify secondary purposes for which
they would like to use the data (other than the primary purpose)</p>
<p> T3: Whether users can specify their preferences about having their
data used for secondary purposes</p>
<p> T4: Whether applications can use data for secondary purposes</p>
</section>
<section>
<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> T2: Whether applications can specify that they would like to
disclose user data, to whom, at what granularity, and at what
identifiability</p>
<p> T3: Whether users can specify their preferences about having their
data disclosed, to whom, at what granularity, and at what
identifiability</p>
<p> T4: Whether applications can disclose data to third parties, to
whom, at what granularity, and at what identifiability</p>
</section>
<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>
</section>