[whatwg] Improving autocomplete
Charles McCathie Nevile
chaals at yandex-team.ru
Sun Nov 11 05:26:39 PST 2012
On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak <mjs at apple.com>
The key questions. I've added some more comments...
> (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
> (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.
Right. It's like openly shared super-cookies...
> (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.
And because as soon as you put it into the input field the site can use
it, as a basic security measure it seems like you should never autofill
without explicit user confirmation.
> 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
Yes. This is a problem I face from time to time, and I think its
seriousness is underestimated. This process can be used to collect all
sorts of information before the user realises they didn't want to hand it
> This becomes especially dangerous if the mechanism can fill in credit
> card info.
That assumes your most valuable info is about your credit card, which is
only the case for a certain proportion of people.
> 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?
> On Oct 26, 2012, at 12:24 AM, Elliott Sprehn <esprehn at 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
>> . 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  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
>>  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
>> 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.
>>  ex. Retailers often split forms into credit card, billing address,
>> and shipping address pages.
>> - E
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
chaals at yandex-team.ru Find more at http://yandex.com
More information about the whatwg