Re: Proposed text for privacy requirements

Frederick,

Having been heavily involved in the Geolocation WG privacy discussions  
(and in drafting the privacy text in that spec), I have a few thoughts/ 
suggestions. My colleague John Morris and I hope that this e-mail, and  
the ensuing conversation on the list, can address the outstanding  
action DAP ACTION-77 assigned to John. This is a long email -- my  
apologies.

First, I think it's useful to conceive of four different kinds of  
requirements, any subset of which could be included in the privacy  
requirements document:

(i) requirements for functionality provided strictly by user agents  
(without relation to any policy information provided by a requestor or  
a user)
(ii) requirements for policy information to be provided by requestors
(iii) requirements for policy information to be provided by users
(iv) requirements for what requestors can do with the data they receive

An example of (i) would be akin to the Geolocation requirement that  
user agents must obtain express user permission before sending  
location. An example of (ii) would be a requirement that requestors  
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 displayed to users (one flavor of this was discussed at  
some length in the Geolocation WG [Geolocation], and the idea of sites  
declaring policies was one general thrust behind P3P). An example of  
(iii) 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 the requestors  
(which is a core idea in the IETF's GEOPRIV work [GEOPRIV]). An  
example of (iv) would be akin to the Geolocation requirement that  
requestors must only use the location information for the task for  
which it was provided to them.

I think there are two fundamental questions about how to specify the  
privacy requirements:

1) Will the document support all four types of requirements, and if  
not, which subset will it support?
2) If the document supports requirements of types (ii) or (iii), 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 (i), (ii),  
and (iv), without automated support for (ii) (i.e., there are  
normative requirements for what requestors are supposed to disclose to  
users on their own sites, but as [PrivacyIssuesW3C] points out, most  
sites implementing the API are not complying).

Personally, I think that at the very least, supporting types (i),  
(ii), and (iii) -- with hooks for automating policy exchanges -- is  
the best approach, but for now I just wanted to lay out that framework  
for thinking about it.

The second issue is which privacy aspects the requirements will cover.  
You pulled the set from [PrivacyIssuesW3C] and I think that's a useful  
set to start from. But we should be aware that the set of concepts  
from [PrivacyIssuesW3C] are largely based on the Fair Information  
Practices (known as the "FIPs"), which are a widely accepted set of  
principles that can be used to explain a more or less complete set of  
privacy protections. There are many different articulations of the  
FIPs ([OECD] and [DHS] provide two examples), but they all essentially  
boil down to the same set of core concepts. The [PrivacyIssuesW3C] set  
is somewhat more granular than most statements of the FIPs usually  
are, but otherwise they cover the same territory.

In the list below I've taken a version of the [PrivacyIssuesW3C] set  
of concepts (slightly modified to be a little closer to most FIPs  
descriptions) and attempted to do a somewhat exhaustive list of the  
kinds of things that could be specified by each type of requirement (i- 
iv) for each concept. The point of this is not that the entire list  
would be covered by the privacy requirements document, but I think it  
makes sense to start with the universe of possibilities and whittle it  
down to those that make the should apply for DAP. I think I've covered  
most everything suggested by both you and Dom (plus lots more). The  
next step could be to go through these, see which ones are most  
compelling, and start articulating them as actual requirements.

Notice
(i) whether the UA needs to notify users before their data is sent to  
a requestor; how that notification happens; what that notice should  
contain; whether the UA needs to notify users as their data is sent to  
requestors (see, e.g., the discussion that started at [Geolocation2])
(ii) whether requestors 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

Consent
(i) whether the UA needs to obtain consent of users to send their data  
to requestors; how robust that consent needs to be (i.e., "express,"  
"affirmative," "implied," or something else); how that consent is  
obtained; whether that consent should be remembered by the UA

Minimization
(i) whether the UA needs to allow users to change or limit the  
granularity and/or frequency of data sent to requestors
(ii) whether requestors can specify their desired granularity or  
frequency
(iii) whether users can specify their desired granularity or frequency  
to requestors
(iv) whether requestors must request the minimal data necessary for  
their purposes

Control
(i) 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 requestors or blacklist  
untrusted requestors

Access
(i) whether the UA needs to allow users to view the requestors 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 requestor; whether the UA needs to allow users  
to delete history entries or whole histories

Retention
(ii) whether requestors can specify how long they would like to retain  
user data
(iii) whether users can specify how long they would like requestors to  
retain their data
(iv) whether requestors must dispose of collected data after  
fulfilling the purpose for which it was collected; whether requestors  
are bound by some default retention period

Identifiability
(ii) whether requestors can specify that they would like to link the  
requested data to the user's identity or identifier
(iii) whether users can specify their preference about having  
requested data linked to their identities or identifiers
(iv) whether requestors 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

Secondary Use
(ii) whether requestors can specify secondary purposes for which they  
would like to use the data (other than the primary purpose)
(iii) whether users can specify their preferences about having their  
data used for secondary purposes
(iv) whether requestors can use data for secondary purposes

Disclosure
(ii) whether requestors can specify that they would like to disclose  
user data, to whom, at what granularity, and at what identifiability
(iii) whether users can specify their preferences about having their  
data disclosed, to whom, at what granularity, and at what  
identifiability
(iv) whether requestors can disclose data to third parties, to whom,  
at what granularity, and at what identifiability


Alissa

[Geolocation] http://lists.w3.org/Archives/Public/public-geolocation/2009Mar/0131.html
[Geolocation2] http://lists.w3.org/Archives/Public/public-geolocation/2009May/0031.html
[GEOPRIV] http://tools.ietf.org/html/draft-ietf-geopriv-arch-01
[PrivacyIssuesW3C] http://escholarship.org/uc/item/Orp834wf
[OECD] http://www.oecd.org/document/18/0,3343,en_2649_34255_1815186_1_1_1_1,00.html
[DHS] http://www.dhs.gov/xlibrary/assets/privacy/privacy_policyguide_2008-01.pdf

On Feb 28, 2010, at 4:03 PM, Frederick Hirsch wrote:

> I'd like to propose the following draft text for the Privacy portion  
> of the  "Device API Security,Privacy and Policy Requirements"  
> document [1].  (We can merge this rough draft with the text that Dom  
> provides.) I will probably have more to offer later.
>
> Privacy Requirements
>
> 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.
>
> The following aspects of privacy should be addressed with more  
> detailed requirements [PrivacyIssuesGeolocation]:
>
> Appropriateness - is the information collected appropriate to the  
> context
>
> Minimization - is the minimum necessary granularity collected
>
> User Control - Does the user have control over the sharing of  
> information, active or passive? Are there defaults?
>
> Notice - What information is provided to the user by the entity  
> requesting information regarding that request? Can a user attach  
> rules regarding use to the information provided?
>
> Consent - Is the user in control of decisions to disclose  
> information? How is this control manifested, per use, per recipient,  
> etc.
> What is the model, opt-in, opt-out?
>
> Secondary Use - Is consent required for secondary use?  Are there  
> mechanisms for setting limits or asking permission?
>
> Distribution - Can the entity requesting the information  
> redistribute it?
>
> Retention - Can policy statements about retention be made? Is the  
> information provided with a timestamp to enable retention limits?
>
> Transparency and Feedback - Are flows of information transparent to  
> the user? Can the user access log information?
>
> Aggregation - Can information be aggregated, are persistent unique  
> identifiers used?
>
> 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 system information  
> disclosures might less so.
>
> [PrivacyIssuesGeolocation] Doty, N. Mulligan, D. Wilde, E. "Privacy  
> Issues of the W3C Geolocation API". UC Berkeley School of  
> Information. 24 February 2010. URI: http://escholarship.org/uc/item/Orp834wf
>
> ---
>
> (It might be worth considering if a light weight version of P3P or  
> Geopriv is appropriate and can be generalized for DAP in the context  
> of extension points as discussed by Noah.)
>
> regards, Frederick
>
> Frederick Hirsch
> Nokia
>
> [1] http://dev.w3.org/2009/dap/policy-reqs/
>
>
>

Received on Tuesday, 2 March 2010 22:12:59 UTC