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

Showing 1-28 of 28 messages
PSA: Ignoring autocomplete='off' by default for password fields Joel 2/11/14 3:59 PM
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
Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields James Robinson 2/11/14 4:04 PM
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
Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Peter Kasting 2/11/14 4:05 PM
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.
Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Joel 2/11/14 4:24 PM
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 :-)
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Peter Kasting 2/11/14 4:31 PM
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
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Joel 2/11/14 4:34 PM



Fair enough; it won't be in there for the long term, then :-) (This is the first flag I've launched.) 

PK

Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/11/14 11:24 PM


PhistucK


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

Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Peter Kasting 2/12/14 1:41 AM
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 
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/12/14 2:02 AM
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
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Richard 2/12/14 3:00 AM
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 :)
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/12/14 3:08 AM
I have. I got no response -
Disable hyperlink auditing Mac, Windows, Linux, Chrome OS, Android
Disable sending hyperlink auditing pings. #disable-hyperlink-auditing


PhistucK
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Richard 2/12/14 3:17 AM
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 :)
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/12/14 3:28 AM
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
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/12/14 11:12 AM
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
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Rachel Blum 2/12/14 12:14 PM
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
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Peter Kasting 2/12/14 1:22 PM
PhistucK, would you be willing to file a bug about the issues you see?  Then we can proceed there.

PK
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Antoine Labour 2/12/14 1:32 PM



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

Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Nicolas Zea 2/12/14 2:11 PM
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.

Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields Peter Beverloo 2/13/14 2:55 AM
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

Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/13/14 3:10 AM
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
Re: [chromium-dev] Re: [blink-dev] PSA: Ignoring autocomplete='off' by default for password fields PhistucK 2/14/14 10:08 AM
Done. An issue for removing the flags that includes a much larger list of flags -

Also, do note crbug.com/343921.


PhistucK
Re: PSA: Ignoring autocomplete='off' by default for password fields Evan Jones 2/19/14 5:54 PM
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
Re: PSA: Ignoring autocomplete='off' by default for password fields Joel 2/19/14 5:57 PM



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

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



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

Re: PSA: Ignoring autocomplete='off' by default for password fields Evan Jones 2/19/14 6:04 PM
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/

Frank Tate 3/8/14 3:26 PM <This message has been deleted.>
Re: PSA: Ignoring autocomplete='off' by default for password fields Alan Pinstein 4/22/14 9:18 PM
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:
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
Re: [chromium-dev] Re: PSA: Ignoring autocomplete='off' by default for password fields Garrett Casto 4/23/14 11:34 AM



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

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

Re: [chromium-dev] PSA: Ignoring autocomplete='off' by default for password fields Alan Pinstein 4/23/14 2:48 PM
Awesome, thank you. Will re-post the relevant bit to the bug report.

Alan
More topics »