To unsubscribe from this group and stop receiving emails from it, send an email to security-dev...@chromium.org.
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.☆PhistucKOn 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.
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).
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.
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...
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.
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.
If Microsoft decided to try anything like this people would be up in arms about it!!!
<sarcasm>So, way to go guys!! *Claps*</sarcasm>
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!!!
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.
Hey, google folks - this is not a feature. This is a BUG.
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
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
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
--
You received this message because you are subscribed to the Google Groups "Security-dev" group.
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.
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.htmlOpinions and thoughts here are welcome as well.--Joel