Closed Bug 124065 Opened 23 years ago Closed 22 years ago

RFE: add preference to ignore 'autocomplete=off' when using wallet encryption

Categories

(SeaMonkey :: Passwords & Permissions, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: thieleke, Assigned: morse)

References

Details

(Whiteboard: This is a **SEAMONKEY** bug. See Product.)

Attachments

(1 file, 1 obsolete file)

As described in Bug 63961, some banks used to block Mozilla because it didn't
support a means to disable the password manager.  So 'autocomplete=off' support
was added, with no means to override other than recompiling with
WALLET_DONT_CACHE_ALL_PASSWORDS undefined.  

I am suggeting the addition of a preference item (there doesn't need to be a
GUI) to override 'autocomplete=off' iff the user is using wallet encryption. 
Comment 17 in bug 63961 <http://bugzilla.mozilla.org/show_bug.cgi?id=63961#c17>
points out that certain institutions might not accept any sort of override.  But
I believe that limiting the override to only the case where password is
encrypted on disk will result in better security, since the user will be more
likely to pick a strong password, rather than one that is easy to remember.
Jeff, I think this is an excellent suggestion and one that I will 
whole-heartedly endorse.  Would you like to post a patch for it?
Yep...this works for me.  Feel free to adjust the preference name, if needed.
Comment on attachment 68275 [details] [diff] [review]
Provides a conditional 'autocomplete=off' override

r=morse
Attachment #68275 - Flags: review+
That's perfect.  Get yourself a super-review and we'll be able to check this in.
Comment on attachment 68293 [details] [diff] [review]
Added the new pref to all.js...no code changes.

r=morse
Attachment #68293 - Flags: review+
Attachment #68275 - Attachment is obsolete: true
Comment on attachment 68293 [details] [diff] [review]
Added the new pref to all.js...no code changes.

sure this looks ok. I sure hope wells fargo doesn't start blocking us again
over this, but what can ya do :)
sr=alecf
Attachment #68293 - Flags: superreview+
Checked in.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
*** Bug 145797 has been marked as a duplicate of this bug. ***
is this option still available?  where is it?
No GUI, but all you need to do is add:
user_pref("wallet.crypto.autocompleteoverride", true); 
to your prefs.js file.
Eww, another hidden pref?  I guess I didn't post my workaround
(http://www.squarefree.com/bookmarklets/pagelinks.html#remember_password)
quickly enough.
I came across Jesse's bookmarklet today and it really rocks. What wonders me is:
why do we even honour this autocomplete="off"? this is not in the standards, as
much as I know.
We honor it so that financial sites will not block mozilla/netscape-6.  See bug 
63961 for details.
*** Bug 185130 has been marked as a duplicate of this bug. ***
*** Bug 185770 has been marked as a duplicate of this bug. ***
v
v
Status: RESOLVED → VERIFIED
*** Bug 211884 has been marked as a duplicate of this bug. ***
*** Bug 250831 has been marked as a duplicate of this bug. ***
I understand that they don't want passwords cached ( I don't cache passwords at
all in my setup ). But why not remember usernames and other fields ?
They are not a security problem ( if they are, there is something wrong with
their "security" ).

So can we (you) ignore autocomplete for non-passwords INPUT fields ? Please ? ;-)
Product: Browser → Seamonkey
*** Bug 287347 has been marked as a duplicate of this bug. ***
I just tried enabling wallet.crypto.autocompleteoverride as described in comment
11, but it doesn't work.  The awful autocomplete attribute is still honoured and
the form field values are not saved.  Can this bug be reopened or should a new
bug be filed to get this fixed?
user_pref("wallet.crypto.autocompleteoverride", true); doesn't seem to work in
OS/2 trunk for me either on e.g. Yahoo.
This is a **SEAMONKEY** bug. See Product. Don't reopen this bug based on it not
being supported in Firefox. It was fixed in the product it was filed against
long ago, reopening in a different implementation in a product just makes a mess
of things.
Whiteboard: This is a **SEAMONKEY** bug. See Product.
OS/2 trunk means Seamonkey.
(In reply to comment #26)
> OS/2 trunk means Seamonkey.

I was reacting to Lachlan's comment 23, or rather to R.K.Aa's duping of his
Firefox bug here. This is still a problem in Firefox, but reopening this bug to
deal with it isn't approrpiate.
*** Bug 254561 has been marked as a duplicate of this bug. ***
I checked attachment 68293 [details] [diff] [review] and found that line:

if !(SI_GetBoolPref(pref_Crypto, PR_FALSE) &&
SI_GetBoolPref(pref_AutoCompleteOverride, PR_FALSE))

From my understanding of logic this is the same as
if (SI_GetBoolPref(pref_Crypto, PR_TRUE) ||
SI_GetBoolPref(pref_AutoCompleteOverride, PR_TRUE))

So why is it written negated and is this really what the author wanted?
Shouldn't it be
if (SI_GetBoolPref(pref_Crypto, PR_TRUE) &&
SI_GetBoolPref(pref_AutoCompleteOverride, PR_TRUE))
Nope. The correct change would be:

if (isPassword && (!SI_GetBoolPref(pref_Crypto, PR_FALSE) ||
!SI_GetBoolPref(pref_AutoCompleteOverride, PR_FALSE))

which is no better programmatically and effectively makes the code slightly less
obvious. That second paramter is a default value for the GetBoolPref method.

The code is essentially doing something like "if the isPassword boolean is set
and the two prefs are not both set to true".

Your change made it to "either pref is not set or is set to true".

(In reply to comment #29)
> From my understanding of logic this is the same as
> if (SI_GetBoolPref(pref_Crypto, PR_TRUE) ||
> SI_GetBoolPref(pref_AutoCompleteOverride, PR_TRUE))
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: