Re: Contacts API typical use cases and privacy considerations

Hi,

some ideas after thinking about this thread.

On Feb 19, 2010, at 10:59 , Dominique Hazael-Massieux 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

A lot of these cases can be more or less handled by the browsers already with the autocomplete attribute. Of course that's not very useful in that it is strongly tied to the browser's own capabilities (and it will likely only know about your own local address book). Also, it only (normally) completes a single field at a time.

Just going a little bit crazy with markup, could the following be made to work?

<fieldset autocomplete='org.w3c.contacts' name='myAddress'>
  <input type='text' name='.name'/> <!-- the "." points to current autocomplete scope  -->
  <input type='text' name='.phone'/>
  <textarea name='.address'></textarea>
</fieldset>

This makes autocomplete the entry point to select a completion source that may be multi-valued. Another potential extension entry point here could be the @list/<datalist> combo.

I still have a preference for the Powerbox-based approach I noodled on in http://dev.w3.org/2009/dap/docs/powerbox-walkthrough.html nevertheless. One advantage is that it gives the service provider and the user control over the level of granularity for data sharing that they wish to have. It's also less deeply integrated into the browser.

> (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)

I tend to agree. I think that this might point to multiple levels of APIs, starting with one that handles the basics and then extending up. If we stick to traditional APIs I'm increasingly guessing that File API and friends can be the model here. And of course Powerbox offers similar flexibility.


On Feb 19, 2010, at 17:56 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com> wrote:
> Calling a JS method that throws up a contacts picker has the implication of producing a blocking JS dialog.

Not necessarily, it can perfectly well be asynchronous. The file picker that file input controls throw up don't block execution (even though they're often modal which indeed you might not want here).

One of the problems in having JS bring up a contacts picker in a non-trusted environment is that you can usually predict where it's going to appear for different browsers, which means that you can trick users into clicking. The typical trick here is "Hey this is a cool game! Click as fast as you possible on this shiny red button and if you score well we'll show you a naked girl!" The user goes into a frenzy of clicks, and all you have to do is throw the picker up in the middle of that.

It's probably a little less problematic for contacts than it is for files (though Aarons are sure going to be getting a lot of spam) but I think it's still problematic enough that we would want to restrict JS-induced contact pickers to trusted environment, relying on <input> otherwise (or on an infobar dialog if we stick with traditional APIs).

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 24 February 2010 14:07:36 UTC