On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak <[email protected]>
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 <[email protected]> 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
[email protected] Find more at http://yandex.com
