Re: [whatwg] Improving autocomplete

On Sat, Nov 10, 2012 at 10:50 PM, Maciej Stachowiak <mjs@apple.com> wrote:

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

Yes, we considered requestAutofill() but it seems rather confusing since
the attribute on the form is "autocomplete". Perhaps we should revisit this.


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

It doesn't provide such a feature. A form is _always_ displayed. Think of
this like a fancy async prompt().


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


We don't believe this is the case. Think of an airline website: the last
step is going to ask you to review all your information, but you still had
to enter it across multiple steps. This is done for lots of reasons that
have to do with  optimizing click through. The goal is to avoid scaring the
user by making it look like they need to fill out tons of inputs.

Mobile is particularly egregious where we've seen one page worth of
information that's easy to review split across many different pages to
optimize the form completion rate.

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

It requires a user gesture and is connected to the browser chrome. At the
limit this dialog could even show a per domain security image or require a
pin, though I don't think it's reasonable for the standard to require that
level of protection.

Ultimately protections against accidental clicks are up to the browser
vendor. You can slip and click and accidentally expose your location
information through navigator.geolocation's dialog as well, it's up to the
browser vendor to decide how to show the UI to prevent that.


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

Indeed, a user gesture should be required to launch the UI.


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

It overlaps/is connected to the browser chrome.

- E

Received on Sunday, 11 November 2012 19:56:31 UTC