Ignoring autocomplete='off'

[Joel Weinberger]

Just an FYI that I sent an email to public-webapps to start a conversation about the autocomplete='off' standard and our intentions of ignoring autocomplete='off' for the Chrome password manager:

http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/1002.html

Opinions and thoughts here are welcome as well.

--Joel

[Michael Anderson]

I disagree with the idea of leaving no way for a website owner to disable password auto completion.  Just because it is not a perfect solution does not mean it should be removed entirely and no reason to make it even easier for 'bad guys' to rip off end users.  This change would encourage a "default insecure" mode of operation; this is a bad thing.

My largest reason: corporate users.  In most companies I've been involved with, this can be a BIG deal, especially with internal webapps.  I'd prefer not to disable Password Manager entirely, because I don't frankly care what users do with their personal accounts, but I do care what users do with their work credentials.  If this goes through, I will have to recommend Password Manager be disabled entirely - and that does not mitigate the entire problem.  Users logging in to OWA or to VPN from home would be encouraged to save their company password in their home browser - and I could do nothing about it.  I know users can write passwords down on a post-it note, but they aren't encouraged to do so via the browser pop-up: "hey, want me to save that password for you?"  It is the shift to default insecure that is a bad thing.  I know there are other ways to be insecure, but we shouldn't make the browser a weak link in the chain.

I'm mostly focused on the user-security side, and I can say that the last thing I want most of my 1500+ users to be doing is saving their company passwords in any web browser.  I have an approved and centrally controlled password management solution - I do not want to decentralize that functionality even if you could convince me that Chrome's solution is 100% safe (which you would be very hard pressed to do for the simple fact that the average end user is oblivious to all things security).

I also don't trust that these passwords won't become visible http://www.engadget.com/2013/08/07/chrome-saved-passwords/ - which I recognize has been responded to, but I could not disagree more with the response. In a corporate world (and to a lesser extent for home users), the OS account does protect the majority of secrets and access levels.  But the widespread popularity of Single Sign On means that the OS account is also used to control access to internal webapps.  This is important because now access to the local machine through any means also gives access to the main account holder's password.  This is way more severe than having access to the OS account because it now allows taking that set of credentials and jumping around to other systems.  Sadly, lots of users don't always lock their systems every time they stand up from a computer.  This should not grant access to the user's privileges.  Yes, they could try to install malware - but not without first defeating all the other protections that have been put in place to prevent installation of software, downloading of executables, or mounting of removable drives.  Saved passwords being compromised prevents all these additional protections from doing their jobs (and potentially allowing for alerting and monitoring systems to do their jobs and tell the right systems or people that something is wrong).  

Which brings me to my next point: detectability.  

A compromised end user system can typically be traced, even if necessary after an incident has run its course, to follow that incident backwards to patient zero.  It is possible to remove all tracks, but in my experience it is not something commonly done.  Stealing a password with such ease (user walks up to an unlocked machine, clicks a button, gets a password) would be very difficult if not impossible to detect.  

Please reconsider ignoring autocomplete='off' for password fields - this would be very bad from a security point of view.  

[PhistucK]

I guess an administrative template that supports a policy for not saving passwords for particular pages or domains should work for you.

If so, maybe file an issue at crbug.com for that.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.

[Joel Weinberger]

Thanks for the email, Michael! I agree with PhistucK; it sounds like what you really want is support for a password management enterprise policy, which sounds like a reasonable feature request. Definitely file an issue at http://crbug.com if you think you would want that.

I'm inlining some other response and thoughts below. Please let me know what you think and if you have and responses.

On Tue, Dec 31, 2013 at 3:00 AM, PhistucK <phis...@gmail.com> wrote:

I guess an administrative template that supports a policy for not saving passwords for particular pages or domains should work for you.

If so, maybe file an issue at crbug.com for that.

☆PhistucK

On Tue, Dec 31, 2013 at 12:03 AM, Michael Anderson <miketa...@gmail.com> wrote:

I disagree with the idea of leaving no way for a website owner to disable password auto completion.  Just because it is not a perfect solution does not mean it should be removed entirely and no reason to make it even easier for 'bad guys' to rip off end users.  This change would encourage a "default insecure" mode of operation; this is a bad thing.

To be clear about our position: we believe (very strongly) that ignoring autocomplete='off' will actually *increase* security for our users and websites. autocomplete='off' provides virtually no added security for users and websites and it disables password managers, one of the most useful tools for increasing user security. Right now, the default is that websites can force the disabling of password managers. Thus, the status quo is default insecure, and we want to change that.

My largest reason: corporate users.  In most companies I've been involved with, this can be a BIG deal, especially with internal webapps.  I'd prefer not to disable Password Manager entirely, because I don't frankly care what users do with their personal accounts, but I do care what users do with their work credentials.  If this goes through, I will have to recommend Password Manager be disabled entirely - and that does not mitigate the entire problem.  Users logging in to OWA or to VPN from home would be encouraged to save their company password in their home browser - and I could do nothing about it.  I know users can write passwords down on a post-it note, but they aren't encouraged to do so via the browser pop-up: "hey, want me to save that password for you?"  It is the shift to default insecure that is a bad thing.  I know there are other ways to be insecure, but we shouldn't make the browser a weak link in the chain.

 

I'm mostly focused on the user-security side, and I can say that the last thing I want most of my 1500+ users to be doing is saving their company passwords in any web browser.  I have an approved and centrally controlled password management solution - I do not want to decentralize that functionality even if you could convince me that Chrome's solution is 100% safe (which you would be very hard pressed to do for the simple fact that the average end user is oblivious to all things security).

As you point out, there are many other threats if users are using corporate resources from a personal computer. Malware on personal computers is your real threat, not password storage. If you're going to allow that, what you really want is for users to use corporate certs in their personal browser, which could allow you to disable passwords for your mail anyway.

Furthermore, as a company, I would argue that you ought to reconsider how you feel about users using password managers. They allow users to have longer, stronger, random passwords that are not reused on other sites. Without password managers, users use the same password, over and over and over again, including for corporate credentials. You may *ask* them not to, but they don't. And if you are asking them not to, then you already trust them, so why not tell them to *not* use the password manager (it only takes one click to ignore it forever)?

But if you reject all of that, what you're arguing is that Chrome should provide a feature that can be used by any website that, overall, decreases the security of users. What you're arguing is that companies have credentials that are so important, they cannot be stored by the user agent. Now, replace "companies" with "banks" or "mail providers" or whatever. All organizations believe that their credentials are the most important ones. That's the world we live in now, and in this world, a huge percent of websites use autocomplete='off', which means that password managers are unusable, and users *must* reuse passwords, have short passwords, and certainly don't have random passwords.

In the end, your argument inevitably leads to the status quo, which is a world in which passwords are not secure tokens. Password managers help mitigate this (of course they're not perfect, but they're a huge improvement).

I also don't trust that these passwords won't become visible http://www.engadget.com/2013/08/07/chrome-saved-passwords/ - which I recognize has been responded to, but I could not disagree more with the response. In a corporate world (and to a lesser extent for home users), the OS account does protect the majority of secrets and access levels.  But the widespread popularity of Single Sign On means that the OS account is also used to control access to internal webapps.  This is important because now access to the local machine through any means also gives access to the main account holder's password.  This is way more severe than having access to the OS account because it now allows taking that set of credentials and jumping around to other systems.

This is true even without a password manager. If you have local system access, sticking a keylogger on the machine gives you full access to the user's credentials. The password manager does not make this worse. 

 Sadly, lots of users don't always lock their systems every time they stand up from a computer.  This should not grant access to the user's privileges.  Yes, they could try to install malware - but not without first defeating all the other protections that have been put in place to prevent installation of software, downloading of executables, or mounting of removable drives.  Saved passwords being compromised prevents all these additional protections from doing their jobs (and potentially allowing for alerting and monitoring systems to do their jobs and tell the right systems or people that something is wrong).  

This is a strong argument as to why, as a company, it might not make sense to allow users to use personal machines that you (the company) have no control over. Lack of OS lacking implies malware on the machine, independent of password managers. This really is orthogonal to the issue of autocomplete='off'.

[dave.m...@gmail.com]

This isn't a vital thing for me but I do think it's a mistake for Chrome to ignore the attribute. If Chrome were smart enough to reliably recognize login forms 100% of the time then it might be a different story, but it's not smart enough.

Instead, every web form I have that asks for a password is automatically being filled with login information, even if it's not a login form. I know my design better than Chrome. I should be able to stop the autocomplete behavior there.

[Devdatta Akhawe]

(sorry if I am taking this a bit off-topic)

Hi Dave

I am curious: what are these web forms that ask for a password but are
not login forms? Other than "password reset" forms, I can't think of
anything.

thanks
Dev

On 29 May 2014 00:40, <dave.m...@gmail.com> wrote:
> This isn't a vital thing for me but I do think it's a mistake for Chrome to ignore the attribute. If Chrome were smart enough to reliably recognize login forms 100% of the time then it might be a different story, but it's not smart enough.
>
> Instead, every web form I have that asks for a password is automatically being filled with login information, even if it's not a login form. I know my design better than Chrome. I should be able to stop the autocomplete behavior there.
>

[Dave Mittner]

In my particular case it's an Add User form.

It's particularly annoying in this case since the form is autofilling with the admin's credentials when they're trying to add a new user.

Fortunately our Reset and Forgot password functions aren't affected by this since there's no preceding text field for Chrome to assume is a username field.

[Devdatta Akhawe]

Hey Dave

thanks! that's actually pretty interesting: I hadn't thought of this
issue with password managers. If I am not wrong, any password manager
(Chrome's built-in or something like LastPass) will have this bug?

I wonder if the removal of autocomplete=off is just making this issue
more obvious to you. It seems the issue here is that Chrome does not
have an option for you to tell Chrome "never auto-fill for this URL".
Would that solve your problem?

I am not a Chrome developer, but to me, this sounds like a reasonable
feature request. LastPass, e.g., already supports this feature, as I
imagine many other password managers do.

Thanks
Dev

[PhistucK]

Usually, a new user form includes two password fields, in which case, as far as I know, Chrome generally does not fill the username and password fields automatically.

So the workaround (and the right behavior, in my opinion) is to add another password field, which is always a good practice anyway (to make sure you typed the password you actually intended).

☆PhistucK

[Dave Mittner]

A URL-based setting would be a step in the right direction but would lack the ability to fine tune.

For example, if you were to go to "https://www.website.com/admin" and you're logged in as an admin user, the page is broken into many control panel tabs of which just one contains the Add User form.

If you go to that URL not logged in, the URL remains the same but you're shown a legit login form instead. Once you submit it, the login process is all AJAX driven and the admin screen is displayed without the URL changing, without the page even reloading. You can actually log out and log in again, all without a page reload or URL change

So in this case a URL-based setting would apply to both the Add User form and the login form. You really need it to be a form-based -- or even a form field-based setting -- to have sufficiently granular control in a case like this.

[Dave Mittner]

This is not my observation.

My Add User form does have a "Confirm Password" password field immediately after the first, and autofill is still being performed.

I read about the logic for this some time ago and it wasn't terribly intelligent. If it finds a password field after a text field it assumes they're login fields and fills them out--even if the text field preceding the password field has nothing to do with a username.

I'll throw together a super-quick test to verify that before I hit the sack...

[Devdatta Akhawe]

Hey

If there are two password fields, then, I imagine Chrome can be smart
enough to not auto-fill. If you find otherwise, I think you should
file a bug. I am not sure how easy it is to fix though.

The "don't autofill" option for a URL will only disallow autofill. You
will still be able to manually fill in the password: it should
basically take you back to "autocomplete=off" world, which is what you
wanted initially?

thanks
Dev

[Dave Mittner]

I did, but on a form basis (as opposed to URL basis)

Setting it on a URL basis wouldn't support cases like I mentioned before, where you might have a login form and an Add User-like form show on the same URL under different circumstances. So I'd be forced to either disable autofill for both, or allow it for both. I'd end up back at square one since I definitely DO want autofill for the legit login form.

Checking for a second password field in a form might help make it more intelligent but I still think it's a behavior the web developer should be able to override, just in case. I'm all for software intelligence for default behaviors but it shouldn't be authoritative; the site developers should still have influence.

I was hoping to throw up a jsfiddle sample but if there's a way to trigger a login save on it, it'll take more time than I have right now. And I really miss having my own server to throw up stuff on quick and easy. Meh. So that'll have to wait for the morning. Exhausted.

[Greg Thompson]

On Thu, May 29, 2014 at 4:23 AM, Dave Mittner <dave.m...@gmail.com> wrote:

This is not my observation.

My Add User form does have a "Confirm Password" password field immediately after the first, and autofill is still being performed.

I read about the logic for this some time ago and it wasn't terribly intelligent. If it finds a password field after a text field it assumes they're login fields and fills them out--even if the text field preceding the password field has nothing to do with a username.

I'll throw together a super-quick test to verify that before I hit the sack...

Hi Dave,

If you manage to get a small test that reproduces the behavior you find frustrating, please file a bug according to the guidelines at http://www.chromium.org/for-testers/bug-reporting-guidelines. Add the Cr-UI-Browser-Autofill label so that it is triaged properly. Thanks.

[PhistucK]

Only project members can add labels, unfortunately, so just post a link to the bug here if you one and we will add labels.

☆PhistucK

[Dave Mittner]

Will do, Greg. Unfortunately I need to table this for the moment. I'm starting to put more time towards this than I can afford to at the moment. You'd think it'd be easy to throw an example together but now I'm struggling to even get Chrome to offer to save a password on my test page, to say nothing about replicating the subsequent autofill problem. =/

[Joel Weinberger]

For the record, there already is the ability to "never autofill" on a page, and I think some of the upcoming password manager UIs we're working on will expose this more obviously to the user. But as has been said before, it actually sounds to me like this *might* be a Chromium bug, so if you do get a chance, please file a bug so we can take a closer look.

[Dave Mittner]

Okay, I finally got something together, complete with some crude instructions.

http://gamersyndicate.com/misc/savebug.php

I'll let folks here take a quick glance to see if they think it's truly a bug or if it's "working as intended" under the desired detection intelligence.

Worthy of note here is that Firefox autofills the secondary form the same unintended way, but it respects the autocomplete attribute on the form, allowing the developer to disable it. So if it is working as intended, I come back to my original point that Chrome should likewise respect the attribute so developers can help Chrome behave as the page design intends.

[PhistucK]

Perhaps the issue here is that the second password field does not have a "name" attribute (which means that it does not participate in the form submission)?

☆PhistucK

[Dave Mittner]

Whoops.. forgot that. I've added it back in, same behavior.

I believe it's also the same behavior if you use IDs instead of names.

[Joel Weinberger]

I suspect that this is a variant of https://crbug.com/352347. Please take a look at that bug, as I think it covers this case. I don't know what the solution is, but we're working on it.

--Joel

[Dave Mittner]

Yep. That's settling on the same issue, with many people citing the issue in CMS applications, which is where I actually first encountered the problem long ago.

Some of the replies are a bit frustrating, too. It seems the original assumption was that password fields are only ever used for logging in, and so the intelligence used by all the browsers was to autofill based primarily on that.

The intelligence was then improved to check for a preceding text field, require input IDs or names, make sure there isn't a proceeding password field, etc. I support the improvement, but evolved assumptions are still assumptions.

Logically you cannot assume that all relevant inputs will have a name or ID attribute; AJAX and DOM traversing could allow for inputs to be used that lack both. Logically you cannot assume non-login forms will always have a confirmation password field, or that it will immediately follow the primary field in the HTML structure. It makes sense to factor those in to help achieve proper handling in the absence of more explicit instructions, but standards should evolve in the direction of supporting explicit instructions, not ignoring them.

When you choose to ignore things like the "autocomplete" attribute it sends the message that you think your established intelligence is 100% perfect when, truthfully, it never will be. There aren't any web design laws that dictate a completely predictable structure--or at least none that I've ever come across. Dynamic DOM manipulation would likely throw even that for a loop.

That said, were I in a position to influence direction, I'd be going the other direction, too. Support autocomplete not only on forms but on individual form fields. Perhaps introduce an 'intent="login"' attribute standard for forms or form fields to help direct browser behavior. You can still have your intelligence apply when such things aren't specified, but don't throw designer influence to the wayside.

Ultimately it's not the job of a browser to assume what a designer wants; it's the job of the designer to tell the browser what they want.

[Joel Weinberger]

On Thu, May 29, 2014 at 2:11 PM, Dave Mittner <dave.m...@gmail.com> wrote:

Yep. That's settling on the same issue, with many people citing the issue in CMS applications, which is where I actually first encountered the problem long ago.

Some of the replies are a bit frustrating, too. It seems the original assumption was that password fields are only ever used for logging in, and so the intelligence used by all the browsers was to autofill based primarily on that.

The intelligence was then improved to check for a preceding text field, require input IDs or names, make sure there isn't a proceeding password field, etc. I support the improvement, but evolved assumptions are still assumptions.

Logically you cannot assume that all relevant inputs will have a name or ID attribute; AJAX and DOM traversing could allow for inputs to be used that lack both. Logically you cannot assume non-login forms will always have a confirmation password field, or that it will immediately follow the primary field in the HTML structure. It makes sense to factor those in to help achieve proper handling in the absence of more explicit instructions, but standards should evolve in the direction of supporting explicit instructions, not ignoring them.

When you choose to ignore things like the "autocomplete" attribute it sends the message that you think your established intelligence is 100% perfect when, truthfully, it never will be. There aren't any web design laws that dictate a completely predictable structure--or at least none that I've ever come across. Dynamic DOM manipulation would likely throw even that for a loop.

That's certainly not the message that we intend to send. We made the change because we think we do a *pretty* good job, and that we want *users* to have a choice (after all, if users find it frustrating, they can just choose to not use the password manager for your site).

That said, were I in a position to influence direction, I'd be going the other direction, too. Support autocomplete not only on forms but on individual form fields. Perhaps introduce an 'intent="login"' attribute standard for forms or form fields to help direct browser behavior. You can still have your intelligence apply when such things aren't specified, but don't throw designer influence to the wayside.

Ultimately it's not the job of a browser to assume what a designer wants; it's the job of the designer to tell the browser what they want. 

No, it's the job of the user to tell us what they want, which is what we're doing here. We want the user to make the decision about whether they want to use the password manager. If they find it frustrating, they are welcome to turn it off. However, hopefully we'll be able to fix the many, many edge cases (for example with helpful reports such as yours) so users won't want to turn it off.

[Dave Mittner]

But you only give them the option to use it on a domain basis. That's where your entire position falls apart.

Give me a day and I could probably come up with a hundred web applications that have both conventional login forms a user would want the password manager to apply to and administration screens that include password fields they don't want it applied to.

Are you going to give them that level of granular control? And with the flexibility of HTML structure, DOM manipulation, etc. how would you ever accurately tell situations apart without the help of the designer?

I and others have already shown you when and how these mis-autofills can happen, you've admitted your logic isn't perfect, and on administration screens incorrect autofills can even lead to data corruption or, worse, security issues of web applications, databases, or whatever it is the administration tools are handling passwords for.

I don't understand why you're so resistant to designers helping you with simple form attributes. You want to empower the user. I get that. But it's in your own interest to apply the password manager only where it's relevant. We designers can help you do that if you'd let us. It's in our interest as much as yours for these tools to apply to our sites correctly.

For our influence to be ignored altogether, well... I'm trying very hard not to feel as though you see us as some sort of bad guy to your intentions. I remember the days when I had to set a "Remember Me" cookie to keep a person's username in the log in form. Believe me, we're on the same side here. Let us help you apply your tool accurately.

[PhistucK]

The problem does not lie with good designers - it lies with bad ones - banks actively prevent password autofilling for no real reason - it is not more secure and they make you think (this is anyway the reasoning for disregarding autocomplete="off"). So the good designers get hurt as a result of bad designers. Kind of like DRM. :)

☆PhistucK

[Joel Weinberger]

On Thu, May 29, 2014 at 2:54 PM, Dave Mittner <dave.m...@gmail.com> wrote:

But you only give them the option to use it on a domain basis. That's where your entire position falls apart.

Give me a day and I could probably come up with a hundred web applications that have both conventional login forms a user would want the password manager to apply to and administration screens that include password fields they don't want it applied to.

Are you going to give them that level of granular control? And with the flexibility of HTML structure, DOM manipulation, etc. how would you ever accurately tell situations apart without the help of the designer?

I and others have already shown you when and how these mis-autofills can happen, you've admitted your logic isn't perfect, and on administration screens incorrect autofills can even lead to data corruption or, worse, security issues of web applications, databases, or whatever it is the administration tools are handling passwords for.

I don't understand why you're so resistant to designers helping you with simple form attributes. You want to empower the user. I get that. But it's in your own interest to apply the password manager only where it's relevant. We designers can help you do that if you'd let us. It's in our interest as much as yours for these tools to apply to our sites correctly.

That is what the argument in favor of autocomplete='off' states. Unfortunately, in practice, many Web applications used it as a tool to keep password managers from remembering passwords when they really should have, and while those Web developers thought they were protecting their users, they were really lowering their users' security by disallowing the use of password managers. Thus, reintroducing such a feature would have the same result; developers could use it as a way of getting the password manager to not run on their site.

For our influence to be ignored altogether, well... I'm trying very hard not to feel as though you see us as some sort of bad guy to your intentions. I remember the days when I had to set a "Remember Me" cookie to keep a person's username in the log in form. Believe me, we're on the same side here. Let us help you apply your tool accurately.

We certainly appreciate the help, and this is exactly the kind of report that's useful, believe me! I'm just arguing that the answer isn't an "ignore me" attribute of some sort; the answer is fixing the password manager.

Put differently, in our view, it's not that big a deal if the password manager is over aggressive in a site; users can always escape that by, in the worst case, erasing the fill. The much, much bigger problem is when we're too conservative, and the password manager doesn't fill, because then the password manager is useless.

I certainly agree that we're on the same page, and I think it's just our views of what a solution look like that differ.

[Dave Mittner]

And if that's their goal, you're not going to stop them.

My bank circumvents autocomplete by asking for your username and password on separate pages. I think I previously mentioned that AJAX and DOM manipulation could allow for logins to be performed even if the input fields don't have a name and ID.

What do you have in mind to successfully apply autocomplete in cases like this, that wouldn't have a high probability of causing false-positives in other cases?

Further, in attempting to circumvent autocomplete they're actually inconveniencing the user more than they'd be if autocomplete="no" were simply respected.

This isn't a battle that can be won, and so long as you fight it you're going to alienate the people attempting to avoid autocomplete and people like me who are trying to have a way to apply it accurately to web applications.

I've already come up with half a dozen different ways to bypass the autocomplete on my Add User form, all of them making my job more difficult so that our users don't have to delete data every single time they come to this form.

[mik...@gmail.com]

Maybe if the password manager stored the field ID and/or name attributes of the fields used as username/password. The password manager completes ANY fields that show up in a form in the sequence of <input type="text"> followed by <input type="password">!!! This totally messes with editing/creating a "user profile" on a site's admin area. If you're going to IGNORE that I'm setting autocomplete="off" and give me NO ALTERNATIVE, then Google, on your part you could at the very least remember the field name(s) where the username/password were saved. Otherwise that just makes Chrome another Asshole browser to be frank...

If Microsoft decided to try anything like this people would be up in arms about it!!!

<sarcasm>So, way to go guys!! *Claps*</sarcasm>

[Joel Weinberger]

On Thu, Jun 19, 2014 at 7:21 AM, <mik...@gmail.com> wrote:

Maybe if the password manager stored the field ID and/or name attributes of the fields used as username/password.  The password manager completes ANY fields that show up in a form in the sequence of <input type="text"> followed by <input type="password">!!!  This totally messes with editing/creating a "user profile" on a site's admin area.  If you're going to IGNORE that I'm setting

As we've said, we're constantly working on improving our matching heuristics. For example, see https://code.google.com/p/chromium/codesearch#chromium/src/components/autofill/core/common/form_field_data.h&q=FormFieldData&sq=package:chromium&l=19 for more information on how we identify autofill form equivalents (note the comments that talks about implementing field ids).

autocomplete="off" and give me NO ALTERNATIVE, then Google, on your part you could at the very least remember the field name(s) where the username/password were saved.  Otherwise that just makes Chrome another Asshole browser to be frank...

Please try to keep this civil. Clearly we're not trying to jerks; we're trying to create the best experience for the user possible. There are sites where the password manager doesn't work perfectly, and we try to fix those issues.

If Microsoft decided to try anything like this people would be up in arms about it!!!

IE already does ignore autocomplete='off' (http://blogs.msdn.com/b/ieinternals/archive/2013/09/24/internet-explorer-11-changelist-change-log.aspx).

[Dave Mittner]

Mikhey- If you want to circumvent the autofill, I found that you can do so by submitting the form data via AJAX. In my case I don't even use <form>. I just have IDs for all my fields then, when a user clicks the submit button or hits "enter" on appropriate fields, I collect all the values and pass them on through an AJAX POST.

The trick is to break out of the standard mold for forms. They'll be hard pressed to detect appropriate places for autofill if they don't have predictable structure.

You might also be able to avoid it if you have the form HTML load into the page dynamically. If it's not part of the initial HTML structure, maybe they'll miss it. I haven't tested this approach, though.

If they want to take away our control we'll just find creative ways to escape theirs.

On Thu, Jun 19, 2014 at 7:21 AM, <mik...@gmail.com> wrote:

[Chris Palmer]

On Thu, Jun 19, 2014 at 1:27 PM, Dave Mittner <dave.m...@gmail.com> wrote:

> If they want to take away our control we'll just find creative ways to
> escape theirs.

http://www.w3.org/TR/html-design-principles/#priority-of-constituencies

"""In case of conflict, consider users over authors over implementors
over specifiers over theoretical purity. In other words costs or
difficulties to the user should be given more weight than costs to
authors; which in turn should be given more weight than costs to
implementors; which should be given more weight than costs to authors
of the spec itself, which should be given more weight than those
proposing changes for theoretical reasons alone. Of course, it is
preferred to make things better for multiple constituencies at
once."""

[Dave Mittner]

The way I read that, you're supporting me?

Your browser's assumptions are creating a detrimental experience for some of my users. In considering my users foremost--as that principle states--I'm having to find ways to escape those assumptions.

But on the other hand, if you think that's justifying Chrome's position of applying those assumptions, I'd point out that the document you reference is about HTML5 design principles--not optional browser utilities like autofill. 

Further, if you want to go to HTML5 specs, per http://www.w3.org/TR/html5/forms.html#the-form-element the autocomplete attribute is legitimate. So by deliberately ignoring it in Chromium you're making the browser HTML5 non-compliant.

[PhistucK]

What is your point? Internet Explorer was the first to ignore that attribute. Chrome simply followed suit, since it is mostly reasonable. The buggy cases are being fixed as they are discovered (you can point out bugs at crbug.com). Just generally complaining would not get you anywhere.

☆PhistucK

[Dave Mittner]

My point is that the people that build a website will know that specific website better than Chrome will. The people who communicate with a site's users directly will understand their needs for that site better than Chrome ever will.

The "bug" is the underlying assumption that Chrome's developers know every single website out there better than those websites' own creators. Creators who have a lot more invested in that specific website's interaction and success than Chrome's developers do.

I have no problem with Chrome's autofill behavior as a default. But when it fails to work correctly and imposes a burden on a website's users, that website's creators should have some recourse. And if the creators can't help make the browser function correctly, who gets hurt? It makes the website look bad. It makes the browser look bad. It frustrates creators like myself to the point we go out of our way to negate the autofill logic. Nobody wins. Let the creators easily help guide the autofill behavior and everyone wins.

To that, someone previously responded that the perspective is that because some website creators will intentionally and wrongfully disable autofill, the autocomplete attribute is ignored for everyone--even if it hurts good creators, their websites, and their users. My rebuttal was simple: if someone really wanted to disable autofill they'll find a way. I figured out about 3 ways of doing it in under 5 minutes and employed one in a commercial website. My bank does it by inconveniencing the user with multiple pages to collect username and password. I think my healthcare insurer's website does the same.

So with that in mind, is it really worth alienating website creators by denying all control? Especially when it means going against HTML specifications?

As for your comment about Internet Explorer, given Microsoft's history of bucking standards and accepting bad HTML (which lead a generation of web designers away from IE and towards Firefox and then Chrome) I wouldn't encourage anyone to follow any of their leads.

[PhistucK]

My Internet Explorer comment was really aimed at @mikhey -

"If Microsoft decided to try anything like this people would be up in arms about it!!!"

And my comment still stands. If you find a sensibly wrong case where autofill is being employed when it should not (like a password changing page, or a user creation form and similar), file an issue at crbug.com and the team will investigate or fix.

☆PhistucK

[Dave Mittner]

"And my comment still stands. If you find a sensibly wrong case where autofill is being employed when it should not (like a password changing page, or a user creation form and similar), file an issue at crbug.com and the team will investigate or fix."

And my comment still stands that there will always be the potential for situations in which things are filled that shouldn't be, or not filled that should be. Especially when dealing with heavy DOM manipulation, cases where form fields don't have name attributes, etc. Tools should be added and specs should be pushed in the direction of maximizing author input, not ignoring it.

I've handled my immediate problem. I have no interest in reporting a bug for this and helping push an agenda I'm fundamentally against. When the Chromium devs restore author input to the HTML5 specifications, maybe then I'll think they give a crap about the help I could offer them to make this whole mechanism better.

[Adrienne Porter Felt]

The root of the problem here is that there are two ways to use autocomplete=off:

1. To give the browser a hint that this isn't really a password field.
2. To prevent users from saving passwords that they *want* to save.

Lots of developers were using it in the second way, which was very frustrating for end users because it meant that they didn't have control over their own password management. If there were a way to accomplish #1 without also allowing #2, it would solve both problems.

[Joel Weinberger]

I feel like we've gotten off to a bad start here, and I'd love to bring this back to somewhere we can all be happy. I think Adrienne's point is great. Let's brainstorm around that.

Dave, you want to make sure your users have a great, secure experience on your site. Chrome wants the same. The point of the password manager is allow users (that turn it on) to have a more secure experience on the web. Currently, your users are having a not-great experience because the password manager is filling credentials into the wrong field/form. We certainly don't want you to have to modify your web page in order to avoid that. I want Chrome to assist you in that.

So let's brainstorm how Chrome can detect your form correctly so it doesn't accidentally fill credentials into it. Do you have any suggestions? Are there any identifying features of this form that Chrome can use to avoid filling into it?

[Dave Mittner]

Adrienne-

I appreciate the problem but my point is that if developers want to prevent saving they're going to find a way and it's not that difficult with a bit of Javascript. In the meantime you're hurting the ability of developers, like myself, to help with #1 per the HTML5 specification. The two-page login process I mentioned is something you'll realistically never be able to overcome because it offers you no fields to compare. My personal solution omits even using <form> tags and only uses input field IDs to collect the values and pass them on via AJAX.

Joel-

If you want to talk my very specific situation, it's an "add user" form. Prior to my change it still submitted via AJAX, but had a conventional <form> structure. The quick and easy way to handle my situation would be to see if there's a second password field within the form. That would suggest a confirmation field which would suggest a form used for something other than logging in. But there's also no guarantee that such a form would have a confirmation field--a Xoops-derivative CMS I had years ago had this very same issue and had only a single password field.

It's also possible, though unlikely, that a login form would have two password fields, so the above logic could result in false positive matches. But with people going crazy over security lately it wouldn't surprise me if some sites ask for a password and secure pass phrase or something.

On Thu, Jun 19, 2014 at 4:41 PM, Adrienne Porter Felt <fe...@chromium.org> wrote:

[graham...@gmail.com]

This is broken. COMPLETELY BROKEN.

Remembering passwords, and giving users an option to use their remembered passwords even when auto fill is turned off, is one thing.

Ignoring the website / designer and simply blasting in values when you *think* you might have found a login form means that you are breaking web applications.

There are more reasons to use type="password", or have a form that may resemble a login form, than to actually implement a login form.

The net result is that if you just blast in saved details to every form that looks like it might need them, then you are putting those details into the wrong place. Applications no longer work, and there is no reasonable workaround.

By all means, give users a button that says "we've detected a form, would you like me to fill it", or "would you like to fill this field with a stored value."

But don't simply blast in values with no user intervention, when the website says not to do it.

[Joel Weinberger]

Just as a brief update, there have been some recent comments and back and forth on https://crbug.com/352347. Take a look and feel free to respond here or there, in particular my suggestion in https://crbug.com/352347#c35.

--Joel

[vbi...@gmail.com]

...this is an old thread but I still observing this behavior on v44.

Actually, I do not understand folks, who are trying to pretend that it is okay, and we just need to find a solution for the new "feature". This is NOT OKAY. W3C clearly defines behavior of "autocomplete" flag.

Hey, google folks - this is not a feature. This is a BUG.

[PhistucK]

For your information, the standard says "should", not "must". So this is still compliant. Also note that Chrome is not the only browser that does so.

☆PhistucK

[vbi...@gmail.com]

Interesting. So, specification was not strong enough to give an idea how such "feature" can affect security :) Okay. The fact that other browsers are doing that does not mean this is correct behavior. Specification allows to make it right and leave a choice. If developer wants to enable auto-completion, he will do it.

[fuhrm...@gmail.com]

On Thursday, May 29, 2014 at 3:48:11 AM UTC-4, Devdatta Akhawe wrote:
> (sorry if I am taking this a bit off-topic)
>
> Hi Dave
>
> I am curious: what are these web forms that ask for a password but are
> not login forms? Other than "password reset" forms, I can't think of
> anything.

Moodle has (had) a bunch of forms break because of this. Passwords are used in many creative ways. For example, a user is granted an extension to an online quiz, the access can have a password that is not the user's or the administrator's. It's more of an access code than a traditional password, but it's coded in the form as type="password" because it shouldn't be visible (I guess) and so it's getting autofilled incorrectly.

Moodle developers have struggled to fix this problem over the months of the autocomplete="off" moving target. It's not just a Chrome issue.

Some details can be found in the bug tracker:
https://tracker.moodle.org/browse/MDL-51083
https://tracker.moodle.org/browse/MDL-45772

[Joel Weinberger]

Those appear to be more or less bugs with the password manager, which should be smart enough to not fill there. It would be awesome if you could file bugs with those examples so we can try to address those.

--Joel

[fuhrm...@gmail.com]

On Saturday, September 19, 2015 at 12:01:02 PM UTC-4, Joel Weinberger wrote:
> Those appear to be more or less bugs with the password manager, which should be smart enough to not fill there. It would be awesome if you could file bugs with those examples so we can try to address those.

Done - I filed 533955 and asked for some Moodle people to help with contributing more cases to it (I can't reproduce all of them without admin privs).

Cris

[mehdiz...@gmail.com]

Support the cause.

I understand that a lot of web-developers do not put in much thought and block it off.

But leaving no-way isn't right either. I need the user to log-in to my platform which lets' say is like an corporate internal system, but if for medical inputs - patient diagnostics gets autocomplete data that could be a killer!... A huge loss for a financial business because "autofill" refuses to go off the input .. and so on.. all practical cases on scaling up my applications as they pick up pace, bogged by (undisciplined) issues from Google!

Please reconsider

Mehdi
- Supporting letting go of Autofill feature

[PhistucK]

For such pressing issues, you can always use contenteditable (maybe even contenteditable="plaintext-only") instead. It is a workaround, not a great way of implementing this, but it should work.

☆PhistucK

--
You received this message because you are subscribed to the Google Groups "Security-dev" group.

[or...@blossom-elearning.com]

We have tables with users information and input fields for search/filter by user name and other details. These fields are autofilled with the current user's username, making the entire table filtered and unusable. We could not find a way to empty the autofilled inputs, even when we mark the value and delete it with backspace it gets autofilled again and the table is filtered again, making the entire report unusable.

I know of several (complicated) workarounds for this (use `data-name` instead of `name`, add junk to the `name` attribute, use `contenteditable` instead of `input`) but this is clearly a bug.

[nickp...@gmail.com]

I think the user delegates part of their constituency away when using online banking or making credit/debit card purchases as they are indemnified from financial loss due to fraud and so should not be able to increase the risk to the parties that bear the cost of that indemnification.  The browser in those cases should not place the User’s security preferences over the covering entity’s since the User has, in my opinion, sold that part of their constituency in those use cases.  Additional explanation:

US Consumers are not liable if fraud is committed on their bank accounts.  It doesn't matter if the person was tricked into providing all their credentials plus the step-up MFA codes; if any money is lost due to fraud the Bank by law must replace the funds.  Since the bank incurs the damages, then if the bank believes the likelihood of that risk increases when the browser saves or autofills credentials, it should be able to control that aspect of the experience.  I think the User has transferred their constituency to the bank websites for any setting that pertains to the security of that session (provided the user is not exposed to non-subjective weaker controls – meaning it’s subjective whether password managers make for better security, but it’s not subjective that using a weaker encryption key weakens the encryption – so the site couldn’t lower the browser’s key or encryption requirements).

Similarly, for merchants that take credit/debit card payments, if a consumer's credit or debit card is fraudulently used not only will the consumer not have to pay for the goods or services, but the merchant gets a chargeback - meaning either the transaction is reversed and the merchant never gets paid, or the bank removes the funds from the merchant's account (merchant consent is not required).  Additionally, banks review merchants with excessive chargebacks on a regular basis and can close their account at their discretion.  So the risk to the merchant is significant - loss of product, loss of revenue, loss of ability to accept online card payments, and in some cases it leads to loss of their business.

In most cases I feel very strongly that the user should have complete control of their experience, as it is after all their computer.  But it does not seem fair to let the user disregard or circumvent a website’s desired security when it's the site (the company behind the site) that will incur all the damages.  People, as we all know, will often choose their convenience even if it's at the unfair expense of someone else.  Enabling that without discretion is I think operating with blinders on and not seeing whose rights are actually being infringed.

Thanks,

Nick Staff

On Thursday, December 12, 2013 at 4:54:56 PM UTC-5, Joel Weinberger wrote:

Just an FYI that I sent an email to public-webapps to start a conversation about the autocomplete='off' standard and our intentions of ignoring autocomplete='off' for the Chrome password manager:

http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/1002.html

Opinions and thoughts here are welcome as well.

--Joel

[vbi...@ozolio.com]

I can not believe that after all customer feedbacks this topic is still alive :)  All Google achieved is developers stopped using the built-in 'password' field. Do you understand, that when it comes to web development no one cares about your opinion? The browser should provide an environment and instruments. The decisions like "whether or not browser should auto-fill forms" are up to developer.

[Faizan Akram Dar]

I can't believe this,

Can't google see the number of questions on stack overflow and other sites about disabling this intrusive behaviour. Clearly we don't want you to suggest garbage, autocomplete means nothing for my app where every user input has to be different, it is only bothering with us suggesting crap and visually overlapping the suggestions shown by for example some JS widget (say select2),

As an example see these

https://stackoverflow.com/questions/10938891/disable-form-autofill-in-chrome-without-disabling-autocomplete

https://stackoverflow.com/questions/15738259/disabling-chrome-autofill

When will you start listening to users and stop your intrusive behaviour.

Screw Google