Chrome’s requestAutocomplete()
blog.alexmaccaw.com
blog.alexmaccaw.com
Though note that submitting and then completely ignoring the standards group (which has also happened) is not much better than not submitting at all. Especially if the submission doesn't actually give much more than the name of the API and a general idea of what it does.
Look at their off-line standard. They took it to the standardization body who changed it so completely that it was a different beast. Google did the right thing and phased out their old legacy stuff and switched to the standard. In fact IIRC they didn't even put the legacy stuff in Chrome.
And there are various other parts that don't.
Auto-complete has always been incredibly flaky for me. And personally I find that reaching for the credit card is the point where I think, "do I really want this?"
It's as if Google is bringing Amazon's "one-click" checkout to all Chrome users.
Shutupshutupshutup, don't ruin this. ;) (http://en.wikipedia.org/wiki/One-click_patent)
form.addEventListener('autocomplete', function(){
form.submit();
});
Always show the user what information is being sent, always give them an option to change it.
That would cover it (by comparison the scenario you think of would be crazy terrible).
As long as the data is NOT filled in automatically on call and the user is prompted, then this feature SHOULD be safe to use.
I don't use autocomplete, I use 1password, which guarantees my information is as up to date as I want it to be for all sites.
Perhaps browser extensions like 1Password can also leverage this to keep your autocomplete data up to date with your main contact/credit details?
Here are the supported fields:
* Contact: name, tel, email
* Shipping: street-address, address-line1, address-line2, locality, region, country, postal-code
* Billing: street-address, address-line1, address-line2, locality, region, country, postal-code
* Payment: cc-name, cc-number, cc-exp, cc-csc, cc-type
Since the system provides a preview of exactly what is being sent and its designed to be used with completely hidden forms to start with, this isn't an exploit.
http://msdn.microsoft.com/en-us/library/ie/ms533032%28v=vs.8...
What it boils down to is that hiding your form and calling requestAutocomplete allows you to reduce the number of steps in the checkout flow by one (instead of taking the user to a page with a form and then showing a dialog on top of that form, just show the dialog and afterwards jump straight to pre-sale confirmation).
[0]: http://www.chromium.org/developers/using-requestautocomplete...
1. Embrace
2. Extend <-- Google Chrome just went here.
3. Extinguish
What would people say if Microsoft implemented a new JavaScript API in their browser that only they had access to the spec for?
I'm the other presenter from the I/O video. We hope to contribute to popular open source cart software in the near future so that vendors creating a quick shop can benefit from [autocomplete] attributes baked in by default.
1. you visit site: whatever.com
2. I have a hidden input with a name="address"
3. I have an onchange event listener for the hidden input
4. Now auto complete fills in automatically and I just associated your ip with your address (assuming the the auto fill is correct).
I always think this whenever I hear about auto complete. I NEVER save form data just for this reason.
I'm sure this is all thought trough but I'll wait for a bit before using this.
What my privacy concern is just a javascript phishing attack (nothing too complicated that a beginner can do). Not to say this feature wouldn't be nice, just making the suggestion that there is alot of room for concern here.
If you have questions or feedback, you can reach out to us at requestautocomplete@chromium.org. I'll also try to answer some of the questions on this thread.
Home address would be too complex with too much variations, same thing for gender or title. Login/password would be better handled by a token cookie...
It seems to be best used for email or phone number fields, or other very standardized data only.
Addendum: the example given in the post would be bad, as for most credit card forms you would want a control code input, and generaly wouldn't want to encourage sensitive data to be autocompleted.