Seeing a bad trend here lately, and at IO, where they continually talk about Chrome as a platform. Not the web, Chrome. I read Chromium bugs about Chrome specific APIs and never see any indication that there is intent at standardization. To be clear, I believe in browser vendors innovating with their own APIs with an eye towards eventually standardization. This is what Mozilla is doing through WebAPI, for example, but I don't hear anything like that from the Chrome team. What I see is that parts of Google are involved in web standards, of course, but particularly Chrome seems entirely focused on themselves as the platform.
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.
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.
It is my understanding that the "autocomplete" event being referenced here, is after you 1 - ask the browser to autocomplete, 2 - the user is shown what will be shared, and accept to share it.
That would cover it (by comparison the scenario you think of would be crazy terrible).
I think in that case it would be almost the same as a malicious site calling form.submit() after detecting in javascript that all of the fields have been filled out. It would have a slightly worse accuracy, though, since the user has not yet double checked that the form is correct. Does anyone know if there are laws related to this? I could definitely see it being illegal to automatically submit forms that result in financial transactions.
Look at the screenshot. The permissions dialog shows exactly what information is being submitted, and is labelled 'submit payment details'. No one should be misled.
As others have noted, Chrome does show the data that will be sent in a modal dialog until the user hits "submit". Calling form.submit() should send the user to a confirmation page which also shows parts of the data back to the user, and allows them to confirm the purchase.
You wouldn't even need form.submit() this could be accomplished just through url encoding and ajax. This is exactly why this concerns me too, but it sounds like it will prompt the end user when the api call is made (similar to geolocate apis).
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.
The UI provides a review before completion (which triggers the autocomplete event), and the feature is expressly designed to be used with hidden forms so that no actual form interaction is required.
One of the best use cases for this is on mobile. Conversion rates on mobile are really low because users usually don't want to dig out their credit cards when on their smartphone, let alone fill in all their details on a tiny screen. The ability to just tap a couple of times and use their existing billing information (which is synced from their desktop browser) is a huge win. And as mobile becomes the more popular way to browse the web, I think this could be a pretty big deal for online sellers.
The initial implementation appears to be targeted to e-commerce sites. Your username and password are not included in the fields that this can populate.
Autocompleting billing details without even having a form shown seems like a terrible idea. How does someone with autocomplete enabled not suddenly find themselves missing bundles of money?
Are they disabling the submit button for a second or two after showing it? Otherwise you can trick the user into clicking where the submit button is going to appear and then trigger the autocomplete.
One possible exploit I can think of would be to put up a form that doesn't have an visible credit card fields, but somehow convincing the autofill code to fill it in anyhow. The user thinks they are just autofilling their email but in hidden fields are populating their credit card info. It would be easy to not fill in <input type="hidden"> fields, but field inputs that are more literally hidden (off the top of the screen, obscured by other elements, white-on-white text and elements, etc) is a harder problem. I could see a user clicking through the popup without noticing the popup mentions more info than they realize, because the user is expecting it already and doesn't carefully examine it.
That will have to be addressed by the Chrome permissions dialog ... Agreed though, I think it would be wise to make the user type-in their CVC or something before transmitting the payment info.
> One possible exploit I can think of would be to put up a form that doesn't have an visible credit card fields, but somehow convincing the autofill code to fill it in anyhow.
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.
Speculation: it will be as bad as the Windows Vista UAC dialog. People will just click Yes to get things moving. Permission prompt is not new, except this time they risk losing their credit card information instead of minor things like leaking their geolocation.
Fun fact: Internet Explorer 6 had features called "Wallet" and "My Profile". The data you'd put there would be picked up by HTML forms that use so called "VCARD scheme".
That is strangely true for many new features: They all all already been there at one point in the monopolistic Internet Explorer. e.g. CSS expressions from IE will now have a comeback, RSS was Active Channels, IE had HTML tooltips that went beyond the window, a fullscreen api (much abused), localstorage was domstorage, shadow DOM were behaviours, css filters were directxfilters...
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).
If you're talking about the extra autocomplete attributes, it gives site authors a way to use both the standardized autocomplete fields[0] and different name and id attributes for their own purposes.
Maybe next time do a cursory search before jumping to conclusions? The WHATWG spec is the first link when you search for "requestAutocomplete" on Google.
Biggest problem: many small shops, especially Wordpress shop themes and many self-written shops don't use the autocomplete="..." attribute to properly indicate autocompletion support...
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.
I love the idea of being able to autofill a form on page load using the browsers own history! Also, I'm highly impressed if indeed this is being added to chrome based on something Alex asked for.
Hey intropic, requestAutocomplete() is only invokable in response to a user action (load's not considered that), so it's more likely that this would be done when you click a "checkout" button or something like that.
This terrifies me on a security level... I understand there is a permission dialog, but I very much would not like me credit card information available unless I type it in...
in this case, you can still use Chrome to remember your address information and use this dialog by entering (just) your CC info in from scratch every time.
requestAutocomplete pops up a permission dialog to the user, it's not automatic on sites you haven't already granted permission to - the article mentions this.
What if I permit a site to autocomplete my email, address etc. but not my credit-card. Then, after the permission is given the form is changed to ask for a credit-card.
I'm sure this is all thought trough but I'll wait for a bit before using this.
Great point! This is why I'm always a little hesitant whenever I hear about auto complete abilities. Just the knowledge that your storing personal info (whether it's hashed and salted or not), and authorizing the browser to determine when it is convenient for you not to type.
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.
I figured there had to be a prompt of some sort like the one's with geolocating. Still if there is an automation of some sort...this is an easy way for sites to associate multiple user id's, assuming this would matter to you ;)
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.
It's a very interesting feature. What would be the best fit for it?
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.
Streamlining credit card payments is like improving CVS. It's still a skeuomorphic, Flintstones way of paying for something online. There are better solutions in the works that focus on innovating rather than renovating:
