Code: Select all
<input autocomplete="off" id="Password" maxlength="50" name="Password" style="width:180px" type="password" value="" />
Code: Select all
<input autocomplete="off" id="Password" maxlength="50" name="Password" style="width:180px" type="password" value="" />
From [1], note:I think some people out there somewhere might think regular form autocomplete is the risk they're trying to avoid with 'autocomplete="off"'. That's theoretically a valid concern, but password fields should already not be covered by regular form autocomplete in any sane browser. This flag exists to prevent autocomplete from remembering SSNs, credit card numbers, encryption/login keys, and other sensitive information that would otherwise be automatically remembered. It doesn't appear to have been created to give pages the ability to override an *opt-in* feature of the user's browser.
There's really no reason to consider the password manager to be "autocomplete" in this respect. It is an opt-in feature that won't be automatically completing anything unless the user explicitly asks it to do so for the specific site. The spec [1] doesn't actually recommend the password manager be overridden here. It's all about the form field autocomplete features, including different types of fields, what data they have and should be remembered and auto-filled for them. If form autocomplete and the password manager are considered two separate features, then there's no reason for the password manager to be affected by this flag at all.
[1] http://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute
A user agent may allow the user to override an element's autofill field name, e.g. to change it from "off" to "on" to allow values to be remembered and prefilled despite the page author's objections, or to always "off", never remembering values.
The standards aren't being ignored. The allowed exception to the application of autocomplete=off is being properly applied in accordance with the draft. I may not have worded myself perfectly when I said that "it's negotiable" - I meant that there is no hard and fast rule that everyone has to adhere to all standards at all times, and there is no requirement that every client adheres to all points of a standard. That can be considered a recommended improvement, but in this case it doesn't apply since the standard is followed.LoveNewBrowser wrote:why have standards when the world thinks it is perfectly fine to ignore them?
I would expect shared environment browsers to be properly configured to disable a password manager or storage of private data for its users. Even so, it would most certainly not the browser's fault for applying this rule, nor to blame for both the shared computer admin and the computer user in question not following proper practice (and both being allowed to opt-in and in fact opting in to saving credentials). You can't blame the program for human error.LoveNewBrowser wrote:in this case I took that line off a site that is likely to be used from browsers running on shared environments. Think public library although in my case that is not the most likely scenario. Sure, we can all blame the dumb user to always just click Yes for everything (something they got groomed to do with long EULAs and multipage install wizards), but this browser behavior negates a quite useful feature.
Pale Moon doesn't. Pale Moon asks you - it's never stored (and therefore used) automatically by default.jumba wrote:I understand when bank sites do not want to let users to store passwords by default.
That can be easily fixed by application design forcing the use of strong(er) passwords. I can fix that from a developer point...the ignoring of the autocomplete=off cannot be fixed by the dev.Moonchild wrote:There's a flipside as well to this whole thing: not allowing users to store passwords is a security issue in itself.
If people are forced to always type in passwords, they are very likely going to gravitate towards using short, (very) weak passwords. In what way would that ever be a good thing?
Switch off the password manager (globally or just for that site).LoveNewBrowser wrote:OK, proceeded with my tests and I kinda can see the user benefit for a Login page. BUT, I am currently crawling through a page that is used for adding new user accounts and the admin has a means to specify the initial password. That page, too, has the autocomplete set to off, but the password manager has no idea that this is not a login page and duly asks to save the password.
In this context ignoring the autocomplete attribute makes even less sense and is utterly annoying because why would I want to save the password for a different user account just because I add an account?
MozCo wrote:RESOLVED WONTFIX
I will use that as a defence when asked why our systems are not properly protected. Well, sir, some other developer thought it is nonsense to adhere with the explicit requests provided in my page code, that is why users are prodded to using password managers within the browser even in shared environments. Yes, sir, I know, secure OS do not have password managers for logins either.....all I can say is that I tried.mattatobin wrote:This type of nonsense....
Actually, Pale Moon is doing exactly what you ask: it asks the user to enable password management for a site "remember password for this site?". So what is the problem? It's opt-in. It's not automatic.but the default is to automatically provide the password manager services rather than the user stating that for this site enable password management