ACTION-100: Share information on key important privacy policy aspects relevant to DAP

I took an action to highlight some of the key privacy aspects that DAP  
applications and users might want to convey. I've included a list of  
aspects below and some examples of the kinds of policies that might  
exist for each aspect for the different APIs. These are just examples  
-- there are obviously a multitude of potential apps that could use  
DAP, and for each app there are a multitude of policy choices. The  
privacy aspects roughly correlate to the list of aspects currently  
listed in the policy requirements doc [1].

There are, of course, the threshold questions of notice, consent and  
control.  Most of this e-mail is focused on policies that might be  
conveyed in a DAP interaction.  Notice, consent, and control are not  
included in the list below because 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.

Before setting out to do this e-mail, I had expected that there might  
be significantly different privacy concerns for each of the different  
DAP API efforts, but at the end of the day, most of the APIs will  
implicate most of the main privacy concerns.  There will be some  
differences and different weights -- certainly, for example, data  
minimization will be very important for calendar and contact  
applications, while it is less clear how minimization applies in the  
camera context.  But for the most part, each of the following concerns  
apply to each of the APIs:

Minimization: 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).
Example:
-- App: 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.
-- Policy: 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.

Retention: policies describe how long user data is retained.
Example 1:
-- App: Uses the Capture API for a webcam service.
-- Policy: Video data is not retained.
Example 2:
-- App: Uses the Capture API for a voice search service.
-- Policy: Voice searches are retained for 90 days for use (for  
example) in optimizing search results.

Secondary use: 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.
Example 1:
-- App: 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.)
-- Policy: Reminder information is used to target contextual ads.
Example 2:
-- App: 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.
-- Policy: 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.)

Disclosure: policies describe whether, to whom, and in what form user  
data is disclosed to third parties.
Example 1:
-- App: Uses the Contacts API to upload address book contacts to a  
social network.
-- Policy: Discloses names and email addresses from the address book  
to the social networking service, but not to any other third party.
Example 2:
-- App: 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) 
.
-- Policy: Discloses all contact information from the address book to  
the social networking service and the credit check service.

Access: 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.)
-- App: Uses the Messaging API to allow users to create and send  
messages.
-- Policy: Provides users with the ability to see and delete all sent  
messages from the app server.

These are the key privacy aspects, and as noted they implicate most of  
the APIs.

I unfortunately will not be at the F2F, but my colleague Alissa Cooper  
will be there for the first day, and I will try to call in to the  
bridge for the privacy discussions.

John Morris

[1] http://dev.w3.org/2009/dap/policy-reqs/#aspects-of-privacy

Received on Saturday, 13 March 2010 04:38:24 UTC