RE: A comment on Security and Privacy Implications for Contact APIs

Hi Noah,

Thanks for highlighting this point. I agree that we could be more
granular on exactly which parts of a Contact card can be requested and
returned to an application. This could become part of the Security
models/mechanisms/recommendations defined by DAP that could also satisfy
Privacy Considerations based on the proposal included below. 

So how do we do it? :-)

As an introduction, the current Security and Privacy considerations are
based on the assumption of accountability of an application's usage of
your data. A large majority of APIs today (e.g. Google Contacts, Yahoo!
Contacts, Facebook, etc) provide basic permission-based access to your
whole Address Book: read access and/or write access. This principle
currently works on the basis that applications have access to a large
amount of data but they are accountable to both the service provider and
the user. This is useful in the case that any malicious activity takes
place but is not ideal because it doesn't prevent that malicious
activity from taking place in the first place.

In DAP I think we have an opportunity to redress this model to some
extent.

There was a proposal made on the list previously (though I'm having
trouble finding a reference!) that didn't get much discussion but could
perhaps warrants further consideration. The suggestion was that
permissions could be based on the actual data exchange to and from an
application rather than permission being granted on abstract method
access. This is a shift from a "permission to do something with,
potentially, all of your data" (the current model based on
accountability of method usage) to "a permission to do something
specific with a specific set of data" (based on transparency on the
actual data being exchanged with an application).

Without getting too much in to the UX implications, and I'd prefer to
steer clear of expliciting a prompt-based approach at the least, a user
could review and further refine the info being shared before it is
actually passed back to the requesting application. All of this could be
enforced with Privacy mechanisms that interact with the data in the
intermediate moment after it has been retrieved from the device/service
but before it has been returned to the requesting application.

Anyway, I largely agree that there are fundamental differences between
Geolocation and Contacts (and other DAP APIs). The included Security and
Privacy Considerations section was intended to create a starting
platform to enable such discussions - to pick up where the Geolocation
WG left off.

I think securing data access as opposed to securing method access will
at least be an avenue to explore in this group. It could provide
additional privacy up to the point when you have actually shared your
data, after which you're relying on proper usage of that data by the
requesting application according to any terms or privacy mechanisms in
place.

Some of these concepts are abstract but I didn't want to be overly
prescriptive on how we could actually combine Security and Privacy by
securing data resulting from method access as opposed to method access
in the first place.

Perhaps others can run with this concept or there are good reasons why
it is perhaps not ideal. Either way, I'd be interested in more
discussion on the DAP mailing list.

Kind Regards,

Richard


> -----Original Message-----
> From: public-device-apis-request@w3.org 
> [mailto:public-device-apis-request@w3.org] On Behalf Of 
> noah_mendelsohn@us.ibm.com
> Sent: 27 January 2010 15:14
> To: public-device-apis@w3.org
> Cc: www-tag@w3.org
> Subject: 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-a
> nd-privacy-considerations
> 
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

Received on Thursday, 28 January 2010 12:59:48 UTC