- From: Elliott Sprehn <esprehn@gmail.com>
- Date: Sun, 11 Nov 2012 10:58:34 -0800
- To: Maciej Stachowiak <mjs@apple.com>
- Cc: WHATWG <whatwg@whatwg.org>
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