- From: <richard.tibbett@orange-ftgroup.com>
- Date: Thu, 28 Jan 2010 13:58:15 +0100
- To: <noah_mendelsohn@us.ibm.com>, <public-device-apis@w3.org>
- Cc: <www-tag@w3.org>
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