PSA: Ignoring autocomplete='off' by default for password fields

18,347 views
Skip to first unread message

Joel Weinberger

unread,
Feb 11, 2014, 6:59:39 PM2/11/14
to blink-dev, chromium-dev, security-dev
It's been in Canary for a few days now, but I wanted to give a heads up that now, by default, Chrome ignores autocomplete='off' for password fields. This allows the password manager to give more power to users to manage their credentials on websites. It is the security team's view that this is very important for user security by allowing users to have unique and more complex passwords for websites. This does not affect non-password fields. If you'd like to re-enable autocomplete='off' for password fields, there is a "--disable-ignore-autocomplete-off" flag available.

See https://crbug.com/177288 for more information on this decision.
--Joel

James Robinson

unread,
Feb 11, 2014, 7:04:04 PM2/11/14
to Joel Weinberger, blink-dev, chromium-dev, security-dev
That bug does not appear to be publicly available.  Could you make it so or provide a link to a place that is publicly available?

- James

Peter Kasting

unread,
Feb 11, 2014, 7:05:19 PM2/11/14
to Joel Weinberger, blink-dev, chromium-dev, security-dev
Thank you so much for this!  autocomplete=off is so user-hostile I wrote an extension around the time of Chrome's original launch to disable it.  I've wanted something like this in Chrome for years and am happy to finally see it happen.

PK

P.S. I hope the intent is to remove the flag in several versions once we're confident we've worked the bugs out of things and aren't going to return to the old behavior.

Joel Weinberger

unread,
Feb 11, 2014, 7:24:05 PM2/11/14
to blink-dev, chromium-dev, security-dev
Sorry for the restricted bug. Unfortunately, we cannot unrestrict that bug yet, and there is no other similar bug. However, there were several earlier public discussions about it. This security-dev email thread might be a good place to start.


On Tue, Feb 11, 2014 at 4:05 PM, Peter Kasting <pkas...@google.com> wrote:
Thank you so much for this!  autocomplete=off is so user-hostile I wrote an extension around the time of Chrome's original launch to disable it.  I've wanted something like this in Chrome for years and am happy to finally see it happen. 
I'm with ya on that one. 

PK

P.S. I hope the intent is to remove the flag in several versions once we're confident we've worked the bugs out of things and aren't going to return to the old behavior.
That hasn't really been discussed yet. I think there is a chance we'll leave it as there are some users who really don't want their passwords memorized by Chrome on autocomplete='off' sites (people on corporate intranets come to mind here), but again, we haven't really gone over it yet. Thoughts welcome :-)

Peter Kasting

unread,
Feb 11, 2014, 7:31:33 PM2/11/14
to Joel Weinberger, blink-dev, chromium-dev, security-dev
On Tue, Feb 11, 2014 at 4:24 PM, Joel Weinberger <j...@chromium.org> wrote:
On Tue, Feb 11, 2014 at 4:05 PM, Peter Kasting <pkas...@google.com> wrote:
P.S. I hope the intent is to remove the flag in several versions once we're confident we've worked the bugs out of things and aren't going to return to the old behavior.
That hasn't really been discussed yet. I think there is a chance we'll leave it as there are some users who really don't want their passwords memorized by Chrome on autocomplete='off' sites (people on corporate intranets come to mind here), but again, we haven't really gone over it yet. Thoughts welcome :-)

Chrome policy is not to provide longstanding flags except for critical low-level debugging features, e.g. single-process mode.  If we decide we have a legitimate user need to toggle this behavior, it needs to be exposed in our UI somewhere, e.g. in chrome://settings/autofill , or be surfaced as an extension API.  Otherwise it simply shouldn't exist at all.

A flag is of course totally appropriate for brand-new behaviors where we may need to flip the default state in response to some bug cropping up in the wild.  It just isn't the right long-term control.

PK

Joel Weinberger

unread,
Feb 11, 2014, 7:34:59 PM2/11/14
to Peter Kasting, blink-dev, chromium-dev, security-dev
Fair enough; it won't be in there for the long term, then :-) (This is the first flag I've launched.) 

PK

PhistucK

unread,
Feb 12, 2014, 2:24:01 AM2/12/14
to Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev


PhistucK


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

Peter Kasting

unread,
Feb 12, 2014, 4:41:30 AM2/12/14
to PhistucK, Joel Weinberger, blink-dev, chromium-dev, security-dev
On Tue, Feb 11, 2014 at 11:24 PM, PhistucK <phis...@gmail.com> wrote:
Who is enforcing this policy?

It has been periodically mailed out to this list (several times over the life of the project) and as with basically all Chrome policies, is enforced ad-hoc by individual project members who are expected to Do The Right Thing, which is precisely why I do things like raise the issue on email threads (since said developers probably don't remember all these policies).

PK 

PhistucK

unread,
Feb 12, 2014, 5:02:30 AM2/12/14
to Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
Well, then it is not really being enforced. There are a lot of flags that should be removed.

Nevermind, this is off topic anyway.


PhistucK

Torne (Richard Coles)

unread,
Feb 12, 2014, 6:00:56 AM2/12/14
to PhistucK, Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
If you have examples of flags that aren't for test/debug purposes and are not for features currently under development, or experiments that may still be running, then let people know :)

PhistucK

unread,
Feb 12, 2014, 6:08:28 AM2/12/14
to Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
I have. I got no response -
Disable hyperlink auditing Mac, Windows, Linux, Chrome OS, Android
Disable sending hyperlink auditing pings. #disable-hyperlink-auditing


PhistucK

Torne (Richard Coles)

unread,
Feb 12, 2014, 6:17:19 AM2/12/14
to PhistucK, Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
Well, I don't know anything about that one, but if you can only think of one example from the massive list over on Peter's site then I'd say we're doing quite well :)

PhistucK

unread,
Feb 12, 2014, 6:28:59 AM2/12/14
to Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
I have not gone through the list today, the one I mentioned was something I happened to notice a few weeks ago and sent an e-mail to which I got no reply.

I will try and go through the list in the coming days and reply with the results.


PhistucK

PhistucK

unread,
Feb 12, 2014, 2:12:45 PM2/12/14
to Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
Turns out the command line switch list on peter.sh is no longer kept up to date.

All of these exist in about:flags. The names are the anchor names in about:flags, so #disable-hyperlink-auditing is about:flags#disable-hyperlink-auditing.

Should either be a visible setting, or removed -
#disable-hyperlink-auditing

Features that were never by default and exist for quite a while -
#purge-memory-button
#expose-for-tabs
#enable-autologin
#enable-spelling-service-feedback
#tab-groups-context-menu
#script-badges
#save-page-as-mhtml
#stacked-tab-strip (or maybe it is enabled by default for touch based user interfaces?)

Experiments that are getting old -
#views-textfield
#enable-async-dns
#fixed-position-creates-stacking-context

Features that seem to be enabled by default for a while (or a long time) -
#disable-device-enumeration
#disable-full-history-sync
#disable-overview-mode
#disable-ntp-other-sessions-menu
#disable-restore-session-state
#enable-panels (for certain platforms, anyway)

Note - lots of Chrome Sync related flags (enable-x and disable-x) exist as well. Do we really need to control features that have been enabled for a long, long time (and that could be disabled by not synchronizing the feature, I guess)?


Next - going through the actual switch files instead of only about:flags.


PhistucK

Rachel Blum

unread,
Feb 12, 2014, 3:14:11 PM2/12/14
to PhistucK, Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev, Rouslan Solomakhin
Spelling service feedback is enabled by default. What the switch does is enable a different feedback API, which requires user consent for various reasons. It _shouldn't_ be on except for very specific users. There are still minor discussions around it, but I expect this to vanish sooner or later. See http://crbug.com/247726


But overall, thank you for going through the list of switches. I wonder if there's value in a quarterly switch reminder. :)

 - rachel

Peter Kasting

unread,
Feb 12, 2014, 4:22:53 PM2/12/14
to PhistucK, Torne (Richard Coles), Joel Weinberger, blink-dev, chromium-dev, security-dev
PhistucK, would you be willing to file a bug about the issues you see?  Then we can proceed there.

PK

Antoine Labour

unread,
Feb 12, 2014, 4:32:05 PM2/12/14
to PhistucK, Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
On Wed, Feb 12, 2014 at 11:12 AM, PhistucK <phis...@gmail.com> wrote:
Turns out the command line switch list on peter.sh is no longer kept up to date.

All of these exist in about:flags. The names are the anchor names in about:flags, so #disable-hyperlink-auditing is about:flags#disable-hyperlink-auditing.

Should either be a visible setting, or removed -
#disable-hyperlink-auditing

Features that were never by default and exist for quite a while -
#purge-memory-button
#expose-for-tabs


Antoine

Nicolas Zea

unread,
Feb 12, 2014, 5:11:37 PM2/12/14
to phis...@gmail.com, Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
On Wed, Feb 12, 2014 at 11:12 AM, PhistucK <phis...@gmail.com> wrote:
We've historically had those around because Sync starts up when the browser starts up, and if there's a crash in the sync code, often the easiest way to work around/debug it is to disable the associated sync datatype (or sync altogether) via a flag. That said, this made more sense back when there were 5 sync datatypes. We should clean it up at this point. I'll file a bug for that.
 


Next - going through the actual switch files instead of only about:flags.


PhistucK


On Wed, Feb 12, 2014 at 1:28 PM, PhistucK <phis...@gmail.com> wrote:
I have not gone through the list today, the one I mentioned was something I happened to notice a few weeks ago and sent an e-mail to which I got no reply.

I will try and go through the list in the coming days and reply with the results.


PhistucK


On Wed, Feb 12, 2014 at 1:17 PM, Torne (Richard Coles) <to...@chromium.org> wrote:
Well, I don't know anything about that one, but if you can only think of one example from the massive list over on Peter's site then I'd say we're doing quite well :)


On 12 February 2014 11:08, PhistucK <phis...@gmail.com> wrote:
I have. I got no response -
Disable hyperlink auditing Mac, Windows, Linux, Chrome OS, Android
Disable sending hyperlink auditing pings. #disable-hyperlink-auditing


PhistucK


On Wed, Feb 12, 2014 at 1:00 PM, Torne (Richard Coles) <to...@chromium.org> wrote:
If you have examples of flags that aren't for test/debug purposes and are not for features currently under development, or experiments that may still be running, then let people know :)


On 12 February 2014 10:02, PhistucK <phis...@gmail.com> wrote:
Well, then it is not really being enforced. There are a lot of flags that should be removed.

Nevermind, this is off topic anyway.


PhistucK


On Wed, Feb 12, 2014 at 11:41 AM, Peter Kasting <pkas...@chromium.org> wrote:
On Tue, Feb 11, 2014 at 11:24 PM, PhistucK <phis...@gmail.com> wrote:
Who is enforcing this policy?

It has been periodically mailed out to this list (several times over the life of the project) and as with basically all Chrome policies, is enforced ad-hoc by individual project members who are expected to Do The Right Thing, which is precisely why I do things like raise the issue on email threads (since said developers probably don't remember all these policies).

PK 






--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

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

Peter Beverloo

unread,
Feb 13, 2014, 5:55:13 AM2/13/14
to PhistucK, Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
On Wed, Feb 12, 2014 at 7:12 PM, PhistucK <phis...@gmail.com> wrote:
Turns out the command line switch list on peter.sh is no longer kept up to date.

How did you conclude that?  The list is perfectly up to date.  If the system breaks it starts nagging me with two e-mails per day, which is a good incentive for me to fix it quickly :-).

When hovering over a row, a small arrow will appear at the end of the flag's description.  You can click on this arrow to open the source file it's defined in.  Also, keep in mind that some of the entries in about:flags aren't unique flags on their own.  For example, the #expose-for-tabs about:flags entry maps to the "--enable-expose-for-tabs" command line flag.

Thanks for doing this, PhistucK!

Thanks,
Peter

PhistucK

unread,
Feb 13, 2014, 6:10:11 AM2/13/14
to Peter Beverloo, Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
There was something weird yesterday then... the page listed --user-scripts-dir and I could not find such flag in the sources (using cs.chromium.org).
(I did not have a ?date=... parameter, so it is supposed to be the current version)
Also, the arrow that shows up when you hover the description of the switch went to the wrong URL (chromium/srcsrc/... instead of chromium/src/...).

It looks fine now and --user-scripts-dir is not longer listed.

The "generated JSON data" link leads to a file with no data, though. It still happens now and it also happened yesterday, so I assumed something is wrong.

Thank you for the great page!

By the way, the wording (and the linked source code) on the page seems outdated, since you are processing much more than just chrome_switches.cc.

I am sorry for the false accusation! ;)


PhistucK

PhistucK

unread,
Feb 14, 2014, 1:08:18 PM2/14/14
to Peter Beverloo, Torne (Richard Coles), Peter Kasting, Joel Weinberger, blink-dev, chromium-dev, security-dev
Done. An issue for removing the flags that includes a much larger list of flags -

Also, do note crbug.com/343921.


PhistucK

Evan Jones

unread,
Feb 19, 2014, 8:54:06 PM2/19/14
to chromi...@chromium.org, blink-dev, security-dev
My apologies for not finding this thread earlier. I make a third-party password manager: https://www.mitro.co/ . Is there anything I can do as an extension author to disable Chrome's password manager, beyond showing my users how to do it themselves in the preferences?

Not that it matters, but I totally think this is the right decision for most users. In our case, where we manage shared credentials for teams, its going to be a common support request. Thanks!

Evan Jones

Joel Weinberger

unread,
Feb 19, 2014, 8:57:47 PM2/19/14
to Evan Jones, chromium-dev, blink-dev, security-dev, mea...@chromium.org
On Wed, Feb 19, 2014 at 5:54 PM, Evan Jones <e...@evanjones.ca> wrote:
My apologies for not finding this thread earlier. I make a third-party password manager: https://www.mitro.co/ . Is there anything I can do as an extension author to disable Chrome's password manager, beyond showing my users how to do it themselves in the preferences?
I'm pretty sure the answer is "no." You might consider filing a feature request for an extension permission that lets you do that, though. I could be mistaken, though, so meacer, correct me if I'm wrong.
--Joel

Evan Jones

unread,
Feb 19, 2014, 9:04:29 PM2/19/14
to Joel Weinberger, chromium-dev, blink-dev, security-dev, mea...@chromium.org
On Feb 19, 2014, at 20:57 , Joel Weinberger <j...@chromium.org> wrote:
> I'm pretty sure the answer is "no." You might consider filing a feature request for an extension permission that lets you do that, though. I could be mistaken, though, so meacer, correct me if I'm wrong.

I'll ask on chromium-extensions and bug my contacts on the Chrome team. Thanks,

Evan

--
Work: https://www.mitro.co/ Personal: http://evanjones.ca/

Message has been deleted

Alan Pinstein

unread,
Apr 23, 2014, 12:18:10 AM4/23/14
to chromi...@chromium.org, blink-dev, security-dev
While I applaud and agree with the move to ignore autocomplete=off for password fields, IMO there is a bug in the implementation that causes problems on many web sites. We have already had a lot of customers report this behavior as a bug in our site, and I am sure we're not alone.

It seems that whenever Chrome 34 sees a password field, it attempts to figure out where to fill in a user/pass. However it also does this on a "change password" form. If such a form is on a page with other things, it typically causes 2 problems:
  1. It will autofill a username somewhere, but not always in the actual username field (which in the case of a change password form, might not even exist). This has the terrible side-effect of putting a username in an otherwise empty field which was intentionally left blank by the user. This can cause validation errors on the form and confuse the end user.
  2. It will fill in only one of the two password & confirm password fields, causing a "passwords don't match" validation failure when the form is submitted.
I found a way (actually someone on Stack Overflow did) to thwart this behavior by inserting the following before the password field:

<input type="text" style="display:none" /><input type="password" style="display:none"/>

However this feels dirty.

I had to deal with this issue recently for Safari, and I discovered that Safari will *not* autofill user/pass info when it sees 2 password fields. So while I had to change the web site to ensure that all "change password" forms had 2 password fields, this seemed like a good idea anyway and didn't seem like a terrible hack around an autocomplete bug.

Just my 2c but I think improvements to the Chrome user/pass autofill approach will save a lot of web developers and site users a ton of time and frustration.

Regards,
Alan

On Tuesday, February 11, 2014 6:59:39 PM UTC-5, Joel Weinberger wrote:

Garrett Casto

unread,
Apr 23, 2014, 2:34:39 PM4/23/14
to apin...@mac.com, chromium-dev, blink-dev, security-dev
On Tue, Apr 22, 2014 at 9:18 PM, Alan Pinstein <apin...@mac.com> wrote:
While I applaud and agree with the move to ignore autocomplete=off for password fields, IMO there is a bug in the implementation that causes problems on many web sites. We have already had a lot of customers report this behavior as a bug in our site, and I am sure we're not alone.

It seems that whenever Chrome 34 sees a password field, it attempts to figure out where to fill in a user/pass. However it also does this on a "change password" form. If such a form is on a page with other things, it typically causes 2 problems:
  1. It will autofill a username somewhere, but not always in the actual username field (which in the case of a change password form, might not even exist). This has the terrible side-effect of putting a username in an otherwise empty field which was intentionally left blank by the user. This can cause validation errors on the form and confuse the end user.
  2. It will fill in only one of the two password & confirm password fields, causing a "passwords don't match" validation failure when the form is submitted.
I found a way (actually someone on Stack Overflow did) to thwart this behavior by inserting the following before the password field:

<input type="text" style="display:none" /><input type="password" style="display:none"/>

However this feels dirty.

I had to deal with this issue recently for Safari, and I discovered that Safari will *not* autofill user/pass info when it sees 2 password fields. So while I had to change the web site to ensure that all "change password" forms had 2 password fields, this seemed like a good idea anyway and didn't seem like a terrible hack around an autocomplete bug.

Just my 2c but I think improvements to the Chrome user/pass autofill approach will save a lot of web developers and site users a ton of time and frustration.


We already have a bug for this (crbug.com/352347) and someone should be dealing with it shortly. Thanks for your input.
 
Regards,
Alan

On Tuesday, February 11, 2014 6:59:39 PM UTC-5, Joel Weinberger wrote:
It's been in Canary for a few days now, but I wanted to give a heads up that now, by default, Chrome ignores autocomplete='off' for password fields. This allows the password manager to give more power to users to manage their credentials on websites. It is the security team's view that this is very important for user security by allowing users to have unique and more complex passwords for websites. This does not affect non-password fields. If you'd like to re-enable autocomplete='off' for password fields, there is a "--disable-ignore-autocomplete-off" flag available.

See https://crbug.com/177288 for more information on this decision.
--Joel

--

Alan Pinstein

unread,
Apr 23, 2014, 5:48:35 PM4/23/14
to Garrett Casto, chromium-dev, blink-dev, security-dev
Awesome, thank you. Will re-post the relevant bit to the bug report.

Alan

On Apr 23, 2014, at 2:33 PM, Garrett Casto <gca...@google.com> wrote:

On Tue, Apr 22, 2014 at 9:18 PM, Alan Pinstein <apin...@mac.com> wrote:
While I applaud and agree with the move to ignore autocomplete=off for password fields, IMO there is a bug in the implementation that causes problems on many web sites. We have already had a lot of customers report this behavior as a bug in our site, and I am sure we're not alone.

It seems that whenever Chrome 34 sees a password field, it attempts to figure out where to fill in a user/pass. However it also does this on a "change password" form. If such a form is on a page with other things, it typically causes 2 problems:
  1. It will autofill a username somewhere, but not always in the actual username field (which in the case of a change password form, might not even exist). This has the terrible side-effect of putting a username in an otherwise empty field which was intentionally left blank by the user. This can cause validation errors on the form and confuse the end user.
  2. It will fill in only one of the two password & confirm password fields, causing a "passwords don't match" validation failure when the form is submitted.
I found a way (actually someone on Stack Overflow did) to thwart this behavior by inserting the following before the password field:

<input type="text" style="display:none" /><input type="password" style="display:none"/>

However this feels dirty.

I had to deal with this issue recently for Safari, and I discovered that Safari will *not* autofill user/pass info when it sees 2 password fields. So while I had to change the web site to ensure that all "change password" forms had 2 password fields, this seemed like a good idea anyway and didn't seem like a terrible hack around an autocomplete bug.

Just my 2c but I think improvements to the Chrome user/pass autofill approach will save a lot of web developers and site users a ton of time and frustration.


We already have a bug for this (crbug.com/352347) and someone should be dealing with it shortly. Thanks for your input.
 
Regards,
Alan

On Tuesday, February 11, 2014 6:59:39 PM UTC-5, Joel Weinberger wrote:
It's been in Canary for a few days now, but I wanted to give a heads up that now, by default, Chrome ignores autocomplete='off' for password fields. This allows the password manager to give more power to users to manage their credentials on websites. It is the security team's view that this is very important for user security by allowing users to have unique and more complex passwords for websites. This does not affect non-password fields. If you'd like to re-enable autocomplete='off' for password fields, there is a "--disable-ignore-autocomplete-off" flag available.

See https://crbug.com/177288 for more information on this decision.
--Joel

Nick Staff

unread,
Mar 8, 2020, 5:18:33 PM3/8/20
to Chromium-dev, blin...@chromium.org, securi...@chromium.org
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 (whether or not autofill of passwords increases the risk should be left up to the bearer of the risk).  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 Liberty is actually being violated.

Thanks,
Nick Staff
Reply all
Reply to author
Forward
0 new messages