Re: [whatwg] Improving autocomplete

On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak <mjs@apple.com>  
wrote:

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  
> "autocomplete".

Yep.

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

Yes.

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

Indeed.

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

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

> 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?

Yes...

> 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?

cheers
Chaals

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


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Sunday, 11 November 2012 14:45:46 UTC