A comment on Security and Privacy Implications for Contact APIs

Congratulations on the publication of the publication of working draft 
"The Contacts API" [1].  I would like to comment on the Security and 
Privacy considerations section [2], which states:

-----------
This section is under development.

This section has been inspired (verbatim where necessary) from the 
Geolocation WG latest public working draft specification.

There are a number of reasons for this approach:

1. The programmatic styles of the Contacts API and Geolocation API are 
very similar and because they both have the the same implied user 
experience within the same implied User Agent the general security and 
privacy considerations of both APIs should remain common.

2. The ability to align the security and privacy considerations of the 
Geolocation API with DAP APIs is important for the potential future 
benefit of making any security and privacy mechanisms developed within the 
DAP WG applicable to the Geolocation API at some point in its own ongoing 
development.
-----------

It seems to me that, in fact, the use cases and this the user experiences 
are potentially quite different for Contacts vs. Geolocation. 
Specifically, the information exposed through a geolocation API is 
potentially important and sensitive, but the nature of it is generally 
clear to a user:  you're giving permission to give out my latitude, 
longitude, and perhaps altitude.  A contacts database is potentially very 
large, and depending on the device may have quite a wide range of 
information for each contact.  This can include (multiple) phone numbers, 
email addresses, home addresses, employers, office address,  office or 
home latitude and longitude, Facebook ids, geolocations, IM screen names, 
etc., etc.  Furthermore, some contact lists will contain a handful of such 
entries, and others will contain thousands. 

For the above reasons, it seems to me that an appropriate mechanism for 
the contacts API will likely involve an ability not just to ask for 
permission, but to clarify the subset of the contacts for which access is 
being granted.  It may also be necessary to separate access for purposes 
of searching vs. access for purposes of display, transmission or 
republication.  For example, I can imagine a mobile instant messaging 
application wanting to do the following:

1) get permission to search my entire contact lists for everyone with a 
compatible screen name
2) get permission to retrieve and display for my selection certain, but 
perhaps not all of the information for such users (e.g. I might want it to 
get at the user's name as text, screen name, and perhaps a few other bits, 
but I might not want to grant it permission to retrieve the users home 
mailing address)
3) when the user selects one such name, grant it permission to send 
certain information out to the IM network

(Maybe or maybe not that third step needs to be separate.)  I'm not trying 
to design the UI or say that it necessarily has to be multi-step.  It 
could be a single step in which the user is given a prompt saying:

"Do you give the SuperIM Web application permission to search your entire 
contact list for users with screen names, to retrieve for each such user 
his/her given name, screen name and email address, and for users you 
choose to chat with, permission to send that information to the chat 
network?"

"Should I ask you again if you make similar requests in the future?"

etc.

BTW:  I am writing as an individual and as a member of the TAG, but in 
this note I do not speak for the TAG as a whole.

Noah

[1] http://www.w3.org/TR/2010/WD-contacts-api-20100121/
[2] 
http://www.w3.org/TR/2010/WD-contacts-api-20100121/#security-and-privacy-considerations

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Wednesday, 27 January 2010 15:14:55 UTC