RE: Contacts API typical use cases and privacy considerations

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.
********************************

Received on Friday, 19 February 2010 15:34:20 UTC