W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

RE: Contacts API typical use cases and privacy considerations

From: <richard.tibbett@orange-ftgroup.com>
Date: Fri, 19 Feb 2010 16:41:04 +0100
Message-ID: <30343_1266594066_4B7EB112_30343_20599_1_355A518BC0575547B2A3D6773AAF8EEF94FEE6@ftrdmel1>
To: <dom@w3.org>, <public-device-apis@w3.org>
FWIW, it's worth reading the full thread of [1] to see how deep the
rabbit hole goes with an <input .../> approach...

However, *something* like [1] is the proposal and the details are less
important than the principal of this discussion.

On Fri, Feb 19, 2010 at 15:34, richard.tibbett@orange-ftgroup.com wrote:
> Thanks Dom. We're on the same page here and I'm keen to 
> progress this discussion...
> 
> On Fri, Feb 19, 2010 at 09:59, Dominique Hazael-Massieux <dom@w3.org>
> wrote:
> > I came up with the following main use cases (which obviously are a 
> > personal perspective, and very much up for discussion):
> > * auto-filling a form with my personal address and/or phone number 
> > (for getting sent an item I just bought, making an hotel 
> reservation, 
> > using an eGov service) * auto-filling a form with one 
> postal address 
> > from someone I know (to send them a gift) * getting 
> auto-completion on 
> > an email address of someone in my addressbook (for on-line email, 
> > sending invitation to on-line services, sharing content 
> from a given 
> > Web site) [this would obviously also apply to other fields, 
> e.g. phone 
> > number, social network account, etc] * sharing an arbitrary 
> number of 
> > email addresses with an on-line social network to expand my network
> > 
> > It's not obvious that the current Contacts.find() interface 
> allows to 
> > implement these simple use cases without opening a much wider than 
> > needed access to the addressbook data.
> > 
> > In particular:
> > * for the two first use cases, the user would want to select one or 
> > two pieces of information (address, phone number) from one entry in 
> > its addressbook; a Web developer would want to provide a small icon 
> > (similar to the calendar icon you get on many sites to pick a date) 
> > which would let the user pick the said contact, and would 
> get back to 
> > the page only the selected address; I don't know how this can be 
> > achieved using the current Contacts.find() without exposing 
> the whole 
> > list of names and addresses * similarly, the 
> auto-completion use case 
> > requires to call repeatedly the Contact.find() method with a very 
> > broad access to the data
> > 
> > Both of these operations would seem to benefit from being 
> brokered by 
> > the browser to preserve as much of the privacy of the user as 
> > possible.
> > 
> > (I think Contacts.find() remains pretty useful for 
> applications that 
> > want to build on top of the addressbook, in possibly 
> innovative ways 
> > compared to what we can do today; but I think we should 
> also address 
> > the problems that already exist today)
> > 
> 
> We have a proposal to implement an <input type="file"> 
> extension for Contacts [1] and I think we should move forward 
> with this. There was little objection to the principal in 
> that thread, only how it should actually be done technically. 
> If you have objections please do reply to that thread. There 
> is also a <device> placeholder in the HTML5 spec [2] and I 
> think either tag could be suitable for the use cases you are 
> suggesting.
> 
> The second question is whether this <input type="file"> 
> 'extension' AND programmatic Contacts.find() access should 
> co-exist in the spec.
> Initially I thought this was a compromise, but actually there 
> are use cases for both models. So should they co-exist? 
> 
> On the other hand, having only an <input type="file" ...> like 'read'
> approach and a programmatic non-modal 'write' approach could 
> work well IMO. i.e. Use a file picker to select the Contacts 
> to work with, resulting in 'ContactFile' object(s) [1] and 
> use the non-modal notification method to write any object 
> changes back to the device.
> 
> Finally, if a webapp must request specific ContactProperties 
> then we need to build this in to our chosen 'read' approach:
> 
> E.g. (something like...)
> 
> navigator.service.contacts.find({}, successCB, errorCB, {fields:
> ['name','addresses']})
> 
> AND/OR
> 
> <input type='file' accept='pim/contact' fields='name,addresses'/>
> 
> In both examples above, the broker (i.e. the browser) is the 
> enforcement point for ensuring these requests are respected, 
> handling the UI for the user, and returning ContactFile 
> objects back to the webapp.
> 
> Thoughts on this assessment of the current discussion are welcome.
> Feedback is vital as I think we all want to see the Security 
> and Privacy debate moving forward.
> 
> Oh, and a final point is that this is only intended to cover 
> the Contacts API initially. Other APIs should probably be 
> assessed on a case-by-case basis...
> 
> Kind Regards,
> 
> Richard
> 
> 
> 
> [1]
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec
> /0005.html
> 
> [2]
> http://lists.w3.org/Archives/Public/public-device-apis/2009Dec
> /0217.html
> 
> *********************************
> 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.
> ********************************
> 
> 
> 

*********************************
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 Friday, 19 February 2010 15:41:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC