Closed
Bug 117989
Opened 24 years ago
Closed 15 years ago
Save password shows alert that is vague on how to save a master password
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: nbaca, Unassigned)
Details
Attachments
(1 file)
24.87 KB,
image/jpeg
|
Details |
Trunk build 2001-01-03-03: WinMe
Overview: When logging into mail choose the checkbox to save the password. The
first time this is done an Alert dialog appears explaining that a Master
Password should be used to store sensitive information. The problem is that it
gives no instructions on how to do this.
Steps to reproduce:
1. Create a new profile
2. Configure for a mail account
3. When the login dialog appears enter a password and select the checkbox to
save the password.
Actual Results: An Alert dialog appears explaining that for greater security a
Master Password should be used but doesn't explain how this is done.
Expected Results: It should give some clue on where to go to enable the Master
Password. I know this is difficult because you don't want to be too specific in
case the location for this control may change.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Marking nsbeta1 because the screen shot in comment# 1 shows the reference to
Master Password but gives no instructions how to enable Master Password.
Currently the user must select Edit|Preferences, expand Privacy & Security,
select WebPassword panel, select the checkbox Use encryption when storing
sensitive data. This is not obvious since under Privacy & Security there is a
Master Passwords panel which is not the correct location to enable encryption
yet it may appear more obvious to the user since it uses the "Master Passwords"
term.
Keywords: nsbeta1
QA Contact: esther → nbaca
Comment 3•24 years ago
|
||
This dialog is not supposed to explain how. It's not supposed to explain
anything. If I had my way, we wouldn't even have this dialog.
The only reason it is in the product is that Netscape Legal wanted it as a CYI
thing, so that nobody would sue us when they discover that we aren't encrypting
passwords by default. Forgetting the legal implications, there is really no
reason for this dialog. As it is, there are too many dialogs that pop up back
to back the first time a user attempts to save a password.
Now for your specific complaint, we used to have more detailed instructions.
But then the menu items changed and the instructions were no longer valid. And
in the embedding product, the instructions would be different as well. So legal
agreed that we could get by without having the additional paragraph giving the
details of how to encrypt your data. I don't recall the bug number, but
basically this bug is saying to undo the patch from the previous bug.
Status: NEW → RESOLVED
Closed: 24 years ago
Keywords: nsbeta1
QA Contact: nbaca → esther
Resolution: --- → WONTFIX
Comment 4•24 years ago
|
||
See also bug 92361. It's not the bug I was referring to regarding removing of
the last paragraph. But it makes reference to it and shows what the screen shot
used to look like.
Comment 5•24 years ago
|
||
Just because legal is satisfied with the solution doesn't mean it's a good
solution. However, adding the text back in doesn't solve the problem either. My
recollection is that this is a modal dialog--you have to dismiss it to turn on
encryption, and then the instructions aren't available anymore.
I don't understand how embedding is relevant here. Isn't the entire Password
Manager UI absent unless the embedder choses to implement it?
I see two possible solutions:
1. Add this paragraph at the end of the dialog:
----
To learn how to password-protect your stored information, choose Help and
Support Center from the Help menu and search on "encrypting stored information."
----
This text is not ideal either, since it still requires the user to remember the
instructions, go someplace else, and read new instructions. But Help is easier
to get to than the Preferences panel. Also we update it all the time anyway for
interface changes, so that's not a problem. Note that this text also relies on
the new Help search feature, which is not yet in the daily builds.
OR
2. Add a help button to the dialog that opens Help to the relevant section
(which already exists--to see it, go to the Help index and click "Encrypting
stored sensitive information").
This is probably the best solution, but it involves another problem: Currently,
opening the Help viewer from a modal dialog results in a modal viewer, so the
user would still have to dismiss the instructions before proceeding to turn on
encryption. I don't see any way around this--Ian, please let us know if you do.
So, I think #1 above is the best solution--unless we simply abandon the user to
digest this scary sounding warning without any clue what to do about it, which
is why this bug got filed.
I suggest that we leave the bug open till either (a) the new Help search feature
is in the builds or (2) somebody comes up with a solution to the modality issue,
which seems unlikely. It doesn't have to be a high priority but I don't think we
should just forget about it.
Comment 6•24 years ago
|
||
> Just because legal is satisfied with the solution doesn't mean it's a
> good solution.
Keep in mind that Legal is the only reason we have this dialog in the first
place. So let's not go making it any more difficult than necessary to satisfy
Legal's requirements.
Comment 7•24 years ago
|
||
The problem is that just "satisfying legal's requirements" creates a problem for
users. Whenever a new user sets up a new mail account or uses Password Manager
for the first time, they are going to see this warning that is very scary and
doesn't give them a clue what to do about it.
What you are saying suggests two things: (1) Netscape cares about covering its
legal ass but not about the user experience; and (2) a friendly experience for
new users is not a business priority for Netscape or AOL.
Both are incorrect. Granted, this is a relatively small problem for new users,
compared to several others I can think of, but it is a problem.
The solution I am proposing involves adding one sentence to the dialog. If you
don't have time to track bitsy stuff like this, assign it to me and I will fix
it myself when we get the Help search feature working.
Comment 8•24 years ago
|
||
The dialog is already too long. I want to shorten it, not lengthen it.
Reporter | ||
Updated•24 years ago
|
QA Contact: esther → nbaca
Comment 9•24 years ago
|
||
I agree that the existing text is both long and confusing. Terms like Password
Manager, Form Manager, and Master Password are irrelevant both for our legal
requirements and for what the user needs to know at this point.
How about something like this (not much shorter, but at least it's not longer):
-------
Saving Passwords and Other Sensitive Information
[Netscape/Mozilla] can save your passwords, user names, and other sensitive
information and enter them for you automatically when web sites or servers
request them.
This information is stored on your computer in a file that's difficult, but not
impossible, to read.
If other people have access to your computer, you may want to encrypt your
stored sensitive information. This approach provides better security but is
slightly less convenient.
To learn how to encrypt your stored information, choose "Help and
Support Center" from the Help menu and search on "encrypting stored information."
-------
The existing Help section on this topic needs to be improved a bit to make this
work, but we need to do that anyway. Also this change will have to wait, as
mentioned above, till the Search feature is available or we figure out a way to
deal with the modality problem and can open the Help viewer directly.
Reporter | ||
Comment 10•24 years ago
|
||
Sean, I like your suggestion. Reopening so that this bug is reconsidered.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 11•24 years ago
|
||
See also bug 117552. If that discussion results in that fact that we no longer
have the legal requirement for this dialog, the whole dialog will be dropped and
this bug report will become a moot point.
Target Milestone: --- → Future
Comment 12•24 years ago
|
||
For the record, there have been several bug reports about the CYA dialog for
saving sensitive information. Here is a cross-reference list of them:
043503: Bad UI in "Saving Sensitive Information" dialog
102288: Wordings for password manager are specific to the application
117552: opening Site with PW opens annoyance window
117989: Save password shows alert that is vague
119114: logging into hotmail: 6 dialogs
Reassigning to module owner
Assignee: morse → sspitzer
Status: REOPENED → NEW
QA Contact: nbaca → laurel
Target Milestone: Future → ---
Updated•21 years ago
|
Product: Browser → Seamonkey
Updated•20 years ago
|
Assignee: sspitzer → mail
Updated•17 years ago
|
Assignee: mail → nobody
QA Contact: laurel → message-display
![]() |
||
Comment 14•16 years ago
|
||
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.
If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.
Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
![]() |
||
Comment 15•15 years ago
|
||
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.
Because of this, we're resolving the bug as EXPIRED.
If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.
Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago → 15 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•