Closed Bug 245333 Opened 19 years ago Closed 10 years ago

support pref to ignore autocomplete=off (when passwords are encrypted?)

Categories

(Toolkit :: Password Manager, enhancement)

Product:
Toolkit
Component:
Password Manager
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 425145

People

(Reporter: asmozilla2, Unassigned)

References

Details

Attachments

(1 file)

Adds an about:config option to ignore autocomplete=off
1.54 KB, patch
smaug
: review-
Details | Diff | Splinter Review 
It's really anoying that on some websites mozilla won't save the password. I
discovered that it's because of autocomplete=off - well it's none of the web
authors business if I want to save a password or not.

I can understand if for automatically saved stuff, but mozilla always asks with
regard to passwords, and therefor should completely ignore that.

Perhaps make a warning? Perhaps save only if passwords are encrypted? (I can see
no harm at all in that case.) Or at the very least please provide a pref for this.
Sorry, my bad. I found it: wallet.crypto.autocompleteoverride

I suppose this could be termed as a request to make this option a little easier
to find. I only found it because I was going to attempt a binary edit of mozilla
to make it not notice the word "autocomplete" and this pref popped up in the grep.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
I thought we had an RFE on this already, but I couldn't find it.

wallet.crypto.autocompleteoverride used to only work if the passwords were
encrypted, and in that case changing the default for this pref would be pretty
safe. But it looks like the pref now works regardless of whether the passwords
are encrypted or not (bug 154825), and in that case changing the default will
get us into trouble again. See bug 63961 for a partial history of how we were
essentially forced to support autocomplete=off (it wasn't just the one bank
named in that bug).
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The report doesn't say if it is about mozilla or firefox. afaik, firefox always
encrypts. I don't know about it's logic to ignore autocomplete=off
This does not seem to work in current Firefox. Works great in Seamonkey.
Firefox has a completely separate form-fill/password manager system, changing
Product (I'm surprised though, I thought someone said they never honor the
autocomplete attribute regardless of pref setting).

The reporter could name the site(s) at which he's having problems, it may in
fact have nothing to do with autocomplete and instead be something getting
fooled in the code that recognizes password forms.
Product: Browser → Firefox
Version: Trunk → unspecified
Assignee: dveditz → bryner
Status: REOPENED → NEW
QA Contact: davidpjames
tweaking summary.  I think we need to treat carefully here, and possibly feel
out a number of large banks on the implications of such a pref.  I don't know
how many people are aware of the wallet pref, but as we grow marketshare it will
invite controversy at some point.  We've made huge strides in being accepted by
the online banking players, I'd hate to blow it over something as small as this.
Summary: remember passwords even if autocomplete=off → support pref to ignore autocomplete=off
I remember that banks were very strict about this, so, to spell it out a bit
more clearly: most banks in this conversation test down to the version number.
They expect browsers to respect a certain level of security, and if the browser
is not working properly, they will block that specific version because it is
untrusted.

I was not aware that this option existed. I don't know what their reaction to
the existence of this pref would be, but we shouldn't expose this in the UI. 
bug 249035 seams similar promlem (for Suite.)
Bug #271039 has been opened as an official feature request for this item. Please
be sure to vote for the bug.

*** Bug 271039 has been marked as a duplicate of this bug. ***
This is already an enhancement request, filing another bug is inappropriate.
I don't believe a global pref is a fine enough granularity here. Just because I
want site X which is poorly designed and needlessly uses autocomplete="off"
doesn't mean I want my password showing up for bankofamerica.com. The only safe
solution is to add per-site settings. I believe any fix for this bug is needless
complexity, and as such it should be WONTFIX. 
(In reply to comment #12)
Ben, well since this method has already been defined (mozilla) then in some sense you are asking for a 
change to  in the first place mozilla, and then feature parity with firefox. But as it stands now. FF isnt on 
parity with Moz.

(In reply to comment #11)
> This is already an enhancement request, filing another bug is inappropriate.

Looked like this bug was stagnating, though I will admit in my eagerness to
tackle the issue I should have reviewed this bug more closely.

Original comments from Bug #271039 still stand, as far as I'm concerned.
While I agree with Ben's statement about granularity, the problem is this is a
"hidden" preference, not something in the UI and not highly visible in standard
documentation. Obviously there is still the concern about financial institutes
boycotting the browser, so doing something to raise the awareness of this
preference would run counter to that concern.

I for one think that should no longer be as much concern for the browsers. When
Bug #63961 was filed it was early 2001, many months before the Enron scandal
broke and they went Chapter 11. MCI/Worldcom didn't start to implode until
mid-2002. GLB, HIPPA, SarbOx and all the other "Responsibility" legislations
either didn't exist or had not yet gone into enforcement.

Financial institutes threatening to boycott the browser should, as a whole, be
reconsidered in these different times.

However, regardless of the politics and not-so-humble opinions expressed here,
the main reason "wallet.crypto.autocompleteoverride" should be supported in
FireFox is because of migration support for users of older versions of Mozilla,
Firebird, Phoenix, etc etc... Complications arise for the end-user when they
migrate from Mozilla with the preference enabled to Firefox which does not
support the preference (see Bug #271038).

Anything further than that should probably be addressed as a new feature
request. Frankly, since the password manager already allows the end user to
selectively choose what sites to save passwords for, additional granularity for
this hidden pref is frankly redundant.

*** Bug 245779 has been marked as a duplicate of this bug. ***
Hardware: PC → All
Blocks: 282123
No longer blocks: 282123
Financial institutions don't trust local security for users, so your average
dummy-with-a-trojan is vulnerable here.  Risk/reward just isn't here to do it right.

WONTFIX.
Status: NEW → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
Is there a bug for doing it right? Or are we just wontfixing with no intention
of doing it right, ever?
>Financial institutions don't trust local security for users, so your average
>dummy-with-a-trojan is vulnerable here.  Risk/reward just isn't here to do it
>right.
>WONTFIX.

Your average financial institute thinks a website with a 1024-bit cert, some
flash Verisign "seals" and a single username/password combo is secure. These are
the same financial institutes that have repeatedly had customer data STOLEN,
usually thanks to some idiot getting his laptop stolen.

I'll repeat: Do not listen to corporate thugs. They know **** about security.
Just because it's a bank does not make them experts in security. Banks get
ripped off all the time.

You want secure? Force routine password changes every 90 days. Require strong
passwords of 8 to 256 characters with at least one digit and one punctuation
mark. Use two-factor authentication. Require biometric authentication.

But these things will not happen because they aren't "convenient" for the customers.

And your trojan argument is pure ****. if some "dummy-with-a-tojan" goes to
a bank site, IT DOESN'T MATTER WHERE THE PASSWORD IS STORED! A trojaned system
will undoubtedly have a keylogger.


While I agree with comment 19 and wish this bug would get fixed to allow the
user to have control, I understand the larger intent of WONTFIXing this.
Currently, Firefox is still the minor player (despite being the # 2 browser) and
must take steps to avoid negative reaction from institutions and indviduals if
they don't go strongly against core fundamental beliefs. As Mozilla based
products are far from the majority, it can't afford major rejection from groups
such as financial institutions in this current growth period. I think the best
hope for this item is unofficial / no mozilla.org pages / add-ons that allow
this functionality. If it is sufficiently disparate from being part of the
browser and mozilla.org created, then the institutions likely won't have a
negative reaction.
IMO the key question is:

 Would having a non-UI pref to ignore "autocomplete=off" upset these institutions?

Being a hidden pref warrants no newbie will have his password saved by default.

Why don't we have this hidden pref added and stay alert for any negative opinion?

I personally agree with Comment #12. 

Giving major institutions any reason to blacklist Gecko UAs is a bad thing.
Ideally nobody would care and the annoyance autocomplete=off creates could be
easily pref'ed away, but, this isn't where we are. If Firefox (or any
Gecko/Mozilla-based product), is to succeed, it needs the support of major sites
that end-users are going to use. If banks, etc, blacklist gecko, then those
users are forced, likely, back to IE (or an older version of Firefox, etc) which
isn't a situation we want to create at all. The benefit of supporting this pref,
as minor as it is, hurts Gecko in the long run.
I read all the objections and therefore I'm changing the description of the
request and reopening it.

Now all I'm asking for is when stored passwords are encrypted, then, and only
then, ignore autocomplete=off

Even with all the senarios listed here I can't see any risk in this case.

Obviously lots of people would prefer if it was always ignored (see the votes!),
but for me ignoring autocomplete=off only when passwords are encrypted is good
enough, and I think it's a resonable compromize.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Summary: support pref to ignore autocomplete=off → support pref to ignore autocomplete=off when passwords are encrypted
>for me ignoring autocomplete=off only when passwords
>are encrypted is good enough

The problem is that it's not being done for you (or us,) it's being done for the
banks.  The problem wasn't the fact that the passwords were stored on disk
(encrypted or not.)  The problem was that someone could walk up to your
computer, go to whatever bank site, and be able to log in.  The 4 year old
comments in bug 63961,comment 4 are still valid.

Just make yourself an extension.  I did, it took me about 5 minutes, based on
Jesse Ruderman's bookmarklet (which is another way to get around this problem.)
 Or use mine at http://mike.eire.ca/ext/aac.xpi

I'm well aware of the original seamonkey behaviour.  Still not going to happen.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WONTFIX
(In reply to comment #24)
> The problem wasn't the fact that the passwords were stored on disk
> (encrypted or not.)  The problem was that someone could walk up to your
> computer, go to whatever bank site, and be able to log in.

If this can only be activated when a master password is set then this "someone
could walk up to your computer" argument is no longer true. The pref could even
check for an adequate "password expiry time" to be present.

> Just make yourself an extension.  I did, it took me about 5 minutes, based on
> Jesse Ruderman's bookmarklet (which is another way to get around this problem.)
>  Or use mine at http://mike.eire.ca/ext/aac.xpi

How come an extension is different from a hidden pref? Both are modifications an
advanced user can do to its own software to have it do something he wants. I
don't get it. If I follow your logic then no extension should be able to modify
the DOM to remove  "autocomplete=off".

I think people is over-exagerating this whole thing. I don't really think any
bank would block Mozilla because of either an extension or a hiden pref.

Nicolas raises the point I was going to make. Mike, you are being foolish and
seriously risking the integrity of Firefox's future.

This is NOT about a frelling preference. Hell, I got the bookmarklet installed
to  strip "autocomplete=off". People are already doing extensions to do that as
well. Those extensions will become more widely spread over time. I no longer
care about the bug itself. This is about a greater political issue that NEVER
should have been allowed to infect the project in the first place.

Since you have chosen to bow to pressure from corporate entities that DO NOT
have any real authority (other than thug-like threats), you have now opened up
the gates for other wild demands. Who's to say American Express won't threaten
to ban Mozilla/Firefox due to the prevalance of extensions/bookmarklets that
strip autocomplete=0ff? Sure, you can explain to them it's not in the original
code. Do you really believe that an entity willing to threaten bans of the
browser is going to care?

Mozilla's and Firefox's websites have plenty of links to 3rd party extensions
and modifications which change the behavior of the browser. So who's going to
start vetting all these extensions to make sure they don't risk Firefox getting
banned?

And why does everyone think the most important thing is for Firefox to become
the #1 browser? Anyone noticed what happened to the #1 browser? It's a piece of
insecure ****. Guess what folks, cream rises to the top, but so does fat.
Mediocracy dominates in our society and you're not going to see a product become
the most widely used and retain it's quality. I'd MUCH rather see Mozilla and
Firefox remain at #2, and retain their robustness and usefulness.

The appropriate resolution to this issue (if not this bug) is to provide an
option to ignore/obey the "autocomplete=off" option, on a per-site basis. By
default leave it enabled. Document the option, explain the risks. Then when big
bad American Express, Bank of America, Wachovia and others threaten to ban them,
let 'em. Guess what? They'll get their asses fried by complaints from customers!
Customers who prefer using a secure, reliable browser like Firefox or Mozilla.


Flaming me isn't going to advance your case.

The point of the Mozilla project is to drive adoption of web standards and open
up the web to avoid being a monoculture.  We don't care about being #1 in market
share, I don't even want Firefox to become as dominant as IE is today.  I want
an open web where I can choose a browser based on security and features, not by
what sites it works with.  Anything that stands in the way of that requires
pragmatism.  This is a defacto standard that some content providers require
support for, so we're going to honour it.
I am very saddened to see this as wontfix. And as a matter of fact I am going to have to reconsider 
going back to Mozilla. However, Mike, while you yourself are not being inconsistent, the current state of 
affairs make you so. The fact is that mozilla honors this preference. If the goal is to honor a defacto 
standard, then it must therefor be abolished from the entire source tree. Being inconsistent on the 
choice of the user to decide is also wrong. personally believe it is wrong to allow site operators to 
dictate the feature set allowed to the user.

I am reminded of a rather off the wall conversation with someone as to why i block cookies, his 
argument was that the developer must have had a 'good reason' so who cares what i think? Are not 
tracking cookies also a de-facto standard? shouldn't cookie management also be turned off. (subtitled 
for the sarcasm impaired.

You are advocating pragmatism, while also advocate /choosing/ a browser based on security and 
feature. Essentially the choice is now gone, bulldozed by pragmatism. You dont get choice and 
pragmatism. Internally, they are mutually exclusive.
It appears to be Firefox is quite consistent in the matter. Seamonkey chooses
differently which is completely fine. Its a seperate product.

Those who want 100% control over their browsing experience will always conflict
with webdevelopers who wish to retain some of that control. In this case, the
organizations who wished to maintain that control did so on the basis of
security of passwords and account information, which /they/ have an obligation
to ensure, the trust of their customers, who believe they wouldn't offer an
insecure service, that trust extends to browsers allowed, working with browsers
to ensure choice for the customers was a much better solution than blocking
gecko. Pragmatism may have inhibited your choice to store your password in
Firefox easily, but it also ensures you /have/ the ability to still go to that
site and have a browser choice to use. :-)

Cookie management is a weak argument, because cookie implementations have never
(AFAIK, or if that's wrong, at least in no popular browser today) forced cookies
onto the users w/o a choice. Its a give and take, sites that require cookies
ignore user choice, the user must then choose whether or not to deal with such a
site. So must a user deal with the choice for an organization to choose to
require passwords not to be stored.

I think that mconnor's comment #28 is right on. :-) and the "fight the system"
comments here, have no place, being revolutionary and melodramtic doesn't
further Mozilla's goals, it hurts them.
Status: RESOLVED → VERIFIED
Summary: support pref to ignore autocomplete=off when passwords are encrypted → support pref to ignore autocomplete=off (when passwords are encrypted?)
An additional problem is Microsoft Office Outlook Web Access, which is used
by many institutions (e.g., West Chester University, where my wife works:
https://webmail.wcupa.edu/exchweb/bin/auth/usa/logon.asp).
Now this page has a "private computer" option, which you would think might
turn off the function that prevents using password manager, but it apparently
works only with Microsoft's version of JavaScript, if at all.  My wife has
been using the wallet.crypto.autocompleteoverride feature of Mozilla, so that
she does not have to type her name and password every time she checks her mail
from home.  With Firefox, Jesse Ruderman's bookmarklet does the trick.  But,
given that it is already possible to use password manager, it seems odd that
there should be no feature for this in about:config.  Either way, word has to
get out to users of this awful program that they CAN use Firefox with
password manager.  It just seems nicer to me to have it part of Firefox rather
than something you have to get from Ruderman's web page.

As for banks, I was using this for Wachovia for a while (which also erases
passwords) until I was convinced that it was more of a risk than writing down
my password in some obscure place (which I hope I remember).  I think that
that banks are not going to base decisions on whether this feature is in
about:config or in Ruderman's web page.  But I could be wrong.  Call some
and ask?  Should I do it?
Calling some and asking isn't particularly helpful/useful, as we're never going
to get consensus.
*** Bug 309425 has been marked as a duplicate of this bug. ***
I've just filed bug 318667, where I ask for an ability to override autocomplete=off that is (IMHO) much more restricted and limited than the one discussed here. I would really appreciate it if those who have WONTFIX'ed this bug would
seriously consider my proposal and not dismiss it right away. 

Note that not having an override at all may be even worse than having a very limited one, since not having it would force people to invent their own workarounds that would usually be less secure that what Firefox might provide. And personally, I'd rather trust Firefox developers to do it right than rely on some 3rd-party solution.
*** Bug 287347 has been marked as a duplicate of this bug. ***
*** Bug 333557 has been marked as a duplicate of this bug. ***
*** Bug 355063 has been marked as a duplicate of this bug. ***
"The point of the Mozilla project is to drive adoption of DE FACTO MICROSOFT STATED web standards and [...] monoculture."

Let's start displaying ALT attributes too and guessing MIME types!?

I say fix this bug. Or come with some rational answer not to do so.
-Everything- should be an option, that's the beauty of the personal computer. How can anyone even think of restricting the abilities of the OWNER of the computer that firefox is running on? Does anyone realize how ludicrous that sounds? That's like making it illegal to crack your own SAM hive file.. it's your file, who cares if it's encrypted you can do whatever the heck you want on your own computer; there's not even any legal complication of "hacking" since it's just local. So how can some web developer control what I can do in my own browser? If they want to push me content, I'm fine with that of course and even render it the way they expect. But I don't have to. If they want to ask me to consider not saving my passwords, I reserve the right to say "no"! 

This absurd attitude needs to be rooted out of this project and never seen again.
(In reply to comment #38)
> "The point of the Mozilla project is to drive adoption of DE FACTO MICROSOFT
> STATED web standards and [...] monoculture."
> 
> Let's start displaying ALT attributes too and guessing MIME types!?
> 
> I say fix this bug. Or come with some rational answer not to do so.
> 

my thoughts exactly. this makes absolutely no sense. to think that some banks are going to ban firefox due to this hidden pref is absolutely ludicrous. i'm a camino user and let me tell a little secret - having this pref functional is a godsend. and i don't want to deal with bookmarklets, because for one, you have to 1) load the page, 2) click the bookmarklet, 3) start typing the username to turn on autocompletion. compare this to simply 1) loading the page and having the username/password filled in for you and ready to go.

"walking up to a computer" argument is the most flawed thing i've ever heard. you can also walk up to a computer and open the user's porn collection, find company trade secrets, hell knows what. if a user doesn't know how to properly secure his computer, then firefox is definitely not going to save him. both windows and mac os allow you to "lock" your computer with about 2 mouse clicks.
Product: Firefox → Toolkit
I have re-written Michael Newton's "Activate Autocomplete" Extension (fixed some bugs and made it work with Firefox 3.0). It "fixes" this Bug. You can download it from

http://www.smart-roadster-club.de/off-topic/mozilla/extensions/activate-autocomplete/

I implore you to add the option to override autocomplete=off. Supply a warning, perhaps. Please reconsider this feature request in the name of progress. I use a master password so that lesser passwords can be automatically looked up and provide to me. Thanks in advance.
I gave up on them ever doing this.

Instead I use this: https://www.squarefree.com/bookmarklets/forms.html#remember_password bookmarklet, and just click it on any page I want to force it to remember passwords.

Once the password is stored it's used afterward, even if autocomplete is off.
I opened a bug report on this years ago. There's been several of these opened and marked as dupes. Mozilla originally said years ago they won't fix it because of pressure from financial institutions. These financial institutions were concerned about users passwords being stolen. Because of course "autocomplete=off" has proven to be a major security defense against that right?

Mozilla didn't want to fix this because of that, but also because they were lazy and didn't see it worth the effort. I've always been frustrated about the foolishness of thinking this stupid little non-HTML-compliant "feature" makes ANYONE more secure. And you know, over the past three years I believe there's been ample evidence that the financial institutions and retail chains *supposedly* about customers' security are 1) not and 2) incapable of implementing real infosec even when they HAVE to.

I'm tempted to start a campaign up about this again just to shove peoples faces in the idiocy of it all (security through obscurity, security theatre, real versus perceived safety). But ultimately it isn't worth it... There's enough workarounds that Mozilla won't spend the few hours needed to implement it...

Fortunately, there's a good work around that doesn't require ANY sort of extensions or plugins or bookmarklets. It's documented here:

http://cybernetnews.com/2009/02/13/firefox-remember-passwords/

and just involves modifying a single .js file. You'll have to modify it again when Firefox is updated but that's all. It will make the check for the "autocomplete=off" ALWAYS return false, effectively disabling it. And of course proving the entire "feature" (invented by Microsoft) is utterly useless. Security my ass...
You have my support. I'd also like the names of these institutions that mandated this. I'd also like to see them suddenly revoke the use of FF at this point if it was implemented.
Thanks for all the great replies. I have implemented the .js tweak by commenting out the test and always returning false. :) I am relieved to see that I am not alone in being annoyed by software that forces me to be protected from myself. I don't mind being warned, but to be disallowed is just plain annoying.
--> changed Assignee and QA to defaults

... since Brian Ryner hasn't been working on Mozilla for years and I've had enough reading about something on a browser I don't even use anymore.
Assignee: bryner → nobody
QA Contact: davidpjames → password.manager
Blocks: useragent
(In reply to comment #49)
> I am relieved to see that I am not alone in being annoyed by software that
> forces me to be protected from myself. I don't mind being warned, but to be
> disallowed is just plain annoying.

Exactly! I feel this is exactly the kind of misfeature that the Papercuts project is trying to fix (bug 565512 in particular). Perhaps this could be marked as blocking that?
Many years are over now and some things have changed. Also this ticket is in real a security feature request.

But now a short summary: Currently a lot of sites are using https - much more than a few years ago. Also these sites are usually relying on autocomplete="off". If this will continue the benefit of a password manager will get questionable.
Computers get more and more powerful, bruteforcing a medium complex password isn't a problem today anymore. For this case I'm choosing passwords strong enough to defend even against any supercomper/botnet but short enough to not exceed the pseudo-security on provoking collisions first in common encryption algorithms.

Why this feature request is a security improvement: Preventing the ability to store the (encrypted) passwords will just result that a user is forced to remember all his passwords. On this amount of sites which are currently using autocomplete='off' this is absolutely impossible for a normal being (if the user chooses always the same password like his birthday he has much more problems than explained in this ticket). So the only possibility is to save the passwords - but as Firefox isn't able to do so many of them will result as plaintext on an easy to access paper (already seen this).

This is also a request on the reporter to reopen the ticket and wait for the new opinion of the developers (so that I don't have to create a new ticket).
I'm seeing increasing numbers of sites abusing this feature for no good reason. Often, it's being used to prevent saving usernames, e-mail addresses and other kinds of non-password data - many sites simply put autocomplete="off" on all their form fields. Also, banking sites are increasingly relying on two-factor authentication / token generators, where a password manager is useless anyway. In fact, I see more forums, blogs and other "non-critical" sites (ab)use this nowadays, than banks and other sites with legitimate uses.
So, the previous decision for enforcing autocomplete="off" against the user's preferences should be reconsidered. My suggestions are:
-Only follow autocomplete="off" for password fields.
-Consider allowing the user to override autocomplete="off", as this bug originally requested.
-Perhaps make a whitelist of sites that are allowed to enforce autocomplete="off". This list could be pre-populated with banking sites, and others who explicitly requested this feature from Mozilla and have a legitimate reason to do so (merely "I want to annoy my users by forcing them to retype whole e-mail addresses every time they want to message somebody" is not a legitimate reason).
It's worse on password fields than other fields! For example, there are perfectly valid use-cases to disable autocomplete on normal fields. Having autocompletion is one. It is *really* annoying if there is both the autocompletion "dropdown" from the website and the autocomplete dropdown from the browser.
(In reply to Adrian from comment #55)

> It's worse on password fields than other fields! For example, there are
> perfectly valid use-cases to disable autocomplete on normal fields. Having
> autocompletion is one. It is *really* annoying if there is both the
> autocompletion "dropdown" from the website and the autocomplete dropdown
> from the browser.

This use case makes sense. However, even so, there has to be a way for the user to trigger the browser's auto-completion.
I long ago gave up on getting this "fixed" because Mozilla has made it clear they don't care. In fact, they've implied that the "autocomplete=off" attribute will explicitly NEVER be capable of being disabled within the browser's normal options. From what I gather, various simpleton's in the banking and financial industry leaned on Mozilla, Microsoft and others to force this because the banker fools thought it would make things more secure.

We have all seen how well that's worked out for them.

Fortunately, Mozilla's opinion is irrelevant. For years now I've relied on the KeePass executable and KeeFox firefox plugin to manage my passwords. It works great and doesn't care about autocomplete. KeePass is available for many major platforms.

http://keepass.info/
http://keefox.org/

And it's a more secure and robust solution than the password manager built into Firefox. KeePass has the advantage of various plugins to work with Chrome, Internet Explorer and other browsers.

(I find it amusing and also sad that Chrome now deeply eclipses both IE and Firefox. At least Firefox manages to still be a bit more common than Opera...)
There's also https://addons.mozilla.org/en-US/firefox/addon/autocompleteon/ which works rather well for me. An add-on has always been the second best way of fixing something dumb in Firefox...
Comment on attachment 8340257 [details] [diff] [review]
Adds an about:config option to ignore autocomplete=off

I wouldn't want to see this handled in DOM level, but somewhere in UI level...
in which case what is wrong with https://addons.mozilla.org/en-US/firefox/addon/autocompleteon/ ?
Attachment #8340257 - Flags: review?(bugs) → review-
(In reply to Olli Pettay [:smaug] from comment #60)
> Comment on attachment 8340257 [details] [diff] [review]
> Adds an about:config option to ignore autocomplete=off
> 
> I wouldn't want to see this handled in DOM level, but somewhere in UI
> level...
> in which case what is wrong with
> https://addons.mozilla.org/en-US/firefox/addon/autocompleteon/ ?

Thanks for the review, certainly seems the wrong place for what I'm trying to do (and having thought about things a bit more it seem like the could could be much cleverer and only ignore autocomplete=off for forms that have a password field in them). I will dig around a bit more...

(Problem with the addon  is that it doesn't actually work for me. On top of that I want to be able to use this on all versions of the Browser (Android and FFOS too, although the latter doesn't have password storage yet AFAICS) -- also in general addons seem to have a tendency to break with newer FF versions and require separate maintenance etc., whereas I don't want to have to waste time getting core functionality working with every update/device-change/etc.)
>> in which case what is wrong with
> https://addons.mozilla.org/en-US/firefox/addon/autocompleteon/ ?
It's a hack. But you're right it should be handled elsewhere, preferably at:

http://hg.mozilla.org/mozilla-central/annotate/c93cfe704487/toolkit/components/passwordmgr/LoginManagerContent.jsm#l379

Ideally there should be a hook here to allow addons like the above to intercept this call and to selectively override the autocomplete attribute.
We ended up fixing this in bug 425145.
Status: VERIFIED → RESOLVED
Closed: 19 years ago → 10 years ago
Resolution: WONTFIX → DUPLICATE
You need to log in before you can comment on or make changes to this bug.