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.
PKP.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.
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 :-)
PK
To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
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-auditingFeatures that were never by default and exist for quite a while -#purge-memory-button#expose-for-tabs
Next - going through the actual switch files instead of only about:flags.☆PhistucKOn 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.☆PhistucKOn 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, AndroidDisable sending hyperlink auditing pings. #disable-hyperlink-auditing
☆PhistucKOn 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.☆PhistucKOn Wed, Feb 12, 2014 at 11:41 AM, Peter Kasting <pkas...@chromium.org> wrote: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.
Turns out the command line switch list on peter.sh is no longer kept up to date.
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?
<input type="text" style="display:none" /><input type="password" style="display:none"/>
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:
- 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.
- 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
--
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:
- 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.
- 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