ACTION-98: Provide draft text for requirements document summarizing 4 privacy aspects...

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>

Received on Tuesday, 9 March 2010 18:12:04 UTC