- From: Charles McCathie Nevile <chaals@yandex-team.ru>
- Date: Sun, 11 Nov 2012 14:26:39 +0100
- To: "Elliott Sprehn" <esprehn@gmail.com>, "Maciej Stachowiak" <mjs@apple.com>
- Cc: WHATWG <whatwg@whatwg.org>
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