Re: [whatwg] Improving autocomplete

(1) If this API fills in a form completely based on stored data, and not by completing the user's typing, then it is "autofill" rather than "autocomplete".

(2) If this API provides the ability to get user information without even having a visible form, then it's not clear that it is even really autofill. It's just "requestUserInformation()" or something.

(3) This API has important privacy and even security considerations. You have to tell the user exactly what you are going to fill in to the site before they approve. Unfortunately, most won't read it. If sites are asking for so much info that they have to split pages for usability, then it seems likely the UI that tells the user what the site is asking for will be impractical for most users to meaningfully review. This becomes especially dangerous if the mechanism can fill in credit card info. I would be very nervous if the browser could at any moment pop up a dialog that would submit all my credit card info to a dubious site if I slip and click the wrong button. Can you expand more on what thought you have given to the security considerations?

(4) Should this API be limited to initiation during a user interaction? That would reduce the ability of sites to spam the user with such forms.

(5) What makes the UI unspoofable? Is that an important part of the security model?

Regards,
Maciej


On Oct 26, 2012, at 12:24 AM, Elliott Sprehn <esprehn@gmail.com> wrote:

> Several of us on the Chrome team have been thinking about the
> challenges of filling out long forms full of personal information.
> We've noticed that site authors split up their forms across multiple
> pages to avoid overwhelming their users with one single massive form
> [1]. This is particularly bad on mobile where we've observed some
> popular retailers splitting their forms into six or more pages in an
> attempt to optimize their flow for a small screen. This unfortunately
> defeats many of the advantages of existing browser autocomplete.
> 
> In researching this we’ve found that with a few changes built on the
> existing HTML autocomplete spec [2] we can allow authors to recombine
> their forms and enable browsers to provide more useful autocomplete.
> 
> 1) HTMLFormElement.prototype.requestAutocomplete()
> Asks the user agent to asynchronously present a UI for performing full
> <form> autocomplete using the already spec’ed autocomplete attributes
> [2] used in the form. In concept this is very similar to prompt()
> except the UA could provide a streamlined experience for filling in
> information in large chunks. For example you could imagine choosing a
> shipping address from a drop down instead of presenting multiple
> inputs.
> 
> 2) Simple event named “autocomplete”
> This event is dispatched on the form element after the UI presented by
> requestAutocomplete() is closed if the form validates after having
> filled each input and firing all necessary input events like “change”.
> 
> 3) Simple event named “autocompletecancel”
> This event is dispatched on the form if the UI is canceled.
> 
> Using this API authors may simplify their input flows from forms
> spread over multiple pages to just a few clicks on a single page all
> while getting all the autocomplete goodness! Authors can also display
> no forms at all to users of a browser who implements this proposal for
> one click checkout experiences which are important on mobile devices.
> 
> The proposed additions also improve security on the web as users will
> become accustomed to inputting their sensitive data through an
> unspoofable UI that could warn users of phishing sites or even allow
> them to choose per domain security images.
> 
> We’d love to hear the thoughts of other implementers on this proposal. :)
> 
> [1] ex. Retailers often split forms into credit card, billing address,
> and shipping address pages.
> [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete
> 
> - E

Received on Sunday, 11 November 2012 07:37:15 UTC