Last Comment Bug 16489 - (profile-password) Password Protection of Profiles
(profile-password)
: Password Protection of Profiles
Status: RESOLVED WONTFIX
NO SPAM PLEASE. Before you comment, f...
:
Product: Core Graveyard
Classification: Graveyard
Component: Profile: BackEnd (show other bugs)
: Trunk
: All All
: P5 enhancement with 141 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 16850 17186 26825 44495 60466 74636 157838 167215 196320 227086 243622 247961 248762 296105 299304 336838 342378 347724 347726 373620 381399 381536 451685 494545 515236 526720 547436 548780 552335 563292 577105 591360 607269 665287 788958 939594 1001973 1011956 (view as bug list)
Depends on: 91384 92054
Blocks: 98346 19184 63092 123569
  Show dependency treegraph
 
Reported: 1999-10-14 18:55 PDT by Ben Goodger (use ben at mozilla dot org for email)
Modified: 2016-04-04 08:49 PDT (History)
127 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
very preliminary, work-in-progress patch for mike's use (1.34 KB, patch)
2001-06-05 20:25 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details | Diff | Splinter Review
outlook express password disclaimer, which we should have something similar to. (20.03 KB, image/jpeg)
2001-06-11 03:26 PDT, Mike Jaques
no flags Details
First XUL/JS/DTD patch for profile passwords (13.11 KB, application/octet-stream)
2001-06-13 12:49 PDT, Michael Hearn
no flags Details
(doh!) This time hopefully it will upload properly. (13.11 KB, application/octet-stream)
2001-06-13 12:52 PDT, Michael Hearn
no flags Details
converted mhearn's contribution into a CVS patch (25.52 KB, patch)
2001-07-09 14:48 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details | Diff | Splinter Review
initial backend integration (cvs diff -N -u -w -b profile) (36.38 KB, patch)
2001-07-13 18:04 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details | Diff | Splinter Review
couple of zipped screenshots (46.29 KB, application/x-zip-compressed)
2001-07-13 18:08 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details
Set Password Screen from Master Password in the preferences (as an example how it could look). (4.34 KB, image/png)
2001-07-14 15:56 PDT, Peter Lairo
no flags Details
Second GUI patch. Just unzip the files into the right place in the comm\profile and en-us\profile directories (11.99 KB, application/octet-stream)
2001-07-17 14:26 PDT, Michael Hearn
no flags Details
updated screenshots (zipped) (77.80 KB, application/x-zip-compressed)
2001-07-20 00:13 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details
cleaned-up patch (36.72 KB, patch)
2001-07-20 00:15 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details | Diff | Splinter Review
http://www.fourmilab.ch/onetime/otpjs.html This document is in the public domain. (40.44 KB, text/html)
2001-07-20 03:08 PDT, timeless
no flags Details
screenshots of corrected UI - mpt could you please review this again? (29.31 KB, application/x-zip-compressed)
2001-07-23 19:24 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details
one more change: widget alignment and additional padding, dialogbox witdth is now fixed at 28em (24.52 KB, application/x-zip-compressed)
2001-07-23 19:39 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details
most recent patch (with UI review from 07-25-2001) (36.48 KB, patch)
2001-09-13 17:53 PDT, jbetak@netscape.com (away - not reading bugmail)
no flags Details | Diff | Splinter Review
Patch - 6th Dec 2001 (36.54 KB, patch)
2001-12-06 14:07 PST, Michael Hearn
no flags Details | Diff | Splinter Review
Here's an amusing joke. Well, it'd depend on taste of course...... (1.02 KB, text/plain)
2001-12-06 14:19 PST, Michael Hearn
no flags Details
Latest patch as of 7/12/2001 (36.55 KB, patch)
2001-12-07 07:33 PST, Michael Hearn
no flags Details | Diff | Splinter Review
updated patch (20.37 KB, patch)
2002-12-22 06:04 PST, jay@mozillacafe.org
no flags Details | Diff | Splinter Review

Description Ben Goodger (use ben at mozilla dot org for email) 1999-10-14 18:55:41 PDT
Profiles should be able to be protected with passwords (perhaps by storing files
inside jarballs or other..?) I'll be glad to supply the XUL/UI extensions to the
Create New Profile Wizard and Profile Manager that are required to supplement
back end implementation.
Comment 1 selmer (gone) 1999-10-15 10:07:59 PDT
There's a lot more than UI to this.  This isn't yet the right time to worry
about this feature.
Comment 2 selmer (gone) 1999-10-20 12:02:59 PDT
*** Bug 16850 has been marked as a duplicate of this bug. ***
Comment 3 selmer (gone) 1999-11-01 15:23:59 PST
*** Bug 17186 has been marked as a duplicate of this bug. ***
Comment 4 leger 2000-01-20 09:22:59 PST
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Comment 5 racham 2000-05-31 14:16:50 PDT
Reassigning to myself. 
Comment 6 racham 2000-07-06 19:09:16 PDT
*** Bug 44495 has been marked as a duplicate of this bug. ***
Comment 7 kmurray1115 2000-07-18 19:31:38 PDT
Looks like a feature that didn't make the date. We need this to get a 
designation of nsbeta3 or future. I'm inclined for the latter, given the looming 
ship deadline. Anyone?
Comment 8 Henrik Gemal 2000-07-20 12:34:28 PDT
*** Bug 26825 has been marked as a duplicate of this bug. ***
Comment 9 racham 2000-07-24 19:23:18 PDT
This calls for architectural changes for profilemanager code. Not doing it in
beta3. Moving the milestone to future.
Comment 10 sairuh (rarely reading bugmail) 2000-11-20 15:45:41 PST
*** Bug 60466 has been marked as a duplicate of this bug. ***
Comment 11 Peter Lairo 2000-12-01 05:35:29 PST
seeing how many people are reportingthis as a bug (see number of duplicates), 
this issue needs to be resolved soon.

Please give it a definite and near target milestone (suggest 0.6 or 0.8 latest).
Comment 12 racham 2000-12-04 18:31:12 PST
Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.
Comment 13 Peter Lairo 2000-12-05 07:55:04 PST
Conrad,

this bug (profile password) and the ability to "watch" messages in newsgroups
are the only two items keeping me from using Mozilla on a DAILY basis.
Comment 14 Conrad Carlen (not reading bugmail) 2000-12-05 09:27:20 PST
This is very hard to do in a way that is not easy to get around. I can't see it
being worthwhile without encrypting many files within the profile dir. Mail
folders can be huge, although it may be posible to encypt/decrypt just the
database file for an account fairly quickly. Either way, there are a lot of
files and subsystems involved in this. I'll need opinions from others. 
Comment 15 Peter Lairo 2000-12-06 01:57:07 PST
Conrad, there is no need to encrypt the actual files in the profile's directory. 
That would be overkill. All we need is to be able to deter someone from 
accidentally entering our profile by hitting ENTER in the profile manager. It 
will also deter 99% of people who want to take a "peek" at our mail and 
bookmarks. It would be the same feature as in NC 4.x - a simple password that 
allows entry into ones profile.

Those who are willing to read through hundreds of pages of difficult to read 
text files to read our mail will likely not be able to be deterred by encryption 
either. Please create a simple password protection for profiles for the 99% of 
us "casual" users.

This should be simple enough to implement in a near nightly build ;-)
Comment 16 Conrad Carlen (not reading bugmail) 2000-12-11 10:24:30 PST
Implementing this in the way you suggest would be so easy to get around, it
would be a joke. Having that joke be such a visible part of the product would
probably not go over well. That's not to say I disagree with doing it the right
way though.
Comment 17 Peter Lairo 2000-12-12 02:55:25 PST
Conrad, I know it would be "insecure" but it would still deter 99% of casual 
users who don't even know where the mail files are located. It would also 
prevent people from accidentally hitting return in the profile manager and 
entering someone elses profile. Most users would benefit from this. You could 
even pop-up a warning message infoming the masses that this protection is not 
secure. If mozilla is to retake the mainstream crown, it must also satisfy the 
majorities wishes (even if not 100% "secure"). Encryption can always be added 
later without redoing the code for this request.
Comment 18 Henrik Gemal 2000-12-12 03:05:30 PST
Come on...
"Warning: This profile is password protected, but not secure at all..."
Mozilla should represent the correct way of doing stuff.
If hitting Enter is the problem, just implement a "Are you sure you want to 
start this profile?" dialog.
Comment 19 Peter Lairo 2000-12-12 03:45:54 PST
This warning dialogue could appear when selecting to password protect a profile 
(it is taken DIRECTLY from the NC4.x webpage!!!):

Specifying a password for your local user profile does not encrypt profile data 
in any way, nor does it prevent others from renaming or deleting profiles, but 
it can prevent users from inadvertently accessing profile data without first 
entering a password.  

This mechanism may therefore be appropriate in a home environment, where members 
of a family may want to keep their information separate, or for developers who 
may want to keep their working profile separate from profiles used for testing 
purposes.  

It is not appropriate as a replacement for OS-level security, nor should it be 
used as the only means of protection within a lab or kiosk environment where 
users have an expectation of privacy.  For these environments, administrators 
may wish to consider Communicator 4.5's Network Install or Roaming Access 
features, which retrieve profile information from centralized servers.

The full text is at:
http://home.netscape.com/communicator/v4.5/passwords/index.html
Comment 20 Henrik Gemal 2000-12-12 03:48:13 PST
But lets also remember that password protection of profile was quickly dropped. 
It only appeared in 4.5 not in 4.7
Comment 21 Peter Lairo 2000-12-12 03:59:37 PST
...which was a big mistake. Given the choice, I'm sure most normal users (not 
geeks who know how to help themselves) would prefer a less secure solution over 
no solution!!! Please iplement this important feature.
Comment 22 Gervase Markham [:gerv] 2000-12-14 09:17:28 PST
In 4.x, you can get most of the important effect with password protection of 
your mail account. That's how I set it up recently - anyone can start up a 
profile, but you can't read mail without knowing the IMAP password. I assume 
this would work in Mozilla - just set the Password Manager not to remember it, 
and you are there.

Gerv
Comment 23 Peter Lairo 2000-12-14 09:55:12 PST
.. not good enough. Someone could still read existing mail (what was copied to 
other folders), see all bookmarks (who would want their wife to find those 
favorite porn sites ;-), see the address book, etc.

With only my new mail protected, everything else would be open to exploration by 
others. We need password protected profiles - please.
Comment 24 Dan Mosedale (:dmose) 2000-12-14 11:45:06 PST
I tend to agree that this is worth doing, despite the fact that it doesn't
provide any sort of "strong" protection.  Security is about managing risk rather
than eliminating it, and this removes the risk of people who are just doorknob
twisters.
Comment 25 Simon Lucy 2000-12-15 01:21:23 PST
Simple password access to open files when the underlying operating system 
supports login and user based permissions is brain dead.  Profiles belong to 
the user not the application, requiring a user to login more than once is daft.

Simple password access to open files when the underlying operating system 
doesn't protect the files gives the user a false sense of security and when 
discovered and publicised would damage the reputation of any application that 
implemented it.

If you want protection over and above whatever the operating system provides 
then you need to encrypt and protect the files individually or use a private 
file system.  Whilst this might seem an advantage for low security file systems 
like Windows 9x it will have repercussions for systems admin in managing their 
systems. 

For operating systems where the profile support is broken (Linux and *nix), the 
solution is to fix the installation so that the code can be installed once and 
profiles stored with the correct user permissions.
Comment 26 Peter Lairo 2000-12-15 03:19:14 PST
Nobody EVER said anything about "requiring" a user to login twice! Since most 
office computers are ON all day, it would be nice to at least have the OPTION to  
"manage" my risk. Also, at home, I don't want to necessarly protect my entire PC 
(i usually turn it on and walk away and do other things; when i return, I want 
it to be booted COMPLETELY - and not have to enter a password and wait AGAIN 
until the login finishes).

For the rest of your arguments, please read my previous comments before posting 
(reg. false sense of security and encryption).
Comment 27 Albert R. 2000-12-15 05:00:39 PST
To prevent the false sense of security, there should be a warning prompt that 
lets the user know that it *isn't* strongly or even lightly encrypted, and still 
allows access to the files through other methods, similar to the warning web 
page for 4.5 (which worked on a Win2k system with 4.72, btw).
Comment 28 Adam Lock 2000-12-15 11:18:28 PST
Short of strong encryption on every file in the profile and the programming hell 
that would entail for Mozilla, I don't see how it is possible to introduce *any* 
security by requiring password protection.

You'd much better off to use the security features of the operating system 
you're running on. Linux/Unix/NT/2000 (& soon MacOS X & Whistler) to deny access 
to your profile. For example, set the folder & file permissions, turn on 
password protection on your screen saver etc.

Even Win95/98/Me can have an encrypted filesystem if you install something like 
PGPDisk.
Comment 29 Simon Lucy 2000-12-15 13:32:18 PST
Since, on insecure operating systems, a straightforward search for any text 
will search all files on a system if asked for, just press F3 and select My 
Computer for example, the problem of inadvertant access of mail is more than 
just having access to different stored profiles.

It is the responsibility of operating systems to protect discrete files and not 
the responsibility of the application.
Comment 30 Mike Jaques 2000-12-15 21:08:58 PST
As long as its noted this is not strong encryption, and explicitly stated in 
somewhere in the routine of setting up password protection, then again each 
time the "login screen" for the profile manager comes up I see no problems with 
this scenario.

It's simply a risk minimizer against nosey roomates/coworkers, and certainly 
isn't intended to keep out intermediate to advanced computer users who would 
know how to circumvent these security feature.  Outlook Express allows non-
secure password protections of its profiles with a warning that the password 
protection is no guarantee that the users mail is secure against intrusion.
Comment 31 Peter Lairo 2000-12-18 01:02:37 PST
We must stop clinging to our personal dogmas ("it is the responsibility of 
operating systems to protect discrete files and not the responsibility of the 
application") and also consider the "client's" wishes. Then entire windows OS is 
a prime example of this. It is full of "compromizes" between technical 
perfection and customer whims and wishes (DOS compatibility). If Mozilla is to 
regain the browser crown, it MUST make these crucial compromizes. It will 
benefit no-one if we satify only one of these criteria. I know it is sometimes 
difficult to compromize our "principals", but in this case it will benefit 
everyone. Please consider implementing Password Protection of Profiles.
Comment 32 Simon Lucy 2000-12-19 03:41:41 PST
It would help as well when evangelising to listen as well as shout.  I'm not at 
all dogmatic but it is true that the management of file permissions belongs to 
the operating system (or more technically to the file system itself), and not 
to applications using them.

Consider data sharing.  If you have two applications sharing data, one of them 
applies a password to accessing the data the other doesn't.  Where is the sense 
in this?  

This is exactly the situation you are asking for.  I can use notepad or some 
other editor to edit and change files within the user profile legitimately.  
Now you might say that a regular home user wouldn't want to do this and should 
be protected from doing it either accidentally or otherwise.

If that is the case then you are arguing for different products for different 
kinds of users (an old chestnut but one that is ageless).  Even so there are 
files in the profile that should remain editable by other applications, 
userChrome.css for example.

No one will argue that this situation is insecure but I doubt that anyone with 
the ability to add this vestige of security will implement it.  I wish there 
was a 'Vote against this'.
Comment 33 Peter Lairo 2000-12-19 05:13:23 PST
Your last sentence shows that you are stubborn. 

Nobody is advocating forcing users to use password in their profiles. You might 
be surprized how popular this feature will be. Keep in mind that this feature is 
only intended as a "a risk minimizer against nosey roomates/coworkers/teenage 
brothers". Consider this: Lotus Organizer, WordPerfect, Excel and many other 
program all let you "protect" your files with a password. None of these systems 
are "secure" (there are cracks all over the internet). Yet these features are 
implemented and useful for doing what I have been saying all along: "to deter 
99% of casual users".
Comment 34 Albert R. 2000-12-19 10:21:35 PST
It is the duty of the OS to protect files.  Unfortunately, most of use are using 
Windows 9x, where security is nonexistent.  Most of the users of this product 
will not know the workaround, so the password is an effective deterrent.  For 
the rest of the users, profile passwords would serve as a speed bump.  And when 
all the OSs have inherent protection, this will be another protection step in 
case someone forgets to log out.

This isn't 100% urgent, but I would hope to see it by 1.0.
Comment 35 Simon Lucy 2000-12-19 16:45:16 PST
Peter... you seem wedded to your own dogma that bad is good enough, but 
sometimes worse is just worse.  It really doesn't matter whether its optional 
or not, but as a practical result of it being optional, where is the option 
stored?  

In a preference?

If its a preference then it can be switched off outside of the application, its 
a text file.  So, not only does the password not actually stop someone 
inadvertently reading the files it can actually be switched off entirely by 
anyone using the machine.

If its not a preference in the normal sense then you are asking for a secure 
file to store both the password and whether the need for the password is wanted 
or not.  

I imagine in the case of the secure file being missing, say deleted, that 
Mozilla will start and say something about profiles being damaged and then the 
user can take remedial action, perhaps by specifying a new password which gains 
access to the files again. Which would be good for the genuine user of that 
profile and good for anyone that wanted to hack it.  The alternative is that 
the user's profile data is 'inaccessible' to the user, except it isn't as you 
can just create a new profile and copy the old files back over it again.

There are consequences to any design change, there are far more consequences to 
bolting on 'security' to an app.  Security has to be built into an app and not 
added as superstructure.  I agree its nasty and horrible that Win9x and Me are 
so insecure, I think though that enabling users and logins on the operating 
system and having profile directories in My Documents where they belong is as 
good a compromise as can be made.

This isn't stubbornness, just common sense and your request isn't addle-headed 
its just not taking everything into account.

Comment 36 Simon Lucy 2000-12-19 16:55:30 PST
Peter... you seem wedded to your own dogma that bad is good enough But 
sometimes worse is just worse.  It really doesn't matter whether its optional 
or not, but as a practical result of it being optional, where is the option 
stored?  

In a preference?

If its a preference then it can be switched off outside of the application, its 
a text file.  So, not only does the password not actually stop someone 
inadvertently reading the files it can actually be switched off entirely by 
anyone using the machine.

If its not a preference in the normal sense then you are asking for a secure 
file to store both the password and whether the need for the password is wanted 
or not.  

I imagine in the case of the secure file being missing, say deleted, that 
Mozilla will start and say something about profiles being damaged and then the 
user can take remedial action, perhaps by specifying a new password which gains 
access to the files again. Which would be good for the genuine user of that 
profile and good for anyone that wanted to hack it.  The alternative is that 
the user's profile data is 'inaccessible' to the user, except it isn't as you 
can just create a new profile and copy the old files back over it again.

There are consequences to any design change, there are far more consequences to 
bolting on 'security' to an app.  Security has to be built into an app and not 
added as superstructure.  I agree its nasty and horrible that Win9x and Me are 
so insecure, I think though that enabling users and logins on the operating 
system and having profile directories in My Documents where they belong is as 
good a compromise as can be made.

This isn't stubbornness, just common sense and your request isn't addle-headed 
its just not taking everything into account.

Comment 37 Mike Jaques 2000-12-19 20:38:38 PST
> If its a preference then it can be switched off outside of the application,
> its a text file.  So, not only does the password not actually stop someone
> inadvertently reading the files it can actually be switched off entirely by 
> anyone using the machine.

How about taking a look at Outlook Express.   Its basically a bolt-on, and its 
not meant to be secure secure against knowledgeable "hackers."  We've already 
conceded that point, MANY MANY TIMES.  Still, 15 people and counting have voted 
for this addition, including myself.  Even though I don't see much use for it 
personally, for many people that share a computer with a little 
sister/brother/mother/father, or in a small office environment where 
workstations are win9x, there _is_ a strong need for it as a simple quick 
deterant against snooping.  I can't even see how this would be too hard to 
implement.

It's simply a deterant.  Stick an anti-theft deterant device on your car does 
not guarantee it won't be stolen, but it does deter a quick spin round the city 
by a joy-riding youth.

IT should be a pref, and pref's are stored in one of the moz reg/prefs files 
are they not?  (since mozilla does not use the registry like most programs)  
Store a pref there, and have a preference panel (or drop down like OLE) and 
also since OLE stores its mail folders under C:\Documents and 
Settings\Administrator\Local Settings\Application Data\Identities\{92152DEF-
FA7A-4B83-96E2-ADA3E0DB919A}\Microsoft\Outlook Express (the win9x equiv would 
probably be  C:\Windows\Local Settings\Application Data\Identities\{92152DEF-
FA7A-4B83-96E2-ADA3E0DB919A} ) then a good choice would be under the same style 
structure, but under the mozilla equivalent, C:\Documents and 
Settings\Administrator\Application Data\Mozilla\Users50\default\7urtmi9x.slt  
or where-ever that equiv is under win9x. Once the prefs panel turns on password 
protection, the profile manager is automatically launched instead of a simple 
moz launch with the default profile no matter the situation (except maybe a 
command line /switch ) and a password entry area in the profile manager becomes 
un-greyed to accept password entry/change .....   maybe a click button to open 
a sub-window to setup preliminary/change passwords.
Comment 38 Simon Lucy 2000-12-20 00:10:37 PST
And what happens if someone edits the plain text file which contains the
preference removing the password setting or reverting it?

Comment 39 Peter Lairo 2000-12-20 02:47:03 PST
How many time do we have to repeat this?

"Its basically a bolt-on, and its not meant to be secure secure against 
knowledgeable "hackers."  We've already conceded that point, MANY MANY TIMES."
Comment 40 Peter Lairo 2000-12-20 02:50:43 PST
OK, AGAIN... if a knowlegeable hacker changes you password, someone has 
basically deliberatey seriously damaged your system. In that case you would need 
a somewhat knowlegeable person who would simply create a new profile and copy 
the files from your old profile into the new one, thus restoring your files.
Comment 41 Albert R. 2000-12-20 07:58:14 PST
Honestly, how many of your "normal" (read: non-computer freaks =) friends know 
where the mozilla registry is?  How many people know how to edit this file?  
Half of the people I know don't even realize there's a Windows Registry, let 
along a Mozilla registry.  A simple password prompt to prevent entry shouldn't 
be too hard to add, but would be effective in environments where several people 
share a computer and can't trust each other.
Comment 42 Simon Lucy 2000-12-20 08:43:58 PST
Objections to this are not about how individuals use their computers, my use 
has nothing to do with my not wanting this implemented.  My objection is solely 
about the health of the application for all users.

Having a broken security option is not an advantage for the application as a 
whole.  Treating security as a bolt on just because the people its not 
protecting don't know any better isn't doing those people any favours at all.

Example.
Grumpy Fred is a member of a mailing list that sends him pornographic offers.  
He uses Netscape 6 and has set up a password on his profile and email.

Dainty Alice is a girl of sensitivity that shares the computer with Grumpy Fred.

Dainty Alice can't find her homework notes on teenage angst and following her 
favourite Windows for Dummies presses F3 after opening My Comnputer and 
puts 'teenage' into the file contains box and then clicks on OK.

As well as finding her homework notes it also finds email to Grumpy Fred 
implying ways of removing teenage angst that Dainty Alice has never even 
contemplated.

(There is no similarity with any persons living or dead called Fred or Alice, 
yeah right).
 
Comment 43 Peter Lairo 2000-12-20 09:19:45 PST
This would happen WITHOUT a profile password too!

Also, pressing F3 only searches "fileNAMES" by default and mozilla stores the 
mails WITHIN a file that only has the name of the mail FOLDER (e.g. Grumpy Fred 
Mail). Only if you select the "Further Options" tab and select to search text 
within documents could what you are saying happen. I did a test search for "sex" 
on my PC and after several minutes, all it came up with was a list of jpg files 
(ALL non-pornografic!!!) and a few wordperfect files where the word sex didn't 
even appear! Either way, profile passwords would not improve or worsen this 
situation at all. Your point is irrelevant (now i sound like 7of9).
Comment 44 bobmlewis 2000-12-21 16:21:05 PST
et al...The basic premise that, via the profile login, an individual user can
customize the browser layout, skins and automatic ?pre-fill? of forms together
with rendering privates ones personalized bookmark directory, login passwords,
email address book and filing of personal correspondence, is reasonable.

So how do we suggest it be achieved?  We know others have it.  We, I would like
it and so I think would many others.

I suggest this is a matter protecting ones privacy within the reasonable
expectations of a home or small office environment.

What is secure can be argued forever.  Security goes from the perceived to the
truly tough and each level is aimed at protecting against a certain degree of
sophisticated penetration.

In a world where features, conveniences, and attempting to offer some kind of
personalization of ones browsing experience attract users, this feature is
desirable.
Comment 45 bobmlewis 2000-12-21 16:22:45 PST
et al...The basic premise that, via the profile login, an individual user can
customize the browser layout, skins and automatic ?pre-fill? of forms together
with rendering privates ones personalized bookmark directory, login passwords,
email address book and filing of personal correspondence, is reasonable.

So how do we suggest it be achieved?  We know others have it.  We, I would like
it and so I think would many others.

I suggest this is a matter protecting ones privacy within the reasonable
expectations of a home or small office environment.

What is secure can be argued forever.  Security goes from the perceived to the
truly tough and each level is aimed at protecting against a certain degree of
sophisticated penetration.

In a world where features, conveniences, and attempting to offer some kind of
personalization of ones browsing experience attract users, this feature is
desirable.
Comment 46 Peter Lairo 2001-01-05 07:06:54 PST
OK, i have tried what the tech sticklers suggested and have created a user
profile for each user at my house; and also started using mozilla as my promary
browser since 3 days ago (yeah). Now, according to Simon's theory, the OS is
taking care of the security of my profile. Unfortunately, this is only partially
the case. Both at home and at work, I frequently leave my computer on all day
and am often not at my desk. Anyone coming in can now load mozilla and read my
mail. A screensaver password is not desirable since people often have a
legitimate reason for using my PC (both home & work), for instance to get
project related info (work) or to make a printout of a letter(home - my wife's
PC doesn't have a printer).

I apologize for this legthy explanation, but it is important to understand that
a password protected profile would provide an additional layer of protection
beyond what any OS does. And that aint a bad thing!
Comment 47 Simon Lucy 2001-01-05 07:31:30 PST
So you want protection for when you're already logged in and presumably not 
running a copy of Mozilla.  But if you do run a copy of Mozilla it asks for a 
password in order for you to use it.  

I suppose you'd accept that if Mozilla was already running that anyone could 
see anything anyway, quite apart from there being no protection of text files.


Comment 48 Peter Lairo 2001-01-05 08:15:33 PST
yes and yes (although you left out the questionmarks - reminds me of my father
who would ask a "question" but didn't necessarily listen to the answer).

PS. Could someone please put in a keyword for mozilla 0.8 or 0.9 (ben? anyone?)?
Comment 49 Conrad Carlen (not reading bugmail) 2001-01-05 10:21:11 PST
As far as the keyword, I think you mean milestone. It's not even been decided as
to whether or not to do this. Setting the milestone would happen after that
point (if and when it comes).
Comment 50 Dan Mosedale (:dmose) 2001-01-05 14:17:33 PST
Conrad: setting a keyword of mozilla0.8 is the way to nominate a bug for
consideration for setting the target milestone itself to mozilla0.8.
Comment 51 Ben Bucksch (:BenB) 2001-01-17 21:54:21 PST
For the record: As stated on .security already (where this has been discussed,
too), I am against implementing this. Such a ridiculus "strength" of security
would give Mozilla only a bad reputation (like MS Word).
If you are concerned about that, use an OS with user-protection. It is IMHO just
braindead to implement such "security" measures in each app - Browser, Mail,
Word processor, Spreadsheet, you name it - independantly.
There are by far worse problems to fix in Mozilla.
Comment 52 Mike Jaques 2001-01-17 23:13:09 PST
I know its not important for moz1.0  but would setting it as a mox1.1 milestone 
be complete out of the question?  It's not ridiculous, and its a feature taht 
would come in handy for 99% of the public that uses a non-secure commercial OS 
like win9x (and I'm pretty such most mac OS's fall into this category too.  
BeOS?)   It's not secure secure, we've stated taht a million times, but there 
are numerous examples (including and excluding MS) out there of non-secure 
proventive measures that can be taken to discourage (not prevent, though even 
with a secure OS that is possible,  nothing is "proof") snooping on ones profile
(s) by others less hindered by a sense of conscience.  It's not a matter of 
whether this is "right" or "wrong"  its a matter of public wish.  Know why many 
great things fail? Marketting.  Advertise profile protection (just making sure 
that its noted clearly that its not 100% fullproof) and the masses will love 
you for it, and flock to Moz/NS Nav/Beonix/etc etc... in a heart beat.

Add a password box that becomes ungreyed in the profile manager if profile is 
deemed to be password protected and voila,  an asterisk-echod password entry 
box must be entered with a password before entry.  For changing/adding a 
password, that would be a button somewhere on the manager to edit password of 
the currently selected profile in the list box. and would pop-up a dialog box 
for password manipulation.  For on-the-fly switching, add a pop-up dialog box 
on activation of the switch if the profile is deemed to have a password 
prompting for the password.  Editting the password would be dynamic in that (if 
possible) another drop-down menu item triggering a pop-up (and/or pref panel) 
would be where all password manipulation of the current profile would take 
place.
Comment 53 Peter Lairo 2001-01-18 00:51:37 PST
> Such a ridiculus "strength" of security would 
> give Mozilla only a bad reputation (like MS Word).

.. and M$ Word is such a poorly selling app? ba-humbug ;-)

We must ask ourselves: Do we give people what we think they should have
(dictatorship) or what they are asking for (democracy)? Within the realm of
possibility, we should give them what they want. It's that simple. 

I appreciate that you feel strongly about what you think is best, but sometimes
it is necessary to be flexible to survive in todays market.
Comment 54 Simon Lucy 2001-01-18 01:20:17 PST
Its more a candidate for a distributor to implement it doesn't fit with 
Mozilla's general thrust, try badgering Netscape on netscape forums (not 
mozilla ones), I wouldn't try Beonex though I think its clear it doesn't fit 
there either.

Just because its wanted doesn't mean its the right thing to do.
Comment 55 Henrik Gemal 2001-01-18 05:52:16 PST
If someone want to implement this, go right ahead. I dont think that either 
Mozilla or Netscape hired developers should spend time on this.

There are a lot of other areas in mozilla that's more important than this one. 
We cant even agree on wheather to implement this or not.

Perhaps this should just be "helpwanted" or something like that...?
Comment 56 Peter Lairo 2001-01-18 06:09:51 PST
could then someone who has the authority please add the keyword: helpwanted ?
Comment 57 Jacob Steenhagen 2001-01-18 06:16:18 PST
Should this also be reassigned to nobody@mozilla.org?
Comment 58 Conrad Carlen (not reading bugmail) 2001-01-18 12:55:48 PST
> If someone want to implement this, go right ahead. I dont think that either
> Mozilla or Netscape hired developers should spend time on this.

Agreed. I also don't think we should be subjected to pages of opinion within
bugzilla. I think the bugzilla pages should be limited to facts which help
developers fix real bugs, not opinion about whether to implement a feature.
Granted, I just let fly an opinion, but... Password protection is a legally
loaded issue. I'm not against implementing it but I think the debate as to
whether or not to have it should be taken up elsewhere. 

Comment 59 ericr 2001-02-11 12:46:39 PST
I really want Profile passwords to be implemented, even if it does not really 
secure the files.
Comment 60 ericr 2001-02-12 10:54:36 PST
I think it is clear that many people want this protection feature.  Like any
security feature, it can be overcome, in this case fairly easily.  But I know
the people around me and I know it would make me feel secure.

Also someone had claimed that password protection does not work after 4.5.  This
is not true!  It may not be documented for newer versions, but it still works. 
I am running 4.75 WITH password protection enabled.  I enabled it at the
following page:
http://home.netscape.com/communicator/v4.5/passwords/index.html
Comment 61 Henrik Gemal 2001-02-12 14:40:13 PST
I'll repeat what I said earlier:
"If someone want to implement this, go right ahead. I dont think that either 
Mozilla or Netscape hired developers should spend time on this."
Comment 62 Albert R. 2001-02-12 15:51:59 PST
Is it possible for a dev to work on this after Moz1.0 comes out?  I agree that 
valuable time should not be spent on this while major bugs/issues need to be 
ironed out, but I think people are going to demand this feature sometime.  
Windows 9x isn't going away any time soon, so we need a non-OS dependent profile 
protection feature.
Comment 63 timeless 2001-02-12 21:48:24 PST
reassiging to nobody, it's clear that NSCP/Mozilla.org do not intend to fix 
this bug.  Please Don't spam this bug. If you have a patch I'll work on getting 
it reviewed and considered.  I think that all relevant issues have already been 
beaten to death.
Comment 64 Boris Zbarsky [:bz] (TPAC) 2001-04-03 17:07:17 PDT
*** Bug 74636 has been marked as a duplicate of this bug. ***
Comment 65 Cody Petry 2001-04-29 09:41:36 PDT
Well guys changing the arch. code of the profile manager wouldnt be such a bad
idead, considering that the profile manager doesnt even work to start with. I
like that idea.
Comment 66 cmorley 2001-05-26 07:23:27 PDT
The incredible arrogance of some of you is mind baffling.  Just give the people 
what they want!  You guys were awful quick to stick us with those damn 'salted' 
directories and NO one asked for those!  Now, when we (the actual users.. 
remember us?) ask for a simple password implementation ala N 4.5-4.7 you scoff. 
 No one's asking to keep Joe-hacker out, damn it.  Just to keep "honest people 
honest".  The adults in the house may (and often do) have sites they visit that 
they don't want 'little Johnny' to stumble across.  Now if little Johnny can 
hack through all those computer files to read your prefs, he can damn well find 
these places on the web all by himself. Same goes for pref-type bookmarks at 
home and work.  Some of you should get off you high horses once in a while and 
talk to the 'regular' people.  You want all those N4.7 users to migrate to Moz, 
then you better listen to what they want.
Comment 67 Georg Meyer 2001-05-26 08:21:58 PDT
I applaud you cmorley. Nothing to add from my side. If I would be able to do it,
I would, but sadly I´ve no programming skills at all. So all I can do is to vote
for this (Which I did and hopefully more will).

George
Comment 68 Michael Hearn 2001-05-30 12:12:01 PDT
Oh please, stop bickering! I can do this if somebody who knows C can help me.
Basically all I need is for the nsIProfile object to call a JavaScript function
on startup and pass the name of the selected profile to it. If it returns true
continue, if false, abort the application start. It'd take, what, 2 seconds?
Please, can anyone help me with this?

thanks -mike
Comment 69 Michael Hearn 2001-06-01 10:28:10 PDT
OK, I've got the support of Juraj Betak on this, it's coming on nicely. Setting
assigned to moi

-mike
Comment 70 Michael Hearn 2001-06-04 14:12:59 PDT
CCing Juraj Betak, my netscape contact for this.

Juraj - that profile.dll you sent me doesn't appear to have made any difference.
I get a message about auto-registration problems in the console on startup, but
password.xul is never loaded. I'm using a nightly ID: 2001053104, is this OK?

Basically I have done all the other work on this bug now, we have a nice shiny
new window for setting/removing the password, and the password prompt dialog,
and the code to tie it all together. Just need to solve this, and add SHA1
digests - and it's done! Presto.

----- 

Oh yay, apparently I'm not "sufficiently empowered" to update pretty much
anything about this bug. Sigh.
Comment 71 jbetak@netscape.com (away - not reading bugmail) 2001-06-05 00:15:54 PDT
Mike, 

please let me know, what you would like to change about the bug. 

I'm suspecting that the problems you are seeing are due to the fact that you 
are running a nightly build. They are all compiled as "distributable" binaries 
and I gave you a "debug" library, as this was the most convenient thing to do. 

I took the liberty of making assumptions about your dev enviroment. I'll run a 
distribution build tomorrow and check that the DLL runs with a nightly before 
handing off to you. I can show you how to apply the patch in your local build 
and how to recompile the profile.dll on your machine, if interested. This would 
give you a "larger action radius". Do you have access to MS Visual C++? Even an 
older version (5.0) will do.

BTW I'll be out of town from June 6 to June 12, I'll be checking my bugmail 
though.
Comment 72 Michael Hearn 2001-06-05 10:24:27 PDT
Hehe, sorry Juraj, my dev environment doesn't exist - that's why I need your
help so badly! I don't know C++ (I'm a Delphi/Python guy myself), and as I run
off a 33.6k modem getting the Mozilla source isn't really an option! And no
sorry, I've never seen or used a copy of Visual C in my life :( One of the
things I love about Mozilla is it's one of the few big open source projects I
can contribute to without having to wrestle with a C compiler! I'm going to
learn it though ... one day :)

Anyway, if you could send me a version that will work with the nightlies that'd
be good thanks. All I wanted to change about the bug was to assign it to me,
remove the helpwanted and whiteboard text and change the target milestone to
0.9.2, which seems reasonable I think.

BTW - if you're going to recompile you could add code to check whether the
password.xul file needs loading first. Basically, if the "password" value exists
under the profile key in the registry then it needs to be loaded. Should the
password dialog stay open if they get it wrong, or try and quit the app, or try
and hand control back to your code? I can do the first two without any extra
help, but if we want the user to reappear on the Profile Manager window for
instance then we need a bit more work first.

thanks -mike
Comment 73 jbetak@netscape.com (away - not reading bugmail) 2001-06-05 20:23:25 PDT
per mike's comments:

-reassigning to mhearn@subdimension.com
-clearing whiteboard status
-targeting 0.9.3 (0.9.2 is a special milestone, only a= checkins are allowed)
Comment 74 jbetak@netscape.com (away - not reading bugmail) 2001-06-05 20:25:57 PDT
Created attachment 37322 [details] [diff] [review]
very preliminary,  work-in-progress patch for mike's use
Comment 75 Michael Hearn 2001-06-06 11:44:54 PDT
Good stuff, thanks Juraj, but like I said, I can't compile mozilla... sorry

BTW, what does the XULWindow.Run() method return? Is there a way of returning
data from XUL to native code?

thanks -mike
Comment 76 jbetak@netscape.com (away - not reading bugmail) 2001-06-08 14:10:44 PDT
mike -

the appshell Run() method is to my knowledge an just event loop. This might be 
the right place to look at to answer your question:

http://lxr.mozilla.org/seamonkey/source/xpcom/appshell/eventloop/xp/nsCBaseLoop.
cpp#53

The return value is only a success/fail indicator. I don't think that the 
CreateTopLevelWindow() method provides for your needs. We need to extend the 
nsIProfileInternal interface. You can then get a reference to the profile 
manager object from your JS script and set some state value we could then 
evaluate in nsProfile.cpp. Have a look at createProfileWizard.js to get an 
idea, how this could be accomplished:

http://lxr.mozilla.org/seamonkey/source/profile/resources/content/createProfileW
izard.js

Can you pop up your dialog using the new DLL? We could get to the registry and 
interface stuff, when I get back...

Just a side note: can you try to mark the bug status to assigned?
Comment 77 Michael Hearn 2001-06-09 08:35:16 PDT
Thanks Juraj [I've just set it to assigned now, hopefully it'll commit]

I tried the last profile.dll you sent with a nightly that was only 1 different
to the one you were using, but no luck, the Start Mozilla button in the profile
manager option didn't seem to do anything. I've got the 0.9.1 build now, so now:

- either you can send me another (sorry) version of profile.dll that works with
0.9.1, or tell me how to get the one you sent working, 'cos I've tried and failed.
- or as the patch is done on the XUL/JS side I could simply send it to you
(attach it to this bug) and you could check it all works and then we can either
submit it as-is or work on it some more.

Which is better for you, as I'm OK with either

I'll look at that LXR link you sent
thanks -mike
Comment 78 Mike Jaques 2001-06-11 03:26:12 PDT
Created attachment 37881 [details]
outlook express password disclaimer, which we should have something similar to.
Comment 79 Michael Hearn 2001-06-11 11:03:20 PDT
No problem Mike, my patch already has such a disclaimer :)

thanks for the screenshot though -mike
Comment 80 jbetak@netscape.com (away - not reading bugmail) 2001-06-11 22:00:33 PDT
mhearn,

(disclaimer: I apologize for the use of the email alias, it's a popular NSCP 
practice).

I'm at a loss, why you'd still fail at displaying the password popup with the 
latest DLL. Have you tried the May 31 nightly? You'd need to exchange the 
profile.dll and comm.jar to replicate my test environment. 

I could understand however, if your XUL file is not popping up. The 
CreateTopLevelWindow() method is quite unforgiving in my experience, it took me 
quite a while to come up with the XUL code it approved of and actually rendered 
in a nightly. 

I'd be happy to help with back-end integration, could you just attach the 
XUL/JS/DTD files you are working on to this bug? Also, you wouldn't happen to 
have some screenshots, would you? I'm sure you are using some testbed while 
working on the new UI, it'd be great to have a peek at it...

Comment 81 Michael Hearn 2001-06-13 12:28:45 PDT
Ok Juraj, (forgive me for not using email names, it seems a bit wierd to an
outsider)

I'm attaching a zip containing all the modified files. No I haven't tried the
May 31st nightly, I'm probably going to stick with 0.9.1 now as I can't keep
downloading nightlies on my modem (takes about 1.5 hours each time). Anyway, it
works with 0.9.1 so hopefully the backend shouldn't be hard to do.

thanks -mike
Comment 82 Michael Hearn 2001-06-13 12:49:33 PDT
Created attachment 38283 [details]
First XUL/JS/DTD patch for profile passwords
Comment 83 Michael Hearn 2001-06-13 12:52:58 PDT
Created attachment 38284 [details]
(doh!) This time hopefully it will upload properly.
Comment 84 bclinger 2001-06-30 15:55:07 PDT
Hey, I'm ignorant about this, but I wanna see profile passwords!!!!!!!!!! Thank
you and please call again. At my level, home/home-office user, just a password
for profiles (as in 4.7x) is more han enough. If I wanna encrypt something, then
I'll encrypt it myself. The real need is to keep the kids from messing with my
settings. Heck, if it is important mail, it'll be done via USPS, as Internet
email is far from secure.

Ben Clinger, bclinger@yahoo.com
Comment 85 jbetak@netscape.com (away - not reading bugmail) 2001-07-03 01:29:57 PDT
mike,

yes - sorry I was sidetracked by some other things - the 0.9.2 release/branch 
has taken its toll. I was also asked to shift my focus from the UI area into 
general i18n bug fixing. I'll definitely help you with the backend and maybe 
even with the landing of this feature. Once we have a complete patch, it might 
also be advisable to find a UI/XPToolkit sponsor for this.

The patch looks good at a first glance, I'll try to integrate it into my tree 
today or tomorrow. We should still be on track for the 0.9.3 release.
Comment 86 Michael Hearn 2001-07-03 10:25:13 PDT
OK thanks Juraj, glad you're back on the case
Comment 87 jbetak@netscape.com (away - not reading bugmail) 2001-07-09 14:48:12 PDT
Created attachment 41678 [details] [diff] [review]
converted mhearn's contribution into a CVS patch
Comment 88 jbetak@netscape.com (away - not reading bugmail) 2001-07-13 18:04:35 PDT
Created attachment 42267 [details] [diff] [review]
initial backend integration (cvs diff -N -u -w -b profile)
Comment 89 jbetak@netscape.com (away - not reading bugmail) 2001-07-13 18:08:12 PDT
Created attachment 42268 [details]
couple of zipped screenshots
Comment 90 jbetak@netscape.com (away - not reading bugmail) 2001-07-13 18:45:50 PDT
mike,

here are the binaries for you to test with: 
ftp://alex:alex@betak.net/MozPass.zip

I check that it works with the 07-12-2001 Mozilla nightly. With little luck it 
might also run with whatever nightly build you are currently runnig...
Comment 91 Peter Lairo 2001-07-14 03:13:38 PDT
for some reason the last two attachments cannot be viewed or downloaded in build
2001-07-13 (bug?)
Comment 92 Michael Hearn 2001-07-14 09:33:17 PDT
Hey thanks Juraj, it's coming on well :) Do you have anyone to r and sr?
Comment 93 jbetak@netscape.com (away - not reading bugmail) 2001-07-14 11:29:36 PDT
Peter: I can email them to you, if needed. I just checked on my W2K machine and
build 2001071304 has no problem displaying the attachments. Do you have a
zip-compatible application registered with the OS? Alternatively, you could play 
with the 'Helper Application' preferences.


mike: I'm assuming that you were able to test the functionality on your machine.
Some people had trouble downloading the binaries off my ftp server and I was not
sure, whether you managed. 

The patch is fully functional in its current form and I've attempted a minor
clean-up, but this might still require heavy mopping. For one, I'd like to
change some things in profilePassword. I could think of using a unified way of
parameter passing - through a parameter block. The other thing that might have
to change it somewhat is the password profile layout and the information icon on
the password entry screen should go too. 

On another hand, we've lost enough time already and should get an initial review
now to address all issues at once. It would be great, if Ben Goodger had some
cycles. He is the reporter of this bug and hopefully still has a marginal
interest in this. You could also try to pester him, timeless and mpt on IRC ;-)

ben: could you please glance over mike's XUL design? 
cc'ing mpt for initial UI review, ccarlen and sspitzer for critique of
nsProfile.cpp changes
Comment 94 Michael Hearn 2001-07-14 12:16:31 PDT
Sure Juraj, I just tested it and it worked fine. I know the XUL needs cleaning
up, it looks a little messy doesn't it. What's wrong with the picture in the
password prompt window though? I think it looks nice.

I'll pester ben about that, I don't think his netscape account works at the moment.

-mike
Comment 95 jbetak@netscape.com (away - not reading bugmail) 2001-07-14 12:36:18 PDT
Good to hear that mike! About the icon: I too think the dialog looks nicer with
than without it. However, it might not be compliant with the UI design
guidelines, since it's an information icon and we are expecting user input... I
think this is a good example of why we need to get mpt or ben to come up with an
initial review. We could incorporate the requested changes along with other
finishing touches.
Comment 96 Peter Lairo 2001-07-14 13:04:50 PDT
Thanks for sending me the screenshots. I have a few comments:

1. the "i" icon probably has to go (it's not an Info box). Another icon would be
cool though (maybe a padlock).

2. on the profile manager, maybe the button "set profile PW" should be slightly
distanced from the other three buttons, since create, edit and delete a profile
are thematically somewhat different.

3. in the PW profile dialogue: the 2 fields where the user enters his PW twice
should be left-aligned.
4. in the PW profile dialogue: there needs to be a "Cancel" button in case the
user panics and wants to back out while being sure nothing was changed (the OK
button would make me think that whatever error/chaos I created was now
irreversibly set in stone).
5. in the PW profile dialogue: the UI for adding, changing or removing passwords
should be like: Prefs - privacy & security - master password - change password
(old PW / new PW / new PW again). That covers all bases: 
  (1) new PW: leave "old" blank, 
  (2) change PW: type old PW in old PW, type new PW in new & again
  (3) remove PW: type old PW in old PW, leave new & again blank
Not only is this consistent with the rest of the app, it is also more intuitive
(I think many apps use this method = recognizability).
Comment 97 Matthew Paul Thomas 2001-07-14 13:32:55 PDT
passwordDialog.jpg:
1.  This alert, like all alerts, should not have a title -- since that would 
    just slow down the ~10 percent of users who read the title because they were 
    misled into thinking that it would say anything useful beyond what is
    already in the alert itself, when (as always) it does not.
2.  The `i' icon is for alerts which provide information (e.g. `The text
    "coronation" was not found'), it is not for asking for passwords. We don't
    have a standard icon for security alert boxes currently, so you shouldn't be
    using an icon at all.
3.  The `OK' and `Cancel' buttons are off-center. You should be using
    OkCancelOverlay.xul or whatever it's called.
4.  `OK' should be `Log In'.

passwordProfile.jpg:
5.  A dialog should have the name of the command as its title, not a sentence,
    and definitely not a sentence ending in a colon. Try `Change Profile
    Password'.
6.  Wherever you feel the need to make part of a UI label bold or italic, you're
    probably doing something wrong. In this case, you should be using a
    miniature of alert-icon.gif at the start of the label, rather than saying
    `Warning:'.
7.  Failing that, there should be a space between `Warning:' and the rest of the
    text.
8.  Your description is too long for humans to be bothered reading. Shorten it
    to two sentences or fewer. Sorry I can't offer such a description at the
    moment, I'm too tired to think.
9.  Remove both of the separators. They're more ugly than useful.
10. The whole `Please enter your new password here ...' sentence should be
    completely unnecessary, but it's not. To make it unnecessary, fix points
    11, 13, 14, and 15 below.
11. The Change Password dialog must include a field for entering your old
    password. Otherwise, if you left Mozilla running unattended, someone else
    could change your password (without even knowing what it was) so that you
    couldn't access your profile.
12. The left edges of the password fields should be aligned. The right edges of
    the field labels should be aligned.
13. The dialog must have a `Cancel' button, in case you decide that you don't
    want to change your password after all.
14. The `Set Password' and `OK' buttons should be one and the same button.
15. The `Remove Password' button will mislead some people into thinking that
    they need to click it before entering their new password. The button should
    probably be labelled `Stop Using Passwords' instead.

profileManager.jpg: looks fine (apart from basic profile manager UI yuckiness
which is nothing to do with this bug).

Legal disclaimer: None of the above UI advice should be construed as expressing
or implying any approval of inclusion of this `feature' in the Mozilla trunk.
Comment 98 Peter Lairo 2001-07-14 15:54:05 PDT
mpt: what about my suggestion to make the PasswordProfile look like the "Prefs
-> privacy & security -> master password -> change password" dialogue?

About the long description: I suggest to just take out the third sentence.
Comment 99 Peter Lairo 2001-07-14 15:56:12 PDT
Created attachment 42308 [details]
Set Password Screen from Master Password in the preferences (as an example how it could look).
Comment 100 timeless 2001-07-15 00:20:27 PDT
Create Profile, Rename Profile, Delete Profile.

'Password Profile' ('Lock Profile' -- this has problems because in some cases 
the user might want to Unlock the profile or change the password), 'Restrict 
Profile' would be in the spirit. 'Profile Password' would probably not be in 
the spirit of %s Profile ... but it would be better English...

Perhaps you should move the button to the left of 'Start Mozilla'.

If you're going to give the 'Please enter your profile password' dialog a title 
it should be the profile name, because it's the one important and relevant 
piece of information missing from your dialog.

The previous suggestion probably applies to both dialogs.

Password protecting your profile doesn't encrypt your _impersonal_ data either. 

The next sentence is _very_ misleading:
It ?may? still be possible to access your data without knowing _the_ password.

This is hopefully an accurate statement:
It is possible to access the data without knowing this password.

However I'm not sure it belongs in the dialog. Hence my next suggestion:
The change password dialog should include a help button (okcancelhelp ?).  It's 
clear you will need to document this feature.

hint about the layout of multiple input fields, use a <grid/>

Instead of a remove password button you could have text akin to 'If you do not 
wish to require a password to use this profile leave the new password fields 
blank.'

I'm not sure i like login, continue might be better, you aren't logging into 
anything, we've spent a lot of time explaining that this performs no real 
locking.  However I agree that OK should be replaced.

I don't like the use of 'your', it reminds me of blake's crusade against 'my'. 
My Profile, My Sidebar, My Password, My Mail. Your Profile, Your Sidebar, Your 
Mail.

The/this are more accurate because profiles can still be communal or shared.

The w2k logon dialog just says Password: which seems good to me.

<title>Foo Profile</title>
<label>Password:</label><input type=password/>
<okcancelhelpbuttons/>
Comment 101 Michael Hearn 2001-07-15 10:14:20 PDT
Ouch, that is a lot of comments. OK a few are unneccesary as would have been
obvious if the patch had been applied.

1) Old password is unnecessary as the password query dialog is used instead
before you can progress onto the set/remove password dialog.
2) The label: Personally I think it's better for people to be informed, if they
can't be bothered reading it then that's their problem. However, I will look at
changing it to be more accurate
3) The picture: I'll see if I can find any more appropriate icons for the
dialogs, however if there isn't one for now it stays until there's a little
padlock or something.
4) Remove password: How is "leave the new password field field blank then click
Set Password" simpler than "click Remove Password"? 
5) My/Your: largely irrelevant I'm thinking, Microsoft established (at least on
Windows) that personal things begin with My - My Computer, My Documents, My
Music etc.

Finally:

"Legal disclaimer: None of the above UI advice should be construed as expressing
or implying any approval of inclusion of this `feature' in the Mozilla trunk."

Then what does it mean? I actually worked quite **** this "feature" and at
least 30 people would like to see it in the trunk. So what gives? Perhaps you
should install the patch and try it yourself.


Don't get me wrong, I don't mind advice, but some of these points seem to be
rather subjective. I mean, I like the separators, I think they make it easier to
pick out the individual sections.

Anyway, I'll change some of those things and reattach another version of the
patch when I get some time.
-mike
Comment 102 Matthew Paul Thomas 2001-07-15 12:30:47 PDT
I apologize for not being able to apply the patch -- I don't have CVS installed
currently, let alone the bandwith with which to keep a Mozilla tree up to date.
Since the screenshots were attached to this bug after the patch was, I
reasonably assumed that the screenshots were current. Please attach new
screenshots if you want further UI advice (preferably after making all or most
of the improvements described above).

As for the legal disclaimer, just because 29 people want this doesn't mean that
I am required to agree with them. Nor does it mean that the feature will
necessarily be immune from legal complaints later on, which I have no desire to
be a part of. My interest in this bug is solely that IF this thing is fully
implemented, and IF the module owner is prepared to accept it, and IF it is
included in the Mozilla trunk, then it should have a professional-quality UI.

> 1) Old password is unnecessary as the password query dialog is used instead
> before you can progress onto the set/remove password dialog.

Please don't do that. Nobody expects the Spanish Inquisition. If you know darn
well that you're going to be putting up two alerts/dialogs in a row, as you do
in this case, you have a duty to merge them into one so as not to annoy people.

> 3) The picture: I'll see if I can find any more appropriate icons for the
> dialogs, however if there isn't one for now it stays until there's a little
> padlock or something.

Please don't do that. If you leave in the (i) icon, you're not only making the
UI worse for this alert, you're making it worse for every other alert in every
other app which uses that icon, by confusing the user's understanding of the
meaning of the icon. Just don't have an icon at all.

Timeless is right about the `Your' business. He's also right about including the
profile name. I suggest making `Profile: {name of profile}' the top row of the
<grid> in all three windows: the dialog where you set your password initially,
the dialog where you change your password, and the alert where you enter your
password when `logging in' to your profile.
Comment 103 Conrad Carlen (not reading bugmail) 2001-07-16 06:45:03 PDT
Wow, thanks for doing this. In terms of the UI, would it make sense to have,
instead of a "Set Profile Password" button in the dialog, a "Properties" button?
One of these property pages would, of course, be for passwords. There are other
properties which could be added as well (locales, roaming, etc).

Now, a few things about the code: 

(1)
In profilepassword.js, profilePasswordGetPassword, profilePasswordSetPassword,
and profilePasswordRemove should not be accessing the registry. The point of the
profile mgr backend is to provide that sort of data and hide its storage format.
The registry keys for the profiles should be considered private - only accessed
by the backend. What you should do is put accessors on nsIProfileInternal and
use those.

(2)
@@ -686,7 +695,7 @@
             rv = ProfileExists(currProfileName.get(), &exists);
             if (NS_FAILED(rv)) return rv;            
             
-            if (!exists) {
+            if (!exists || !Authenticate(currProfileName.get())) {
                 PRInt32 num5xProfiles = 0;
                 PRInt32 num4xProfiles = 0;

This isn't right. If exists is false at that point, we are going to set the URL
string so that the profile UI is brought up. The user will then have to
authenticate when selecting a profile from the UI. You only want to call
Authenticate() from the backend when it would call SetCurrentProfile() without
putting up UI. What you want is this:

if (!exists) {
  // no change
}
else {
  if (!Authenticate()) {
    profileURLString = PROFILE_SELECTION_URL;
    return NS_ERROR_FAILURE;
  }
  rv = SetCurrentProfile(currProfileName.get());
  }
}

(3)
@@ -494,6 +495,14 @@
                 rv = curProfileDir->Exists(&exists);
             if (NS_FAILED(rv) || !exists)
                 profileURLStr = PROFILE_MANAGER_URL; 
+
+            rv = GetCurrentProfile(getter_Copies(currentProfileStr));
+            if (NS_FAILED(rv) || (*(const PRUnichar*)currentProfileStr == 0)) {
+              return NS_ERROR_FAILURE;
+            } else {
+              if (!Authenticate((const PRUnichar*)currentProfileStr))
+                profileURLStr = PROFILE_MANAGER_URL;
+            }

Same story here as with (3) - check the value of exists.

(4)
+    if (isNewProfile)
+    {
+      profileItem->hasPassword = PR_FALSE;
+    }
+    else
+    {
+      profileItem->hasPassword = aProfile->hasPassword;
+    }

Lose the curly braces, please.

(5)
In nsProfileAccess::UpdateRegistry, two instances of
if (NS_FAILED(rv)) return rv; were added. Neither of them should be there. The
value of rv has not changed since that check was done above.
Comment 104 Henrik Gemal 2001-07-16 07:41:24 PDT
For the properties dialog please see:
http://bugzilla.mozilla.org/show_bug.cgi?id=25196
Comment 105 jbetak@netscape.com (away - not reading bugmail) 2001-07-16 08:54:05 PDT
Conrad:
thanks for your comments and the careful review  - I'll revise the backend and 
incorporate the requested changes today or tomorrow.

mhearn: 
please don't get discouraged, you've done a great job! Honestly, I didn't 
expect the initial reviews to arrive this soon and was pretty impressed with 
both their volume and quality. Please realize that this process is quite the 
norm and this bug will require some more work, as I've attempted to indicate on 
Friday. This is a functional extension (feature) and we are quite late in the 
development process; it's natural for people to show restraint. Yet it is 
crucial to offer a patch, which complies with commonly recognized Mozilla UI 
and coding guidelines and which has been reviewed by domain experts to be 
considered for inclusion into the trunk before the 1.0 milestone.
Comment 106 Conrad Carlen (not reading bugmail) 2001-07-16 09:31:24 PDT
> please don't get discouraged, you've done a great job!

I'll second that :-) As you can see from the long history of this bug, this
feature was debated forever, and then assigned to nobody because it wasn't on
the plate of any NS engineer. mhearn -  that you stepped up with a patch of this
significance re-affirms my faith open source :-)
Comment 107 Michael Hearn 2001-07-17 14:08:21 PDT
juraj: don't worry, I'm not getting discouraged :) I've implemented most of
those things that mpt and timeless brought up, I'll upload a new patch soon.
Below is a list of things changed.

Things marked with OK are done.

mpt:

passwordDialog.jpg:
OK
1. This alert, like all alerts, should not have a title -- since that would just
slow down the ~10 percent of users who read the title because they were misled
into thinking that it would say anything useful beyond what is already in the
alert itself, when (as always) it does not.

OK
2. The `i' icon is for alerts which provide information (e.g. `The text
"coronation" was not found'), it is not for asking for passwords. We don't have
a standard icon for security alert boxes currently, so you shouldn't be using an
icon at all.

Already using overlay.
3. The `OK' and `Cancel' buttons are off-center. You should be using
OkCancelOverlay.xul or whatever it's called.

Not doing as would involve changing overlay
4. `OK' should be `Log In'.

passwordProfile.jpg:
OK
5. A dialog should have the name of the command as its title, not a sentence,
and definitely not a sentence ending in a colon. Try `Change Profile Password'.

? Unsure of what icon to use here ?
6. Wherever you feel the need to make part of a UI label bold or italic, you're
probably doing something wrong. In this case, you should be using a miniature of
alert-icon.gif at the start of the label, rather than saying `Warning:'.

OK
7. Failing that, there should be a space between `Warning:' and the rest of the
text.

OK
8. Your description is too long for humans to be bothered reading. Shorten it to
two sentences or fewer. Sorry I can't offer such a description at the moment,
I'm too tired to think.

Removed bottom separator only
9. Remove both of the separators. They're more ugly than useful.

OK
10. The whole `Please enter your new password here ...' sentence should be
completely unnecessary, but it's not. To make it unnecessary, fix points
11, 13, 14, and 15 below.

OK
11. The Change Password dialog must include a field for entering your old
password. Otherwise, if you left Mozilla running unattended, someone else could
change your password (without even knowing what it was) so that you couldn't
access your profile.

OK
12. The left edges of the password fields should be aligned. The right edges of
the field labels should be aligned.

OK
13. The dialog must have a `Cancel' button, in case you decide that you don't
want to change your password after all.

OK
14. The `Set Password' and `OK' buttons should be one and the same button.

OK
15. The `Remove Password' button will mislead some people into thinking that
they need to click it before entering their new password. The button should
probably be labelled `Stop Using Passwords' instead.

timeless:

OK
If you're going to give the 'Please enter your profile password' dialog a title 
it should be the profile name, because it's the one important and relevant 
piece of information missing from your dialog.

OK
The next sentence is _very_ misleading:
It ?may? still be possible to access your data without knowing _the_ password.
This is hopefully an accurate statement:
It is possible to access the data without knowing this password.
    
    
=====================================================================


Just a few things though:

mpt, I meant the zip patch actually, which can be applied to 0.9.2 just fine. I
also don't have the bandwidth, time or skills to maintain a whole Mozilla CVS
tree, and I also don't know any C, so don't worry you can still try the patch if
you want.

--snip--
As for the legal disclaimer, just because 29 people want this doesn't mean that
I am required to agree with them. Nor does it mean that the feature will
necessarily be immune from legal complaints later on, which I have no desire to
be a part of. My interest in this bug is solely that IF this thing is fully
implemented, and IF the module owner is prepared to accept it, and IF it is
included in the Mozilla trunk, then it should have a professional-quality UI. 
--snip--

I'm confused, what legal complaints? I don't want any of them either...
Comment 108 Michael Hearn 2001-07-17 14:26:59 PDT
Created attachment 42606 [details]
Second GUI patch. Just unzip the files into the right place in the comm\profile and en-us\profile directories
Comment 109 timeless 2001-07-18 01:04:48 PDT
I think mpt's disclaimer is because he as the default uid assignee is offering 
advice and doesn't want his advice to be construed as support for integrating 
this feature into the tree.

Major trivial nits: Please change new files to reference MPL not NPL.

so your new files should look something like this:
<!--
 
  The contents of this file are subject to the Mozilla Public
  License Version 1.1 (the "License"); you may not use this file
  except in compliance with the License. You may obtain a copy of
  the License at http://www.mozilla.org/MPL/
 
  Software distributed under the License is distributed on an "AS
  IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or
  implied. See the License for the specific language governing
  rights and limitations under the License.
 
  The Initial Developer of the Original Code is Michael Hearn.
 
  Contributor(s): Michael Hearn (mhearn@subdimension.com)

-->
I'm not sure about All Rights Reserved. (for the js file the change is 
equivalent ...)

the web appears to be split about express vs. expressed (although google hits 
for expressed are all legalease and google hits for express turn up random 
bits)

<box> usage. we just attacked the tree to remove most traces of <box> most 
likely you want <hbox> (for <box orient="vertical"> you want <vbox>) see 
npm.seamonkey or npm.xpfe i think for more information.

id="pass.txt", i'm pretty sure this doesn't fit our naming conventions.. i 
could be wrong.

Considering intl, i think replacing
		  <!-- warning text -->
		  <html width="300">
		    <html:b>&passwordWarning1.label;</html:b><html:br/>
		    &passwordWarning2.label;
		  </html>
with <html width="300">&passwordWarning.html;</html> might be better. make the 
English version use the <b> and <br> as you intend.

we should have a way to allow string replacements for the ok buttons... I'll 
rummage
		<button label="&okButton.label;" default="true" 
class="exit-dialog" oncommand="profilePasswordDoSet()"/>
		<button label="&cancelButton.label;" class="exit-dialog" 
oncommand="window.close()"/>
		<button label="&passwordRemove.label;" 
oncommand="profilePasswordRemoveButton()" 
accesskey="&passwordRemove.accesskey;"/>

    
window.openDialog('chrome://communicator/content/profile/passwordProfile.xul', 
'_blank', 'chrome,modal=yes,titlebar=yes', name);

'_blank' should probably be the name of the dialog...

you should probably add code to function DoEnabling()

I'm not sure I like Access Denied. Nor am I sure i like Please try again.
profilePasswordIncorrect=Access Denied: Sorry, but the password you entered is 
incorrect. Please try again.

I know I don't like 'password set operation' 
profilePasswordSetError=Sorry, an error was encountered during the password set 
operation. Please ensure you have used valid characters in your password.

please use a consistent indentation and no tabs (esp profilePassword.js) the 
modeline indicates 2 spaces, so I expect to see all indents mathching that.

could you explain how/why the try in 
function profilePasswordCancelFunc() {
is useful/needed/used

i'm not sure this is the correct or best way to do what you want:
if (window.arguments[0] == undefined) {

checking in dumps will get someone shot (not you since you aren't checking 
in, but ...):
} catch(e) { dump(e) }

bad: else after return.
	if (pass.indexOf(" ") != -1) {
		return false;
	} else if (pass == "") {
		return false;
	}
	
	return true;
consider something like:
  return (pass && pass.indexOf(" ") == -1)

else before return is kind of odd..., especially return before end of void 
function.
	if (promptService.confirm(window,title,string)) {
		profilePasswordRemove(window.arguments[0]);
		window.close();
	} else { 
		return;
	}
ignoring my second observation,
	if (!promptService.confirm(window,title,string))
		return;
	profilePasswordRemove(window.arguments[0]);
	window.close();

CARP LICENSE VIOLATION. afaik LGPL is not compatible w/ MPL. return to drawing 
board.  I'd suggest contacting the NSS people to see if mozilla already has 
something for this.

References: MozGlade, Curl.
Comment 110 Simon Lucy 2001-07-18 01:07:13 PDT
>Not doing as would involve changing overlay
>4. `OK' should be `Log In'.

No, you can override the caption on the dialog at run time, though the actual text should always be in some properties file somewhere.
Comment 111 Mike Jaques 2001-07-18 02:10:33 PDT
>This is hopefully an accurate statement:
>It is possible to access the data without knowing this password.

This would be even more accurate, and more inline with what MS Outlook states 
(its a good statement I must admit):

A password provides moderate security for your profile.  However, it
may still be possible for other users to access your profile without
knowing this password.

The MS statement on Outlook Express 5.5 is, and I quote:  
    You can require a password for this identity. This provides a
    moderate level of security. However, other users may still be able to
    see your data. For more information about security click, click Help.
end quote.
Comment 112 Mike Jaques 2001-07-18 02:13:28 PDT
nyah!!!!  nothing like quoting something and getting the quote wrong.  3am 
bugzilla posting should be forbidden, for me atleast.

The MS statement on Outlook Express 5.5 is, and I quote:  
    You can require a password for this identity. This provides a
    moderate level of security. However, other users may still be able to
    see your data. For more information about security, click Help.
end quote.

I got "click" happy,   scuse my spam.
Comment 113 Dan Mosedale (:dmose) 2001-07-18 12:21:52 PDT
timeless: I don't believe that LGPL code is necessarily incompatible with the
MPL.  You may wish to file a bug on Product: mozilla.org Component: misc 
Assigned-To: mitchell@mozilla.org with the particulars of the code in question.
Comment 114 timeless 2001-07-19 13:28:28 PDT
i filed bug 91384 and hecker's first response was to concur w/ my reading. Again
I'd suggest trying to use NSS's functions instead since they would be license
friendly (and will normally be available).  Otherwise we can try this again w/
the 'library' in a seperate file, i'll file a bug for that but I'm not sure if
it changes anything.

You could of course reimplement whatever encryption you're using, or implement
some other hashing algorithm (CRC32 is probably usable and I'd expect an
algorithm to be available in the public domain).
Comment 115 jbetak@netscape.com (away - not reading bugmail) 2001-07-20 00:13:20 PDT
Created attachment 42966 [details]
updated screenshots (zipped)
Comment 116 jbetak@netscape.com (away - not reading bugmail) 2001-07-20 00:15:07 PDT
Created attachment 42967 [details] [diff] [review]
cleaned-up patch
Comment 117 jbetak@netscape.com (away - not reading bugmail) 2001-07-20 00:22:36 PDT
mhearn:

timeless has a very valid point with the licensing issue he raised. I 
tentatively included dual licensing terms for profilePassword.js. However, we'd 
need the original author's consent to distribute under MPL. Could you please 
get in touch with him or alternatively start thinking about a different hash 
algorithm? 

I cleaned up the patch quite a bit and hope that this will bring us closer to 
r/sr. A lot of things moved from JS to the backend as requested by ccarlen. I 
don't have any binaries this time, my connection at home is pretty slow tonight.
Comment 118 Simon Lucy 2001-07-20 01:42:16 PDT
The LGPL as a library file connection may not be incompatible with the MPL, its less certain what the consequences of a source file licenced as LGPL would be.  If the originator wishes to licence a file under whatever other licence then that is naturally their right, but if its intended to be part of the Mozilla tree (aside from all arguments as to whether it should ever be incorporated into the tree), then it should be plainly licenced as the rest of the module of which its meant to be part.  In this case this is MPL only.

If code is being used from another source which is LGPL then the original author's permission for re-licencing under the MPL should be sought before its use in any form, patch or otherwise.
Comment 119 timeless 2001-07-20 03:05:41 PDT
the code is probably getting better (or i'm reviewing w/ less sleep)

please split if (NS_FAILURE(rv)) return ... across 2 lines -- this aids 
debugging.

the types for true and false are bool, PRBool is PR_TRUE and PR_FALSE (see 
prtypes.h).

of course whitespace should be consistently added (nsProfile.cpp has new code 
indetented 2spaces, and 4spaces).

Looking at the screenshots, I don't see a reason to verify the user wants to 
remove the password, removing the password doesn't cause dataloss except for 
the password which is the obvious consequence. assuming you must know the 
password to use this dialog to get that warning, then you will probably still 
know it 5s after you click remove password and decide to restore it by 
reentering it.

re licensing, if the author is willing to license it to mozilla.org as strictly 
mpl w/o requiring the lgpl piece (and the author can show clear title to the 
code -- fun) then that would of course be ideal...

I know virtually nothing about copyright law, but i'm going to assume based on 
the md5 notice that the author indeed has clear title, so then it's merely an 
issue of getting the author's consent.

Or we could look for someone else's MD5 algorith... 
http://www.fourmilab.ch/onetime/otpjs.html
I'll attach the version of that page, whose footer indicates:
'This document is in the public domain.'

If someone has the time to adapt the version provided w/in to the code 
currently proposed, ...
Comment 120 timeless 2001-07-20 03:08:40 PDT
Created attachment 42977 [details]
http://www.fourmilab.ch/onetime/otpjs.html This document is in the public domain.
Comment 121 (not reading, please use seth@sspitzer.org instead) 2001-07-20 10:55:53 PDT
is there a spec on mozilla.org for this new UI?
Comment 122 Peter Lairo 2001-07-20 11:25:15 PDT
The *standard way* to clear the password is to enter the old password and leave
the new password fields blank. I think we should do that here too. All that is
needed is to loose the "stop using passwords" button, and maybe add some text:
"To stop using passwords, enter your old password and leave the New Password and
Retype New Password fields blank." Although this text is likely not needed, as
it is also not used in the "Set Master PW" UI in prefs.

I also suggest to rename "Password" to *"New Password"* (and to *"Retype New
Password"*). This would be a more logical progression from the "Old Password" field.

Both these enhancements would also make the UI *consistent with the existing*
"Set Master Password" UI in the preferences.
Comment 123 Michael Hearn 2001-07-20 11:28:15 PDT
Ah OK, I'm now out of synch here. I had cleaned up the patch myself and made
many of the requested mods but i don't know how much juraj has done. Anyway I
have no time tonight. I'll be back in two weeks from now, if the hashing issue
hasn't been solved by then I'll look into getting simple hashing from NSS.

Peter, yeah OK then we can change that. But if I do it, it'll be a while for the
above reasons.

ooh i've just had my first bugzilla mid-air collision! This one is really
getting a lot of postings :)

thanks -mike
Comment 124 jbetak@netscape.com (away - not reading bugmail) 2001-07-20 11:38:58 PDT
timeless: thanks for skipping sleep to pour over the changes. I'll be polishing 
it some more this weekend... And thanks for pointing out this PD source for 
MD5, I might work on that as well as an alternative to the relicensing effort.

sspitzer: mpt was giving us some preliminary UI advice. I don't believe there 
is a formal spec.

mhearn: boy am I glad I posted the patch before you sent your updated version ;-
) Anyhow, I didn't change anything about the UI - I just had to move some 
functional pieces to the backend and consequently had to clean up the JS side. 
I've attempted to simplify and clean up things in the process, while going back 
to the coding issues timeless has raised.
Comment 125 malicose 2001-07-20 11:42:49 PDT
I agree with PLairo@cs.com's suggestions. That is, to clear a password by
entering the old password and leaving the new password fields blank. I think we
should do that here too.

On field renaming, I vote for "Password:", "New Password:", and "Cofirm New
Password:". As PLauro@cs.com indicated, a progression such as this is more logical.

As long as I'm commenting, kudos to everyone involved here as it's a testament
to me that personally critical features DO have a chance in the open source
environment.
Comment 126 Simon Lucy 2001-07-21 12:11:50 PDT
So far as I'm aware this hasn't been accepted by the module owner so I doubt it will be accepted into the trunk.  It can always be applied as a patch by those that think they should have it though.
Comment 127 jbetak@netscape.com (away - not reading bugmail) 2001-07-21 14:03:06 PDT
simon: you are right, we need to get past the licensing issue for the secure 
hash algorithm and address the remaining coding and UI nits. I'm working on a 
new version of the patch - ETA 07/23/2001
Comment 128 Conrad Carlen (not reading bugmail) 2001-07-21 14:34:02 PDT
> So far as I'm aware this hasn't been accepted by the module owner

As far as the back-end, which I own, I reviewed a previous patch. Juraj
addressed my concerns so I expect to give r= when the final patch is in. Since
this involves more front-end than back-end, you'll need to get Blake or Ben to
give owner r= for that.
Comment 129 Matthew Paul Thomas 2001-07-21 15:42:08 PDT
sspitzer: Perhaps 5 percent of Mozilla's UI is covered by specs, and about 4/5 
of that 5 percent is in mail/news. The UI for the rest of Mozilla flies mostly 
spec-less (and, might I add, it isn't noticably worse than mail/news as a 
result). So of the reasons for the module owner to reject this patch, lack of 
spec is not one of them.

mhearn: I see from the new screenshots that you are trying to make the Change 
Password dialog do double duty as the dialog for setting the initial password. 
Please don't do that. The title of the dialog (`Change Profile Password'), and 
the existence of the `Old Password' and `Stop Using Passwords' controls (even 
though they're disabled) makes that reuse look like a bad kludge.

Finally: `/!\ Danger, danger! Your new password has been set! Run for your 
lives!' Admittedly this is a bad bug in nsIPromptService (it uses the /!\ icon 
when it should be using the [i] icon), and not really your fault, but here you 
shouldn't be using an alert at all. If a user sets/changes their password 
successfully, you shouldn't be punishing her for it by putting up an alert like 
that. :-)
Comment 130 Peter Lairo 2001-07-22 02:04:40 PDT
mpt: having one dialogue called "change password" is OK in this case because you
are always "changing" the password:

- *change* password from "none" to a "new one".

- *change* password from "old" to "new".

- *change* password from "exiting one" to "none".

It is good to not confuse the user with too many different dialogues (in this
case). Also, it is *consistent* with the way passwords are handled under "Edit -
Preferences - Privacy & Security - Master Passwords - Change Password".
Comment 131 paj 2001-07-23 01:43:56 PDT
Hi, I'm the author the LGPL'ed JavaScript. Both MD5 and SHA-1 scripts are by me
with some modifications that I've been sent. They're based on the respective
standards. I can and do allow you to distribute the SHA-1 script under the MPL.
Because of the conditions on the MD5 specification, I can allow you to
distribute that script under the MPL only if you include the notice below.

The code that some people have mentioned is public domain is not legally so. The
MD5 part of the public domain page is written by someone else, and was not 
placed in the public domain. In any case the restrictions RSA place on the
algorithm clearly prohibit public domain MD5 code.



Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All rights reserved. 

                         License to copy and use this software is granted
provided that it is identified as the
                         "RSA Data Security, Inc. MD5 Message-Digest Algorithm"
in all material
                         mentioning or referencing this software or this
function.

                         License is also granted to make and use derivative
works provided that such works
                         are identified as "derived from the RSA Data Security,
Inc. MD5 Message-Digest
                         Algorithm" in all material mentioning or referencing
the derived work.

                         RSA Data Security, Inc. makes no representations
concerning either the
                         merchantability of this software or the suitability of
this software for any particular
                         purpose. It is provided "as is" without express or
implied warranty of any kind.

                         These notices must be retained in any copies of any
part of this documentation and/or
                         software. 
Comment 132 jbetak@netscape.com (away - not reading bugmail) 2001-07-23 11:18:26 PDT
adding Paul Johnston to the cc list...
Comment 133 jbetak@netscape.com (away - not reading bugmail) 2001-07-23 19:24:51 PDT
Created attachment 43312 [details]
screenshots of corrected UI - mpt could you please review this again?
Comment 134 jbetak@netscape.com (away - not reading bugmail) 2001-07-23 19:39:01 PDT
Created attachment 43315 [details]
one more change: widget alignment  and additional padding, dialogbox witdth is now fixed at 28em
Comment 135 jbetak@netscape.com (away - not reading bugmail) 2001-07-24 17:00:50 PDT
seems like we are missing the 0.9.3 train - pushing out to 0.9.4. 

Unless there are any futher complaints/suggestions about the most recent UI 
changes, I'll finalize and post the patch tomorrow.
Comment 136 Mike Jaques 2001-07-24 19:59:03 PDT
jbetak,  I know I stated this above, but I do have a small quibble with the 
wording of the disclaimer about security.  I think it would be a more accurate  
statement as follows:
   "A password provides moderate security for your profile.  However, it
    may still be possible for other users to access your profile without
    knowing this password."

If you want to add "Use of this feature is at your own discretion."  I wouldn't 
be opposed.

This falls inline with the MS statement on Outlook Express 5.5, which obviously 
is enough to put their lawyers minds at ease:
    "You can require a password for this identity. This provides a
    moderate level of security. However, other users may still be able to
    see your data. For more information about security, click Help."

Otherwise, great work to mhearn and jbetak.  Kudo's and thanks.
Comment 137 timeless 2001-07-25 00:57:10 PDT
I object to moderate. heck, I object to the entire suggestion. It's misleading 
if not utterly false.

if the entire profile was ROT13 encrypted or if the password was used to XOR 
encrypt the profile then we _might_ be able to claim 'moderate' protection.  

some people would say that ROT13 is laughable (none ~ laughable < moderate < 
reasonable). remember: what we're doing here is less than ROT13 for the entire 
profile.

MS's lawyers aren't our problem. The fact that the dod had to shut down .mil 
(heck, the whitehouse changed its static ip) because of IIS and codered should 
be considered more relevant than whatever MS's lawyers had to say about this 
tiny UI element.
Comment 138 Simon Lucy 2001-07-25 01:08:23 PDT
Further, if this feature is added to the tree there should be an easy and safe way for distributors to remove it.  Ideally this means a conditional build.
Comment 139 Mike Jaques 2001-07-25 01:31:19 PDT
> I object to moderate. heck, I object to the entire suggestion. It's
> misleading if not utterly false.

Um, ok, thats your opinion. My understanding of teh english language must be 
quite different then yours.  In your opinion a password isn't protection at all 
timeless, in my experience with novice to moderate computer users it's more 
then adequate to avert most peoples nosiness.

I find it sad that we keep having this discussion over the validity of this 
feature and whether it has merrit or not.  It's a very requested feature as 
seen by the votes, and no matter how much you say just because its wanted 
doesn't make it right, who are you to say what is right? Is anyone.  Even as an 
open source project the public should and DOES get the final say on a product 
or a part thereof it, it's your job as coders to respond to and code their 
wishes as much as your own desires, don't fool yourselves, your coding for 
hundreds of thousands of people here, not just a few thousand.  This part is 
wanted and will go ahead as is I hope, so build a bridge and get over it 
please. If you want to contribute and have the coding expertise DO SOMETHING 
ABOUT IT. ROT13, MD5, whatever encryption you want to include, just do it.  
Sure I would like to see the profile encrypted, but that comes down the road.  
For now, even insecure protection is better at stopping 80-90% of novice to 
intermediate computer snoopers.

As for Simon's comment, i guess a turn on flag could be added, but I would hope 
by default it would be turned on in mozilla and any future Netscape products.  
Otherwise, the point of adding it to the main product, which most people see, 
is lost and only less publically released specialty builds have it.

</end_rant>
Comment 140 (not reading, please use seth@sspitzer.org instead) 2001-07-25 01:47:48 PDT
this sounds like the "no security is better than false security" argument that
jar always talks about.
Comment 141 Simon Lucy 2001-07-25 05:52:15 PDT
I'd be more than happy to see personal security in this, I'm working on a 
product requirement now that includes that (its unlikely to be a Mozilla development though).  And that is the main point that it should be designed in from the beginning.  If an application is to take responsibility for the security of data from the operating system then it has to remove or prevent all other access by whatever route.  This implies private file systems or an encrypted database.

Neither of those are bad things.

In that sense the data is then application data and not personal data, if its
important for that data to be accessed by other applications then it belongs
in the regular file space with the regular security offered by the operating
system.

Waving a spurious login process at the user is misleading regardless of all
the caveats.
Comment 142 Peter Lairo 2001-07-25 06:20:23 PDT
<OT>
Please stop discussing the pros and cons of *simple password protection* in this
bug. The topic has already been excessively covered here. If you must, go to the
newsgroups to argue your points.
<OT\>
Comment 143 Matthew Paul Thomas 2001-07-25 07:13:49 PDT
jbetak: That UI is not perfect, but it is much improved and quite check-inable.
Thankyou.

Minor quibbles which you can fix if you like:
1.  The alert for entering your password when logging in should be wider, and
    should have the profile name in the alert itself rather than the title bar.
2.  `Retype password:' should be `Confirm Password:' (with a capital `P').
Comment 144 Simon Lucy 2001-07-25 08:40:14 PDT
My comments were about requiring this feature to be turned off if it ever makes
it into the tree, they were not off topic but relevant.
Comment 145 Michael Hearn 2001-08-13 14:31:55 PDT
Changed email address, since subD suddenly decided they can't be bothered
running email any more, damn them.
Comment 146 jbetak@netscape.com (away - not reading bugmail) 2001-08-15 23:07:54 PDT
Simon, I planned to incorporate your request to make this into a a removable 
extension. 

However, I'm running into some time constraints and was wondering, if anyone 
else would be willing to take up that challenge. I could post the latest patch 
reflecting mpt's most recent UI review form 07-25. If we could get this in as 
is (i.e. it's not a build-script-configurable extension), I'd polish up the 
patch one more time and start the r/sr process. I don't think I have the cycles 
to make it ready for 0.9.4 otherwise and would have to delay to 0.9.5.
Comment 147 Michael Hearn 2001-08-21 14:35:49 PDT
Damn slippage - can't make it for 0.9.4 so pushing back to 0.9.5

Juraj, is there any possibility of it making it into the tree without the build
on/off option. And if not, would it be switched on in trunk builds and Netscape
builds?

thanks -mike
Comment 148 jbetak@netscape.com (away - not reading bugmail) 2001-08-21 15:02:05 PDT
mike,

incidentally, I do believe that Simon is right and making this into an extension
is a good idea, since there might be vendors out there w/o the password
protection requirement or with a requirement to build their own security
features. They need to be able to turn off this feature in their builds. And I
agree, if this is to become an extension, we should lobby to turn it on in trunk
builds and Netscape commercial builds. 

Sigh, I'll try to post the patch this week. My apologies for the slippage - I'm
struggling with some Netscape-related bugs right now.
Comment 149 Simon Lucy 2001-08-22 07:10:00 PDT
I'd go a little further, I don't think this should go into the trunk
as anything else other than an extension.  After I've completed my
committment to build Beonex Win32 and if no one else has built the patches
as an extension then I'm willing to do it if for no other reason than
to avoid the slightest possibility of it getting into the default
build.
Comment 150 jbetak@netscape.com (away - not reading bugmail) 2001-08-22 07:37:34 PDT
>slightest possibility of it getting into the default build.

Simon, am I reading this correctly, when assuming that you'd not like to see 
this turned on in Mozilla trunk buids?
Comment 151 Peter Lairo 2001-08-22 08:00:51 PDT
Is it possible to have it in Mozilla/Netscape per default and still have it
easily removable by vendors who may not want to use it? If so, that would seem
to be the preferred way to do it.
Comment 152 Simon Lucy 2001-08-22 12:00:08 PDT
Well, as I don't want this in the build at all :-), personally, professionally
and for all sorts of reasons already exhaustively gone through I certainly
don't want it enabled by default.  I can't speak for what should be in a 
distribution such as Beonex, or Netscape but I believe Beonex has already
decided that its a bad thing.

Regardless of whether some think its a good thing, I believe its controversial enough to be an extension rather than a default.
Comment 153 Peter Lairo 2001-08-22 12:31:08 PDT
[OT]
Simon Lucy: please stop spamming this bug. You have repeated your standpoint
enough - this has been discussed to death here.

If the feature is easily added or removed then all interests are represented -
let the vendors decide.
[/OT]
Comment 154 Michael Hearn 2001-08-22 13:23:24 PDT
I would like to hearby officially disagree with Simon P. Lucy on this point. 
Both me and Juraj (and others) have worked hard on this feature and at least 32 
people don't think it's "too controversial" to go into the trunk. At the end of 
the day 99% of end users don't actually give a damn about encryption of 
personal data, which is why Windows doesn't bother encrypting My Documents and 
Hotmail has 180 million users despite bad security. Simple password protection 
with appropriate warnings is a feature that will enhance Mozilla/Netscape and 
if other distributions do not wish to use it then I don't have a problem with 
that. But I do think it should be on by default.
Comment 155 (not reading, please use seth@sspitzer.org instead) 2001-08-22 13:38:16 PDT
if it does land in the trunk (you should run it by staff@mozilla.org, perhaps
they can help resolve that issue), I suggest under mozilla/extensions.

it could be optionally built (or downloaded and installed as an xpi by the users
later.)

personally, I don't want this as part of mozilla.

"A false sense of security is worse than a true sense of insecurity."
Comment 156 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-08-22 14:16:57 PDT
Why aren't we using the cryptographic services of NSS, given that they're there
in the default build?  (You go as far as using SHA-1 to hash the password
itself, though you don't use NSS services for that, either.)   Until we do that,
I think referring to this as a "security feature" is dangerously misleading.  We
will get our lunch eaten by the security community, just as W9x password
protection has been berated in the past, because they will think that we should
know better.  They're right.

Of course, with the use of NSS to encrypt the profile data, I think this could
be a very worthwhile addition to the tree.
Comment 157 (not reading, please use seth@sspitzer.org instead) 2001-08-22 14:28:17 PDT
do we plan to encrypt all the users data?  (bookmarks, prefs, local mail files,
including summaries?)
Comment 158 Conrad Carlen (not reading bugmail) 2001-08-22 15:18:42 PDT
This discussion is now back where it was many months ago. If you believe as Seth
does, "A false sense of security is worse than a true sense of insecurity.", you
don't have to use it - I wouldn't. As long as this feature is optional, is not
on by default, and if somebody choses to use it, it's made clear that it is not
secure, I'm in favor of it. There are those who want this even though it is not
secure. How do we break this impasse?
Comment 159 (not reading, please use seth@sspitzer.org instead) 2001-08-22 15:43:52 PDT
if it was an extension, that could be optionally built (and optionally turned
on/off) that would solve impasse.

Comment 160 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-08-22 16:06:33 PDT
To put a password option in is to imply to users that the password provides
meaningful protection of their data.  What are you actually protecting against,
otherwise?  Someone _accidentally_ starting up the protected profile?

Why not actually encrypt the data, like wallet does (optionally, sigh) with its
data?  It's more work, certainly, but that's often the cost of actually solving
a problem.

As far as "break[ing] the impasse", you'll have to get it reviewed and
super-reviewed and checked in, I guess.  Given that both Seth and I have
expressed our distaste for this approach to "protection" of profiles, I expect
you'll have a hard time getting a super-reviewer to over-rule us, though I guess
it's possible.  (I'm happy to be overridden by drivers@, as well, but Seth might
not be.)  I don't think making it an extension/ is going to make me feel better:
 if it's going to be in the Mozilla tree, it should be The Right Thing.
Of course, we're way ahead of ourselves, as this patch isn't ready to go in
anyway: you can't just go writing to the application registry willy-nilly:
multi-user systems often have it unwritable by non-admin users.  You probably
want to find and use the profile registry instead, but let's get to actually
protecting the data before we worry too much about that.
Comment 161 James "Dexter" Akula 2001-08-22 16:26:24 PDT
Just my $0.02: I think this feature should be added and turned on by default
whenever it's ready for prime time.  I think a nice big warning when first using
it is enough to let Mozilla off the hook as far as not being secure goes.  It
will be sufficient to keep my sister from reading my mail.  Once it's in there,
I think the bug should remain open as efforts are made to add more "true"
security to Mozilla.  That way, when I download Netscape 6.3, my email suddenly
*will* be encrypted, and Netscape can add that to a little advertising blurb
along with "actually prints frames" and "no longer causes Quicktime to suck." 
Then everybody will be happy.

In other words, I think the big deal is that Mozilla not *settle* for cheopo
security when much of the technology to have real security is already in the
project.  There's no problem getting what you can in there when it's ready, though

Cat fish?

PS  I'm voting for this one.
Comment 162 Jason Bassford 2001-08-22 16:42:44 PDT
<OT>
This is not the place for continued discussion.  Once the code has been
developed (if it ever gets there) , then it needs to get approval as per the
regular channels.  Discussion as to the validity of the code should be carried
out elsewhere.  There is enough support for the feature, and interest on the
part of some developers, that work seems to be progressing.  If, in the end,
there isn't , then the coding will never be finished.  If it does get completed
then it will either be checked in or it won't.  Neither arguing for it, nor
arguing against it, is helping the overall process.

With all due respect, I would like to save my Inbox and have discussion in
BugZilla stop unless it is with respect to technical aspects of the code itself.
 Evangilzation, and it's opposite, can happen in Newsgroups.
</OT>
Comment 163 Håkan Waara 2001-08-22 22:42:08 PDT
I have to agree with Seth that this is probably not something we want in the
default builds (milestones, nightlies...).

Jason: discussing an approach to resolve this bug is perfectly valid in
bugzilla. If you don't want bugmail, remove yourself from CC.
Comment 164 Peter Lairo 2001-08-23 01:01:37 PDT
[OT]
.. and while we're at it, why don't all people that do want this feature remove
themselves from the CC list so those three who are trying to block it can have
their way (and continue to repeat that they "don't think it is a good idea" - we
know what you think, thank you).

Is it our priority to impress our geek peers with super-hyper 512 bit
encryption, or do we give the users what they are obviously asking for? Geek
users will understand the warning message and not use the feature if they
suspect that their geek colleagues will try to bypass it. All others will not
know how (or care) to bypass it. It's all about choice - nobody is forced to use
this feature. 

SUGGESTION: The feature should be *available* by default (under "manage
profile"), but the user is not asked to create/enter a password when creating a
profile. This way, it requires a *conscious effort* to activate the feature, and
therefore causes the user to *think about his descision*.

QUOTE OF THE BUG: "Market share is all about customer satisfaction, not *ideal
technology worshipping*."
[/OT]
Comment 165 Simon Lucy 2001-08-23 02:04:44 PDT
PL:  It was not spam, it was germane.  Your hysteria though certainly does seem unnecessary.  If this patch stands on its own then it is an extension because without encapsulating all the data as application data (encrypting and isolating from the host operating system), it is an external add on, it isn't part of the main application.  

Making it a negative option for distributors (ie having it built as a default), is not acceptable because of the possibility of error, build options should be positively chosen.
Comment 166 Jason Bassford 2001-08-23 04:46:18 PDT
<OT>
Discussing how to implement it is fine.  Having an endless series of "I like
it,", "Well, I don't.", "Well, you're wrong it's good.", "No, you're wrong it's
not." is just taking up air space.  Considering it as an extension is also valid
- but not "because it's something that shouldn't exist in the first place".

I agree with Mike Shaver.  Wait until the code is in place, or until nobody
continues with it and it is never finished.  If it is finished, wait until it
gets approved or rejected via the regular process.

This process is no longer a useful forum for arguing for or against the feature.
 It's only for discussing how to technically implement it.  Discussions of
whether it's a good thing or not  have already occurred ad nauseum and new
discussion is just repetition.
</OT>
Comment 167 jbetak@netscape.com (away - not reading bugmail) 2001-08-23 11:30:09 PDT
simon:

I side here with PL: give the users, what they want. At present Mozilla 
apparently doesn't have the engineering capacity to implement full encryption 
for profiles. If there is a significant number of users, who will be content 
with weak protection, mainly against accidental profile usage, why shouldn't we 
give them what they want? 

This question has probably be answered by each individual vendor, as it depends 
on their audience, hence the need for this to be an extension. Mozilla might or 
might not turn it on. Maybe Netscape will, and as we surely all know by now, 
Beonex will turn it off in their distribution.
Comment 168 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-08-23 12:06:10 PDT
jbetak: I guess I should have been clearer before: there is at least one
significant issue with this patch as it stands right now, aside from any
discussion about whether the feature would or would not be accepted into the
Mozilla tree with a proper implementation.

(It's not clear to me how this would be structured as an extension, but I
haven't yet thought about it in detail.  But if it _is_ an extension, then it
doesn't need to be in mozilla.org's CVS, should it be generally rejected: it can
live at mozdev or anywhere else, and be XPI-installed by anyone who wants it.)
Comment 169 jbetak@netscape.com (away - not reading bugmail) 2001-08-23 12:39:28 PDT
shaver: 

>one significant issue with this patch 

I'm not quite clear - are you referring to the application registry problem? 


>It's not clear to me how this would be structured as an extension

I was contemplating placing XUL and JS into 
http://lxr.mozilla.org/seamonkey/source/extensions/. Not sure yet, how to 
isolate the code changes to the profile manager in the best way. I considered 
#ifdefs first, but that seems to be quite crude. Another idea was to check, 
whether the UI (via extensions) got built and is present and run the 
authentication check in nsProfile.cpp only then. The backend changes in 
nsProfileAccess.cpp could possibly be always built, unless we decide to forgo 
writing to the application registry. ccarlen - what do you think? Would you 
have an idea, how to make this into an extension?
Comment 170 Håkan Waara 2001-08-23 13:02:18 PDT
Actually, what's the point of checking this in as an extension,  because there
are issues with the patch?

I certainly don't want a false sense of insecurity on by default, and if it
wasn't, and we'd have it as an extension, who, except for you guys on the CC
list who build yourselves or tweak your hidden prefs, would use it?

Just make it right at - make it part of the default build. Adding #ifdefs,
hidden prefs and whatnot is a shame for our source-base. Just because no one
wanted to do the Right Thing...
Comment 171 jbetak@netscape.com (away - not reading bugmail) 2001-08-23 13:10:48 PDT
>no one wanted to do the Right Thing...

and why don't you? 

>who build yourselves or tweak your hidden prefs, would use it?

Håkan, I hate to sound like an evangelist, but most earthlings don't build 
Mozilla on their machine and there are certainly even fewer people capable of 
building various Mozilla-based distribution. Hmm, I know this sounds 
controversial, but open-source project should be capable of compromises and the 
contributors need to keep an broader audience in mind.
Comment 172 Matthew Kruer 2001-08-23 14:15:22 PDT
Looking into the salts I may have discovered a super simple way around the
entier random dirctory see http://bugzilla.mozilla.org/show_bug.cgi?id=96606

As soon as the Password protection is implimented the salts should be removed
due to various problems.

Additional Resources
http://bugzilla.mozilla.org/show_bug.cgi?id=56002
http://bugzilla.mozilla.org/show_bug.cgi?id=95331
http://bugzilla.mozilla.org/show_bug.cgi?id=96606

Comment 173 Peter Lairo 2001-09-07 02:29:09 PDT
What is the status of the patch? Is it ready to be checked in? What is the next
required step (jbetak, mpt)?
Comment 174 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-09-07 08:24:23 PDT
At least the application registry issue needs to be resolved, and then the
patches need to make it through review and super-review.
Comment 175 Conrad Carlen (not reading bugmail) 2001-09-07 09:02:19 PDT
> At least the application registry issue needs to be resolved

What's the application registry issue? If it's this:

"you can't just go writing to the application registry willy-nilly:
multi-user systems often have it unwritable by non-admin users.  You probably
want to find and use the profile registry instead"

that's what he's doing. I objected to an earlier patch in which the registry was
being read by the front-end code, but that was fixed in the 7/20 patch.

Comment 176 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-09-07 09:15:31 PDT
Ah, so.  I think I was looking at an outdated patch (there are so many to choose
from!).  Sorry about that.

The more I think about it, the more interested I am in seeing this as an
extension (if we see it at all -- I'm still of the mind that we should do the
same thing here as with wallet, and let the user choose to encrypt their data).
 Can someone whip up an XPI that we can install and test against 0.9.4, as a
proof of concept of the extension path?
Comment 177 Michael Hearn 2001-09-07 10:46:41 PDT
I might be able to do this, Juraj I'd need you to send me the latest DLLs that'd
work with 0.9.4, then I could make an XPI fairly easily I think. Although I'd
like to see it on by default, there's no reason I suppose why it couldn't be
optional in the installer (though again, it's so small it could be installed by
default too)

-mike
Comment 178 jbetak@netscape.com (away - not reading bugmail) 2001-09-07 12:32:04 PDT
mike, I'll repost the latest patch, screenshots of which were reviewed by mpt 
on 07-25, and roll up a binary DLL drop for you. Hope to have it done today or 
tomorrow at the latest.
Comment 179 Conrad Carlen (not reading bugmail) 2001-09-08 06:31:20 PDT
> Ah, so.  I think I was looking at an outdated patch (there are so many to
> choose from!).

That's for sure. Whoever is responsible for posting these patches here, please
use the new bugzilla feature for editing attachments, mark them obsolete, etc.
This is a wonderful capability is is especially useful on a bug like this :-)


Comment 180 Michael Hearn 2001-09-08 08:07:13 PDT
ok thanks juraj. I've just found I'm not authorized to edit attachments, so can
somebody give me those access rights?
Comment 181 Dan Mosedale (:dmose) 2001-09-08 13:43:58 PDT
Michael: access granted
Comment 182 Michael Hearn 2001-09-08 14:38:30 PDT
Comment on attachment 38283 [details]
First XUL/JS/DTD patch for profile passwords

obsoleting bug. aplogies for the spam
Comment 183 jbetak@netscape.com (away - not reading bugmail) 2001-09-13 17:53:15 PDT
Created attachment 49288 [details] [diff] [review]
most recent patch (with UI review from 07-25-2001)
Comment 184 Michael Hearn 2001-09-15 06:32:49 PDT
Thanks Juraj, do you know when the latest DLL will be posted? thanks -mike
Comment 185 jbetak@netscape.com (away - not reading bugmail) 2001-09-17 20:20:58 PDT
Mike, I was hoping to post them today, but I'm having some trouble making the 
binaries run against the 0.9.4 distribution build. I haven't quite figured it 
out yet...
Comment 186 bclinger 2001-09-18 23:28:49 PDT
I see this is still a hot issue. Guys, as a user, I understand completely that
profile passwords do not provide any degree of security. I understand and
appreciate it. What it provides for me is a way of keeping my profile/bookmarks/
email, et cetera, seperate from someone elses. There are five Netscape 6/Mozilla
users on this one machine (total of 4 with the browers, though only one machine
has multiple profiles) and there are times when we hit the wrong profile. In my
family, it's not a "security" issue, as there is nothing of real value to be
protected. No porn, no nothing. I just do not look forward to seeing my 10 year
old putting his Neopets stuff in my bookmarks or getting his email from his
friends, et cetera. 

So, I vote for implementing profile passwords and await the day it arrives.
Thanks for letting me babble. Ben
Comment 187 Michael Hearn 2001-09-19 04:07:58 PDT
Juraj - just had a thought. Will it even be possible to do this as an XPI. In
particular, the DLL will be hardcoded to reference chrome://comm/profiles (or
whatever the path is) won't it? Also, is it going to be possible to overlay the
profile manager correctly? I'm thinking it might be easier to move it into an
extensions directory and switch it on with defines or something here. sorry to
mess you around juraj, I didn't think of this until this morning

thanks -mike
Comment 188 Michael Hearn 2001-10-09 12:36:04 PDT
ALERT! ALERT! This bug needs some sweet lovin'

Juraj - can you please remind me what the chances of this feature being put into
the trunk (with an on/off switch) are? I think it's pretty much ready, just
needs r= and sr= right?

thanks -mike
Comment 189 Mike Young 2001-10-17 23:57:18 PDT
What is the status of this bug? If the developer feels this patch is acceptable
to undergo review, he/she should place the patch and review keyword in, and
email drivers@mozilla.org and the module owner/QA for a review.
Comment 190 timeless 2001-10-18 14:45:58 PDT
last i checked i was waiting for someone to make this code use NSS for crypto
and fallback to something which is non crypto in the event that NSS is
unavailable (some countries may not like crypto)
Comment 191 jbetak@netscape.com (away - not reading bugmail) 2001-10-18 15:13:31 PDT
timeless - since Paul Johnston gracefully relicensed and explicitly allowed us
to used his code, could we give this a rest please? 

IMHO this project is - apart from some  philosophical issues - suffering from
lack of engineering cycles. I currently don't have enough time to work on this
and was hoping someone would attempt to turn this patch into an optionally built
extension before I can. 
Comment 192 timeless 2001-10-18 15:24:51 PDT
Well if you want to go that way then please make this extension honor
--enable-crypto and --disable-crypto.
Comment 193 jbetak@netscape.com (away - not reading bugmail) 2001-10-18 16:35:05 PDT
OK cool, pardon my ignorance but what effect should "disable-crypto" have? Looks
like a build switch to me... I'm not quite clear how <mumble> <mumble>
Comment 194 timeless 2001-10-19 10:11:03 PDT
the crypto code which we use should not be built/packaged unless --enable-crypto
(yes it's a build flag) is used.  The code alternative to NSS is still crypto
and therefore should be covered by that flag.
Comment 195 Conrad Carlen (not reading bugmail) 2001-10-24 14:09:14 PDT
r=ccarlen on the profile mgr back-end portion (which I own) You'll also need to
get module owner r= on the front-end portion from ben@netscape.com.
Comment 196 Michael Hearn 2001-11-24 06:08:14 PST
OK, changed milestone, and updated my email address which has changed _again_.

I just need to get ben to review this bug, and then we can get sr= and hopefully
permission to check in.
thanks -mike
Comment 197 kostya 2001-12-06 06:01:00 PST
I just want to say that this bug is the only reason why I now have to stop using
mozilla. It was my only browser and mailer since M18, and now I have to switch
to Outlook Express just because it supports identity passwords.

The people who say it is not necessary probably do not have families (and no,
even if it was possible to encrypt profile data, I would not use that. I do not
need to encrypt anything - I only need a simple password dialog).

And why this bug is marked as 'enhancement', while it is an obvious regression
comparing to Netscape 4.5 - 4.72 ???
Comment 198 loadrunner 2001-12-06 08:23:07 PST
ben, blake: 

this bug is another "step child" in dire need of your attention. ccarlen has 
review the proposed changes for the profile backend, but we still need a review 
of for JS changes. I'd expect that a super-reviewer will ask to turn this into 
an optionally built extension, but we might as well get lucky...

Could you review the patch - please?
Comment 199 Michael Hearn 2001-12-06 09:10:30 PST
Don't worry guys, I chased up Ben on IRC yesterday. He promised to review this
bug in the next 2 days, so hopefully it'll get r= on the front end soon. Then we
just need sr.

To kostya@mindless.com - yep, I know what you mean, which is why I contributed
to this bug. Hopefully when it gets into the trunk you'll be able to switch back
to MozMail.

thanks -mike
Comment 200 bclinger 2001-12-06 09:54:31 PST
Like the gentleman above, I also have a need for a password/profile function and
like him, it is not for any encrypting need, it is just something to make life
with the browser/mailer easier. I do not care to have to search thru bookmarks
looking for for a journal because one of the kids used my profile instead of
his. Any need to test it - I'll be glad to. It certainly can't be any worse than
having to put up with the "flashing" Bugzilla at the bottom of the screen. Ben
Comment 201 Sean Cotter 2001-12-06 11:40:30 PST
To be consistent with change password dialogs elswhere in the interface, the
field labels in the screen dumps attached on 7/23/01 should be changed as follows:

Set Profile Password

  Password:

  Password (again):

Change Profile Password:

  Current password:

  New password:

  New password (again):

In addition, I suggest the following change in the first sentence of the warning:

  Protecting your profile with a password does not encrypt your personal data.





  
Comment 202 Michael Hearn 2001-12-06 14:07:16 PST
Created attachment 60693 [details] [diff] [review]
Patch - 6th Dec 2001

OK, modified patch to come in to line with Sean Cotters suggestions. However,
unfortunately due to the fact that the Change Password and Set Password windows
are basically the same, I couldn't change the labels to have "New" on them, so
they just say "Password" and "Password (again)" now... perhaps someone who has
CVS access can apply the diff, make the changes, and then recreate the patch? I
can't do this... :(

Hope this is OK
thanks -mike
Comment 203 Michael Hearn 2001-12-06 14:19:45 PST
Created attachment 60696 [details]
Here's an amusing joke. Well, it'd depend on taste of course......

Mass-obsoleting bugs using the new attachment feature. Well, I had to attach
something, didn't I?
Comment 204 Mike Shaver (:shaver -- probably not reading bugmail closely) 2001-12-06 15:41:53 PST
A super-reviewer _did_ ask for it to be done as an extension
(http://bugzilla.mozilla.org/show_bug.cgi?id=16489#c176 ), and I thought someone
was going to cough that up.  Did I miss an attachment?  (I've been behind on my
bugmail, sorry.)
Comment 205 Sean Cotter 2001-12-06 16:21:48 PST
It would be better to make it "New password" etc. in both dialogs rather than
plain "Password" in both. After all, when you're setting the password for the
first time, it's a new password (brand new, in this case).

This might actually be an improvement, even aside from the implementation issue.
Comment 206 Michael Hearn 2001-12-07 07:33:01 PST
Created attachment 60805 [details] [diff] [review]
Latest patch as of 7/12/2001

Changed "Password" to "New Password" as per sean cotters suggestion. Now to go
and bug ben about reviewing this one

thanks -mike
Comment 207 Michael Hearn 2001-12-18 10:26:07 PST
OK, ben is clearly not interested in this at all. MPT, can you give this patch
r= for the front end?

thanks -mike
Comment 208 Michael Hearn 2001-12-18 11:19:51 PST
There isn't much work left to do on this now I think. Basically turning it into
an optionally built extension, which I've been told will involve creation of a
new build directory and some modifications to the build script. It might also
involve writing a few lines of JS to show/hide the "Set Password" button in the
profile manager. Unfortunately, this bug has now passed beyond my abilities to
contribute, as I lack a complete source tree, so I'm CCing racham@netscape.com
who dveditz in IRC told me did a lot of the original work, also sending him an
email about it. Hopefully he'll be willing to put in an hour to making this
patch make the grade for super-review.

thanks -mike
Comment 209 Jonadab the Unsightly One (Nathan Eady) 2001-12-21 07:50:40 PST
This really worries me.  

The fact that we have statements like this:

> It will also deter 99% of people

and this:

> this removes the risk of people who are just doorknob twisters.

and this:

> Most of the users of this product will not know the workaround, 
> so the password is an effective deterrent. 

and this:

> would be effective in environments where several people 
> share a computer and can't trust each other

and this:

> It's not ridiculous, and its a feature taht would come 
> in handy for 99% of the public that uses a non-secure 
> commercial OS

demonstrates the very real danger of implementing this -- 
people will obviously believe it has protective value.  
Anyone still want to argue that nobody will believe it
makes them safe?  

Is this really too far gone to stop?

> Honestly, how many of your "normal" (read: non-computer freaks 
> =) friends know where the mozilla registry is?  

None.  How many of them need to know where it is to 
accidentally bump into it when mindlessly clicking
whatever they see without understanding it?  None.  
If you haven't seen that sort of thing happen, you 
haven't been watching clueless end users long enough.  

> This would happen WITHOUT a profile password too!

Yes, but without a password people *know* the information
isn't secure.  Add the password, and suddenly people
believe they are safe.  It's analogous to putting a 
cardboard guardrail along the side of a bridge and spray
painting it silver so it looks like a metal rail.  With
no rail at all, most people will walk appropriately
far away from the edge (and those who don't are idiots).  
With a cardboard rail that *looks* like it might keep 
you from falling off, more people will get themselves 
seriously injured, because they enguage in behaviors that 
they wouldn't otherwise.  

> I think it is clear that many people want this 
> protection feature.

They want it only because they believe it will do what
in fact it cannot do.  Many people also want a program
to translate text for them from one language to another --
until they see the actual results of such an automated 
translation, at which point they rapidly lose interest.

Comment 210 Michael Hearn 2001-12-21 08:24:30 PST
Please stop spamming this bug. We're sick of these endless arguments. You have
your own beliefs, we have ours (where "we" are the people who want and who are
implementing this feature). Don't like it? Don't use it. We couldn't care less.

Oh, and your point about the registry is invalid. I watch clueless users all the
time, and let me tell you, there isn't a chance in hell of them being able to
extract the password, or extract information from the user profiles or whatever.
We can do this yes, because we know that sometimes files without a .doc
extension are text files and can understand the structure of XML. Most can't.
Even reasonably competent people who could open the registry would still not be
able to read the password because it's hashed (although I'm considering removing
that).

All your points have been argued over endlessly and a compromise has been
reached that the majority are happy with. 

It's been asked before, but I'll ask again. Please refrain from spamming this
bug, it's bloated enough as is.
Comment 211 Blake Ross 2001-12-21 09:01:35 PST
"Don't like it? Don't use it." shouldn't be justification for adding something 
to Mozilla or everyone with a feature idea and the skills to implement it would 
have a cvs account.

The module owners, presumably Ben and Conad, need to decide whether they'd like 
this code to be added to Mozilla.  The best way to get their attention is to e-
mail them; I know that Ben, at least, is on vacation.

To sum it up, this solution is obviously not infallible for a number of 
reasons: the profile files remain accessible through the file system; the 
encryption method is viewable on the internet and anyone with the program; and, 
my favorite, anyone can just modify their profile manager chrome to remove the 
dialog.  Still, the users for whom the profile manager was made -- family 
members -- do not know how to do any of these things. They'll see the password 
dialog and assume it's unbreakable.
Comment 212 Michael Hearn 2001-12-21 09:45:52 PST
That's a pretty good summary of what I'm thinking. OK, I admit you're right that
"don't use it then" isn't a good reason for adding a feature to mozilla anyway,
but you are right in that although it's easy to work around, even my computer
loving friends would find it hard to hack the profile manager chrome to let them
in. This is a primarily family-oriented feature, not one for business use. The
warnings on the feature should hopefully make this clear.

As for review, well Conrad has given it r= on the backend, Ben however doesn't
want to make the time for it. I'll asked many many times, but although he agreed
to review it he never did. Maybe in the new year I'll try again.

thanks -mike
Comment 213 bclinger 2001-12-22 02:16:09 PST
My penny's worth again. Most of us know it does not provide any protection. What
it does is provide a convenient method of dividing what belongs to the users.
Heck, Windows doesn't have any security, but the password function within
Windows does make it easier to keep information seperate. Put your disclaimer
about "security" in and give the end user/customer what he/she wants. It'll make
life grand for all of us again.
Comment 214 timeless 2001-12-27 14:07:51 PST
as long as we're using code from pajhome.org.uk please include a reference to http://bugzilla.mozilla.org/show_bug.cgi?id=16489#c131 in your patches/whatever you try to get into cvs/whatever you put in cvs.

IANAL, but i think 
/*
 * JavaScript implementation of the Secure Hash Algorithm, SHA-1, as defined
 * in FIPS PUB 180-1 Copyright (C) Paul Johnston 2000.
 * Code used under MPL as granted by the author paj@pajhome.org.uk in
 * http://bugzilla.mozilla.org/show_bug.cgi?id=16489#c131
 */

Beyond that, this license block should be attached to the bottom of the main license block at the top of the file instead of drifting in the middle of a file.  As usual, i'd prefer for the sha1/md5/... modular code to live in their own file(s).
Comment 215 Sören 'Chucker' Kuklau (gone) 2002-01-06 06:46:37 PST
Shouldn't Target Milestone be updated?
Comment 216 Ben Goodger (use ben at mozilla dot org for email) 2002-01-08 14:38:17 PST
I currently have a lot of work assigned to me for this milestone. See my .9.8
bug list for details. Anyone with experience in FE work can review this code, I
can offer little special Profile Manager insight since I've not really touched
this section of code for well over a year. 
Comment 217 Michael Hearn 2002-01-09 08:46:10 PST
Okay thanks Ben, I'll go poke someone in IRC to help review this
thanks -mike
Comment 218 jbetak@netscape.com (away - not reading bugmail) 2002-01-09 12:47:55 PST
how about timeless - he has spent considerable amount of time looking into this 
already...
Comment 219 Michael Hearn 2002-01-09 13:24:38 PST
well, i've been told to get the mods suggested by shaver (making into an
optional build extension) done first. as for who will make those changes - well
timeless just told me to get my own tree. Easier said than done methinks,
though I will look into it
Comment 220 Andrew Hagen 2002-04-04 21:34:00 PST
I've read all the comments. I'd like to propose that this feature be called
"Family Profile Password Protection."

The problem is that fixing the bug would give users a false sense of security.
If a person sees the password feature, he might use it at home to prevent one of
his kids from using the other kid's profile. This is legitimate use. There are
no security problems with this use because the user does not expect solid
security. But if the parental user learns to trust this password feature, he
might decide to use it for another purpose: for example, keeping business
secrets safe on his office computer. Maybe he stores usernames and passwords to
e-commerce sites in cookies. 

In previous comments, the analogy has been made to MS Word's legendary weak
security in its password scheme. As everyone acknowledges, the problem is that
people assume it's good security, and so they unknowingly trust MS Word's weak
security. That's the problem we have to prevent. As is well known, many, many
people have been burned by this security hole.

The disclaimer in the screenshots is not enough. It's not prominent enough.

When we implement this feature, it should be called "Family Profile Password
Protection." The word "Family" would alert users that this password protection
feature does not meet business (or higher) standards. This would prevent the
false sense of security problem. 

Once implemented, this feature will be a nice addition to Mozilla.
Comment 221 cmorley 2002-04-05 15:34:42 PST
I'd go the the "Family" tital that #220 mentioned.  This keeps it simple and no 
one would guess that it's "serious" protection.  I still, however, know many 
small businesses that would use the "Family" feature as well.  I had a room of 
30 engineers all using this in N4.5 and it worked like a charm.  No secrets, no 
espionage, just VERY conveniant for all these people to have a "simple" 
seperate profile that others wouldn't use.

So, when do we get it?  Doesn't look like it'll make it to 1.0 (along with a 
lot of other things)
Comment 222 Michael Hearn 2002-04-06 06:46:27 PST
This feature will hopefully make it in once it's been converted to an optional
extension so that distributors can make an independant decision whether to have
it or not. Unfortunately I have no time for this, and I'm sick of this bug
anyway, so somebody else would have to pick up the slack. It's a pretty trivial
modification though.
Comment 223 Michael Hearn 2002-06-08 13:02:40 PDT
Two things

1) The release of 1.0 has renewed my enthusiasm for contributing. In the next
few months, I'm planning on embarking on the development of a piece of
(commercial) software using the Mozilla toolkit, and as part of that I'll be
setting up my own Moz build environment. This is much easier now I'm used to
Linux, so within the next few months if nobody else does so, I may be able to
turn this into an optional extension and therefore reach a compromise with which
most people at least find acceptable.

2) This bug is assigned to a non-existant email address: I'm mike@theoretic.com
now :p

Any comments?
Comment 224 Andrew Hagen 2002-06-08 13:30:28 PDT
Reassigning to his new e-mail address. P.S. Go, Mike, go!
Comment 225 bclinger 2002-06-08 13:37:05 PDT
As a user, I look forward to having this issue resolved. The use of the term,
"family feature" is just great. Every member of my family knows how to get
around the system to get whatever information is wanted. There are utilities
available to open almost any file. We are wanting only a simple mode of
seperating profiles, similar to the 4.79 arrangement. It is a request that many
have made and frankly, means more to me and my family than IRC chat and other
similar features. Ben
Comment 226 bclinger 2002-06-08 13:37:29 PDT
As a user, I look forward to having this issue resolved. The use of the term,
"family feature" is just great. Every member of my family knows how to get
around the system to get whatever information is wanted. There are utilities
available to open almost any file. We are wanting only a simple mode of
seperating profiles, similar to the 4.79 arrangement. It is a request that many
have made and frankly, means more to me and my family than IRC chat and other
similar features. Ben
Comment 227 cmorley 2002-06-08 14:27:00 PDT
Ben, my thoughts exactly.  I guess the programmers have the privilege of getting
things that *they* want in first and others last (this being one of them), but
let's hope they get this up and running soon.  They don't realize they're
cutting out a large segment of the market with their myopic grievances
concerning this 'feature'.

dr
Comment 228 Peter Lairo 2002-06-09 01:48:18 PDT
Please don't call it "Family ...". Call it what it is ("Profile Password") and
explain the limitations, then let the users with a brain decide if it's for them.

PS. GO MIKE! :-D
Comment 229 Vidar Haarr (not reading bugmail) 2002-07-16 20:45:00 PDT
*** Bug 157838 has been marked as a duplicate of this bug. ***
Comment 230 Alfonso Martinez 2002-09-07 02:53:57 PDT
*** Bug 167215 has been marked as a duplicate of this bug. ***
Comment 231 Peter Lairo 2002-12-04 09:18:24 PST
Could someone (ANYONE) with sufficient rights please update the keyword for this
bug? i.e., "mozilla1.3"
Comment 232 jbetak@netscape.com (away - not reading bugmail) 2002-12-22 00:50:08 PST
Mike, I'm tentatively reassigning this
Comment 233 Michael Hearn 2002-12-22 03:15:15 PST
Yeah, sorry to disappoint. I probably won't be getting a chance to do much with
this anytime soon. Living, along with 2 jobs, is taking up most of my time at
the moment. Combined with the fact that I left my family behind when I moved and
am now on Linux anyway, means that I personally don't have much use for this
patch either :/

I also have a feeling the patch will have bitrotted somewhat by now. If somebody
else has more time to update and merge in this patch (assuming the original
objections have been dealt with) that'd be excellent.

Once again, I'm sorry I didn't manage to get this in. This was the first patch I
wrote for an open source project, and since then I've got more experienced at it
(2 into wine so far, needed for work). Hopefully some day soon I'll have enough
time to start writing more than just docs for Mozilla.

ta -mike
Comment 234 jay@mozillacafe.org 2002-12-22 06:04:11 PST
Created attachment 109935 [details] [diff] [review]
updated patch
Comment 235 Andrew Hagen 2002-12-22 17:50:25 PST
The references in the UI to "password protection" should be changed to "family
password protection".

"Stop using passwords" Should be "Stop using password for this profile".

Comment 236 jay@mozillacafe.org 2002-12-22 18:32:51 PST
Andrew,

thanks for reviewing the code. While I agree with the second proposition, I don't think that 
any reference to "family" would be appropriate for office environments. And yet many of 
them would be content with weak profile protection.The wording in the current patch is an 
exact replica of a consensus solution from last year. 

We'll create a mozdev project for "secure profiles" on mozdev and post an update on it  
shortly. There is a good chance that eventually full profile encryption will come out of it.

Meanwhile, we need to have a project for people to rally around and continue this 
discussion. We also want to distribute an add-on (built as an extension) to help 
interested parties with their Mozilla deployment plans.
Comment 237 Andrew Hagen 2002-12-22 19:53:47 PST
I see your point about "family password protection" being unsuitable for
business environments. It would also be inappropriate to provide business users
with weak security features that are not specifically labeled as weak. The
warning dialog is good. It is:

"Protecting your profile with a password does not encrypt your personal data. It
is possible to access your data without knowing this password."

In these two sentences, the words "personal data" and "data" should be replaced
in each case with "profile."

Users should be reminded that they are using weak security every time they enter
their username and password. A popup is not needed. The addition of a word or
two of text in the same dialog box would be enough here. We don't want to call
it "weak password protection," though. The word "weak" has unnecessary negative
connotations. The word "family" would be offputting to business users. We should
have some description of the password feature besides just "password
protection." How about "informal password protection"? That would apply equally
well to family situations and business situations where encryption of profiles
is not a requirement.

I understand the need for secure profiles, even encrypted profiles. If the
feature called for in this enhancement request is called "informal" then that
would help to sell users on the need for fully secure profiles in the future.
Comment 238 Jason Bassford 2002-12-22 20:07:20 PST
> In these two sentences, the words "personal data" and "data" should be 
> replaced in each case with "profile."

I disagree.  The phrases "data encryption" and "access your data" are far more
commonplace and understandable.  Replacing that with "profile encryption" and
"access your profile" would just cause confusion.  When the message says *your*
data it's perfectly understandable that it's talking about data accessed by your
login (your profile).

> Users should be reminded that they are using weak security every time they 
> enter their username and password.

God, no.  The last thing I would ever want is a constant reminder every time I
logged in.  Put in as many "Are you sure?" messages as you want the first time a
profile has a password put on it - but then leave the user alone after that.

> The addition of a word or two of text in the same dialog box would be
> enough here.

And *also* not needed.  A simple login dialogue is all that's necessary. 
Anything else is insulting to the person who went through the steps of adding a
password in the first place.

> We should have some description of the password feature besides just
> "password protection."

No, because what's being proposed *is* password protection.  Calling it
something else, as a constant phrase, seems silly.  I have no problem with a
brief comment/warning given when setting up a password, but there's no reason to
keep denigrating it every time after that.  

> If the feature called for in this enhancement request is called "informal"

Then it would make the feature look unprofessional and laughable.  I'm sure that
the people against this feature think that anyway, but there's no point in
implementing this unless it's done seriously.

> that would help to sell users on the need for fully secure profiles in the 
> future.

In the future, it can be called "enhanced".  Spin it more positively in the
future, rather than spinning it negatively now.
Comment 239 Andrew Hagen 2002-12-23 11:57:27 PST
> The phrases "data encryption" and "access your data" are far more
> commonplace and understandable.  Replacing that with "profile encryption" and
> "access your profile" would just cause confusion.  

Read comment 237 again. In no way did I call for replacing anything with
"profile encryption." I don't know what you're talking about there. 

Furthermore, I never called for any pop-up on login. All I want is for the login
prompt to not look like this:

Password for profile access: _____________________

but to look something like this:

Informal password for profile access: _________________

(rough approximations for demonstration purposes)

That change would not be a burden on experienced users such as yourself. It
would be extremely helpful to the 99% of our (mostly future) userbase for whom
"password" typically means "all the security I need." What we need to do is keep
users informed about the level of risk they are taking without bothering them
too much.

The word "informal" would *not* make our product look unprofessional. Informal
does not equal unbusinesslike. There are many informal workplaces. The question
is whether the data stored on the profile is worth protecting with good
security. If not, then weak or "informal" security is all that is needed. 

The addition of a word like "informal" would make our product look more
professional, not less. Unlike some other products on the marketplace (MS Word,
for example), we would not be lulling users into a false sense of security by
giving them the option of "password protection" when that password is easily
cracked. People have been burned by the weak security of MS Word, PK Zip, and
other programs that misrepresent to their users the actual risk they are taking.
See previous comments in this bug.

We can't prevent any user from being burned by their foolish misuse of our
security functions, from password access of profiles to SSL. We can and should,
however, give the user information to enable that user to appropriately manage
the risks being taken.

I don't care about the exact wording. Alternatives to the word "informal" exist.
No doubt there are many. Just don't use the term "password" in an unqualified sense.
Comment 240 Jason Bassford 2002-12-23 12:16:39 PST
> Read comment 237 again. In no way did I call for replacing anything with
> "profile encryption." I don't know what you're talking about there. 

Here's a direct quote from comment 237:

---

"Protecting your profile with a password does not encrypt your personal data. It
is possible to access your data without knowing this password."

In these two sentences, the words "personal data" and "data" should be replaced
in each case with "profile."

---

To follow that suggestion for word replacement would be to end up with the
phrases "encrypt your profile" and "access your profile".

> Furthermore, I never called for any pop-up on login. All I want is for the 
> login prompt to not look like this:

I know you didn't.  I even said in my comment 238 that you weren't asking for a
popup.  You were asking for notice on the login dialogue of the "weak"
encryption.  I still argue against that.

> would be extremely helpful to the 99% of our (mostly future) userbase for
> whom "password" typically means "all the security I need."

Um, no.  If somebody sees "informal encryption", they'll say to themselves, "WTF
does that mean?"  I've certainly never heard of that exact phrase before and
I've been working in IT for 10 years.

>  What we need to do is keep users informed about the level of risk they are
>  taking without bothering them too much.

Which is exactly why you give an explanation of what's going on with the
password when they decide to implement one the *first* time - not every time
they log in.

> The word "informal" would *not* make our product look unprofessional.

That's your opinion.  I disagree.

> giving them the option of "password protection" when that password is
> easily cracked.

You're superficially supporting this enhancement request, but, by making
statements like this, implicitly sabotaging it.  If you don't like the idea then
take arguments against it to the newsgroups.  If nobody likes the enhancement
request enough to submit a patch that uses professional verbage, without
undermining its function, then no patch should be submitted / approved.

> Just don't use the term "password" in an unqualified sense.

The qualification comes when they choose to activate this feature and a
paragraph describing what its implications are comes up.  There's no need to hit
them over the head each time they log in that what they've chosen to implement
is weak / shoddy / informal / easily cracked / insecure / not recommended.
Comment 241 Andrew Hagen 2002-12-24 12:41:07 PST
I want this patch very badly. I've been pushing for it for months. 

If you have better wording for the warning message that we will have, with the
current patch, that appears when password protection is first turned on, then
please suggest it. Here's my suggestion, slightly changed

"Password protecting your profile does not encrypt your profile. It is possible
to access your profile without knowing this password."

IMO, this is superior to the current wording because it makes it clearer to the
user that the profile password has some risks that the user should know about,
and that these risks specifically pertain to unauthorized access of the profile.

Now, I've also suggested that the password dialog says this:

Informal password for profile access: __________________

This could be improved upon. For one thing, it uses non-technical jargon, when
we use technical jargon in the warning message. 

How about a password prompt that says the following?

Password for non-encrypted profile access: __________________

That would get the same message across, as far as I'm concerned. Does that work?
Comment 242 Mr Israel Steinmetz 2003-01-19 04:33:06 PST
Dear Andrew Hagen,

Your phrase "family password protection" is meaningless and ambiguous, even if
we were to make the false assumption that Mozilla will only be used by families.

You suggest that we should replace the warning:
"Protecting your profile with a password does not encrypt your personal data. It
is possible to access your data without knowing this password."
with:
"Protecting your profile with a password does not encrypt your profile. It is
possible to access your profile without knowing this password."

I'm confused why you suggest this replacement. Your stated goal is to ensure
that users should be reminded that they are using weak security, but this
replacement would actually cause only confusion. We would end up talking about
protecting an obscure "profile", but the user is really concerned about his
"personal data".

You also recommend the term "informal password protection". That phrase is also
not meaningful.

You state that you would recommend the term "informal" because it would "sell
users on the need for fully secure profiles in the future". I wonder why you
believe that anyone would need to sell users on the need for secure profiles? Do
you perhaps believe that there would be a public outcry against insecure
profiles and that massive media coverage would attempt to force Mozilla.org to
bend all of its energies to redressing this insecurity? To me, this issue seems
to be an unlikely rallying point for Mozilla users.

You state that you prefer not to use the term "password" in an "unqualified
sense", preferring the term "informal password". First of all, the term
"informal password" has no meaning in this context. Second of all, you are
implying that a password is inherently strong, but anyone with any knowledge of
security realizes that passwords are inherently weak, because they are by
definition a method of access. I hope this makes clear to you why your phrasing
is unacceptable.

Finally, you suggest the label "Password for non-encrypted profile access".
However, this is also meaningless: By qualifying the label, you imply that there
is also a separate password for encrypted profile access. However, because this
is not an available option, you are causing needless confusion.

I don't think that anyone with good English skills and good computer skills
would support any of these changes. I would suggest that, in the future, you
find a relative/friend/associate who has good English and computer skills and
have this relative/friend/associate review any of your future posts that regard
text visible to the user. This should prove educational to you and should lessen
the time that we waste on insubstantial posts.

Sincerely,
Israel Steinmetz
Comment 243 Andrew Hagen 2003-01-20 13:51:42 PST
I withdraw my earlier suggestions.

In the current patch, the one-time warning a user sees after he turns on
password protection is:

"Protecting your profile with a password does not encrypt your personal data. It
is possible to access your data without knowing this password."

I don't completely like this text. Here's why. The word or words for the thing
that we are talking about changes, while the thing itself remains the same.
First it is "profile," then "personal data," then just "data." I like how the
word "profile" is defined as "personal data," but I don't like how "personal
data" becomes just "data." The latter is confusing.

How about the following as an alternative?

"Protecting your profile with a password does not encrypt your personal data. It
is possible to access your personal data without knowing this password."

That wording is clearer than the wording in the current patch.

Secondly, when the user attempts to load Mozilla with a profile that has been
password protected, he is presented with the following prompt in the current patch:

"Please enter your profile password:"

This is good. If we could insert a couple of words to the prmopt so that users
would be reminded that they are using weak security, but still would not be
inconvenienced, then that would be an improvement to this already useful
feature. How about the following?

"To access this unencrypted profile, please enter your password:"
Comment 244 Jason Bassford 2003-01-20 14:37:52 PST
> "Protecting your profile with a password does not encrypt your personal
>  data. It is possible to access your personal data without knowing this 
> password."

That works for me.  However, given the desire to impress upon the user that it
is unencrypted, the warning might be made stronger still:

"Please note that protecting your profile with a password will not encrypt your
personal data.  Even with this password in place, it may be possible for
somebody else to access your personal data without knowing the password."

> "To access this unencrypted profile, please enter your password:"

I still don't agree with continually reminding the user of the fact that their
data is "insecure / unencrypted" every time they go to login.  They should be
perfectly aware of this fact due to the initial warning that they got when they
set up their password.  I don't think that the routine login message should be
changed.  (However, I do concede your point that they should be more aware of
what they're getting into at the beginning, hence my rewording of the initial
warning so as to make more of an impression.)
Comment 245 Georg Meyer 2003-01-20 14:40:36 PST
I like your alternative suggest. But I think it woudn't hurt to explain a bit
more, so that "Joe User" knows what a profile is and what it contains. Often
they will use profiles for the very first time and many Win users aren't aware
of the concept that much. Suggestion:

"Your Profile contains personal data. Protecting your profile with a password
does not encrypt this data. It is possible to access your personal data without
knowing this password".
Comment 246 Andrew Hagen 2003-01-24 14:24:24 PST
I like both of those suggestions for the one-time warning, especially the first
one because it mentions that the profile is not encrypted.

Here's why I think the password prompt should also say something about the
profile not being encrypted. Many users will not have set up Mozilla (or the
Mozilla-derived product) themselves. An expert user, a local guru, or a system
administrator will have done it for them. Thus, there is no guarantee that the
actual user will have seen the one-time warning. There will be many cases when
the actual user will not see it at all. In those cases, it is important that the
person who uses the profile be provided with relevant information about the
level of security provided. 

I don't care about the actual wording of the password prompt, except that it
should say something about the profile not being encrypted.

For example, either of these would work.

To access this unencrypted profile, please enter your password: __________

or, 

Protected Profile (unencrypted)
Please enter your password: __________
Comment 247 Jason Bassford 2003-03-07 07:56:38 PST
*** Bug 196320 has been marked as a duplicate of this bug. ***
Comment 248 Georg Meyer 2003-03-18 16:40:41 PST
I go for compromise. Let's add a button saying "Help on profiles" or "Profile
Help". Clicking this button set's you to a section of mozilla help, where
profiles are explained, including the fact that they're unencrypted. The word
unencrypted can be fat, underlinded, whatever there. 
Comment 249 Vaclav Dvorak 2003-03-18 17:46:16 PST
One more thing to consider: suppose you have Mozilla with a password-protected
profile set up. When an intruder comes to your computer and tries to access that
profile with Mozilla, he will get a password prompt. If that password prompt
displays the information that the profile is not encrypted, the intruder will
know right away that he can go and read the data without any password.
Otherwise, he may assume that it's not so simple, and give up.

Whether this is good or bad is a matter of opinion. Most normal users will
probably say that it's bad, because it reduces the value of the "protection".
Andrew Hagen will probably say that this makes it obvious to the user that they
can't rely on the protection, which is good. No offence intended, Andrew - not
being normal is nothing to be ashamed of. :-)

Personally, I prefer not having the warning in the login dialog. Consider this:
the value of the planned password protection is only in pretending that the
profile is protected, while in fact it isn't (sorta). Making it explicit during
login that the profile is not protected nullifies the whole value. In that case,
we might as well not implement this at all.

Note about the latest patch: it misses a few files! In particular, all of the
added files (look for /dev/null in the previous patch), and makefile.win.
Comment 250 Andrew Hagen 2003-03-18 19:08:00 PST
Okay, that convinces me. I agree that there should not be an extra warning in
the login dialog. I remain convinced that there should be an in-your-face
warning about the profile being unencrypted at the point when the user turns the
feature on. Is that all right?
Comment 251 cristo morlan 2003-05-11 05:51:16 PDT
Comment #249
I don't know where you live, but I don't generally worry about intruders trying
to get into my book marks or email (though I do agree with your comments). I
don't, however, want little johnny easily stumbling across more 'adult'
bookmarks and such.  The warning up front upon creating the password'd profile
seems best.
Comment 252 Daniel 2003-05-11 13:47:19 PDT
As said by our friend, the "other" users running 9X/ME like me at home (I use
Slack at work) are waiting for some privacy, in mail and in bookmarks...
Unfortunatelly, I don't have a way to compile hole Mozilla here, I ask that some
good fellow could bring a "special" version with password protected profile. 
Maybe it could be possible make the Mozilla for M$ detect the OS Version and
decides if it should have an screen asking a password or not (NT/2K...)

This would be a very interesting enhancement to this great job!
Comment 253 :aceman 2003-07-21 01:41:17 PDT
I agree with comment #244. The user should be warned when the password is set, 
not when it is asked for at login. This would break the whole point of it and 
hint those, who are to be locked out with the password. They would become 
interested and try to find the data. Without any warning or hint, they would 
just give up. I am talking about newbie family members, not professional 
intruders.
Comment 254 Fenintsoa 2003-08-01 07:07:43 PDT
I've very recently seen this bug and 've immediately voted for it. Indeed, even 
if it does not bring 100% security, it is useful when used only to manage 
profile like with Windows NT/XP where you can customize your own desktop, 
window, etc (i.e. here your own address book, etc.).

I have already seen and used it with Nestcape 4.5 and it really worked for me 
and my friends. I think that between no security (no profile password at all) 
and a little security, the choice is done.

F.

ps: I don't know if it is the current real discussion but I am just giving 
mine. Sorry if I am out of the context.
Comment 255 jbetak@netscape.com (away - not reading bugmail) 2003-08-26 11:07:09 PDT
Comment on attachment 60805 [details] [diff] [review]
Latest patch as of 7/12/2001

Obsoleting. Hopefully I will have some time to work  on a new patch soon.
Comment 256 Totally Fake I 2003-08-27 20:12:16 PDT
Wow... 4 years this has been pending, and essentially no progress.  Impressive.
Comment 257 cristo morlan 2003-08-29 12:46:33 PDT
Wow, not as impressive as that last comment tho!

Seriously, this bug is at the whim of whoever has it at the moment and may never
see the light of day.  After 4 years, I've gotten used to not having it... (sad,
really).

The answer is to just set up icons for everyone with thier profile in the string
"-P yournamehere"
Comment 258 Allen Pike 2003-10-12 01:49:38 PDT
I really don't want to come off as just a spoiled user, because I'm very
appreciatve for what the Mozilla project has given the world... but I've had so
many users refuse to use Mozilla Mail instead of Outlook due to this feature I
decided to look it up to see what was holding it up as the only thing I've ever
ever had a normal user ask for. I guess it's a sad reality check for me. Just
posting this in the hope that maybe someone with the knowhow or drive will be
inspired to make this thing happen after years of poltics and quagmire.
Comment 259 Joachim Hellriegel 2003-11-03 09:44:00 PST
Having browsed through most of the previous discussion...
I tend to consider it rather puristic, than user-orientated.
My view is simple:
All we want is a simple means to prevent others (e.g. friendly family members)
from "stumbling" into our mail, or from attempting access driven by mere curiosity.
It is not at all necessary to use a strong defensive mechanism.
It has been pointed out very well, that there are ways to sufficiently inform a
user, that the "password protected" profile is not secured in a strong sense.
To me, it seems we have just lost 4 years in a redundant circular discussion.
What a shame, regarding the otherwise well-done product.
Comment 260 Dale 2003-11-04 06:46:38 PST
Hi all.

Well, I do not know if this is the right bug/enhancement thread to write to but
I do believe so. Just wanted to react to the previous poster. I am probably
differently oriented user than Joachim. I do not care whether my girlfriend
reads my e-mails, as I use this for business and she would get roayaly bored in
a short while... :)

As I am travelling a lot I have all my mails in the notebook and .. well, it's
been stolen from me a few times. With kind of business related-sensitive info in
the mail. It has been in the times when I used Lotus Notes, so there should not
be much of a security problem. Since I switched to Mozilla I am much more
nervous about notebook beeing stolen.

So, what I would expect is _strong_encryption_ of the "mailfile" that would be
unlocked by prompting password at the beginning of the session (and optionally
the password would have to be retyped after "n idle minutes"). The "mailfile"
would then be encoded/encrypted automatically at the end of the session.
Something like calling small PGP (GPG) at the start/end of session.

Well I do this now manually by calling pgp and encrypting *.msf files .. but
Mozilla is unhappy when I forget to decrypt them before starting the session :)

Dale
P.S. Sorry for long post. Does it make sense? Ahem - am i paranoid? 
P.P.S. Sorry for not offering patch or programming, can't do C :( Java, maybe? :)
Comment 261 Nicu Buculei 2003-11-04 06:56:47 PST
Dale, encrypting *.msf files is worth almost nothing, those are only indexes,
you can even delete them and mail is stil readable. you should encrypt the files
without extension (like "Inbox" *not* "Inbox.msf"), those are real messages
Comment 262 Vaclav Dvorak 2003-11-04 08:36:53 PST
Dale, comment 260: I don't think it is realistic to expect full-fledged strong
encryption of Mozilla profiles in the foreseeable future. And, anyway, I don't
think that's the right solution for your problem. No, I don't think you're
paranoid - rather, you're perhaps not enough paranoid. ;-) Don't you have
anything else on you hard disk that is in some way sensitive (whether because of
personal privacy or business secrecy), besides emails? Documents? Any kind of
business data? Of course, you could encrypt these with GPG, too, but that seems
like too much hassle. And how about deleted documents that are nevertheless
still physically present on the drive? Or temporary files created by a word
processor during editing?

If I were you, I'd start looking for a solution that would encrypt the whole
hard disk. In particular, a hardware/software combination with a USB key that
would require you to plug in the key _and_ enter a password to unlock the drive.

I have to agree with Joachim's comment 259 (and many others before him): what we
need for Mozilla is a simple password protection that would avert curious
peekers, though not determined crackers, much less cryptographers.
Comment 263 Christian :Biesinger (don't email me, ping me on IRC) 2003-11-29 15:41:22 PST
*** Bug 227086 has been marked as a duplicate of this bug. ***
Comment 264 Darius 2004-02-18 04:48:55 PST
I don't understand why programmers have not included this into mozilla. As I
understand simple password protection is long time ago done. Some gurus don't
like it, then please do better, but don't be a brake.
Comment 265 derrick 2004-02-24 04:03:22 PST
with this feature added to mozilla i'll be able to migrate hundreds of users
away from outlook express and onto mozilla.

(maybe the reason this feature hasn't been added is due to some secret m$
conspiracy? whatever, its enough to have forced hundreds of my users to use OE
thus far)
Comment 266 Greg Fisher 2004-02-28 14:03:29 PST
I personally would like to see a "Different User Account" feature implemented 
either in a new version of TB, or as an extension. Would be of beneficial use 
to many users across the Continent. If I can be of any assistance to you folks 
please call on me via my e-mail address.
Comment 267 Greg Fisher 2004-02-28 14:05:20 PST
I personally would like to see a "Different User Account" feature implemented 
either in a new version of TB, or as an extension. Would be of beneficial use 
to many users across the Continent. If I can be of any assistance to you folks 
please call on me via my e-mail address.
Comment 268 Scott MacGregor 2004-05-17 08:52:01 PDT
*** Bug 243622 has been marked as a duplicate of this bug. ***
Comment 269 Mohit Aron 2004-06-21 16:52:03 PDT
I filed a feature request bug that has been made a duplicate of this one.
It seems this bug has existed since 1999 and as of yet this feature hasn't been
included in Mozilla. Does someone know when this is going to appear in Mozilla ?
Comment 270 Bogdan Stroe 2004-06-21 17:11:34 PDT
*** Bug 247961 has been marked as a duplicate of this bug. ***
Comment 271 bclinger 2004-06-22 00:23:24 PDT
The password situation and lack of interest is the reason I quit participating.
So many ask for it...
Comment 272 Mohit Aron 2004-06-22 12:43:28 PDT
> The password situation and lack of interest is the reason I quit participating.
> So many ask for it...

I suppose this is why Microsoft still has the edge over open source. If these
many requests had been made for Internet Explorer, you can be sure the next
release would have the feature. On the other hand, Mozilla hasn't incorporated
this feature even after 5 years.
Comment 273 Simon Spiegel 2004-06-22 12:49:19 PDT
>If these many requests had been made for Internet Explorer, you can be sure the 
> next release would have the feature.

Sorry for the spam, but this is the most ridiculous statement I've heard in a
long time. The development of IE has basically stopped for several years.
Everybody knows that IE is currently the most outdated browser on the market,
thousands of developers and web designers would be also happy if MS would add
better CSS to their browser. They don't do it because it's against their plans,
they care very little about the real needs of users and web designers.
Comment 274 Matija Polajnar 2004-06-22 14:00:09 PDT
Still, many more would use Mozilla if it had this future ...
Comment 275 Mohit Aron 2004-06-22 16:09:25 PDT
> Sorry for the spam, but this is the most ridiculous statement I've heard in a
> long time. The development of IE has basically stopped for several years.
> Everybody knows that IE is currently the most outdated browser on the market,
> thousands of developers and web designers would be also happy if MS would add
> better CSS to their browser. They don't do it because it's against their plans,
> they care very little about the real needs of users and web designers.

95% of browsing is still done using IE. If Microsoft felt its user base is 
threatened due to lack of some feature, it is sure to add it.

And whatever is being done on IE is no excuse for letting this bug lie dormant
for 5 years in Mozilla ...
Comment 276 Jason Bassford 2004-06-22 18:34:10 PDT
> And whatever is being done on IE is no excuse for letting this bug
> lie dormant for 5 years in Mozilla ...

Enough spam.  One reason this bug has taken so long to resolve is because of the
noise/sound ratio.  This is a volunteer effort.  If you want to contribute
something useful then come up with a patch for review.  Complaining nothing
being done is a sure way of ensuring that nothing WILL be done because nobody
will feel like contributing in a negative atmosphere.

So everybody please follow the appropriate etiquette as just mentioned in the
Status Whiteboard.  No more comments on why or why not this should be
implemented!  Only technical comments from here on out please.

(BTW: This was not meant to be taken personally by anybody.  FWIW I'm a strong
advocate for getting password protection in place.  But any comment for or
against at this point is nothing other than counter-productive.  This is now
comment #276 and it's all been said already - many times over.)
Comment 277 Scott Brawner 2004-06-23 10:18:18 PDT
(In reply to comment #273)
> The development of IE has basically stopped for several years.

Just wanted to point out that this is not the case anymore:
http://blogs.msdn.com/dmassy/archive/2004/06/16/157263.aspx

Microsoft is waking up to the threat that Mozilla and Opera pose. They are
actively seeking feedback from users on what features they would like to see
implemented as well.

I know that up until AOl cut the cord that Mozilla was more of a developer's
version of the Netscape browser and therefore was not intended to implement
features such as this. However, it is obviously a consumer product now and user
demand should be taken into consideration when determining what to work on. This
bug has 92 votes and yet the last submitted work on it was from Dec 2002. That
just doesn't make sense to me.

Comment 278 Daniel Wang 2004-06-26 15:24:43 PDT
*** Bug 248762 has been marked as a duplicate of this bug. ***
Comment 279 Pauli "suokko" Nieminen 2004-07-01 22:52:02 PDT
I can begin to work with this bug after I got out of millitary service in
November. I think that this is worth of doing as option for users. The insecure
way to do is enought for ppl how aren't using file protecting os.

(I'm new to mozilla project so I need something to begin with)
Comment 280 Brian 'netdragon' Bober 2004-10-03 23:22:31 PDT
Another application for this could be bug 262762 - Method to keep adware and
malicious extensions and plugins from being added without user's knowledge. 
Doesn't exactly depend on this since there are other ways to accomplish it.

We could offer two forms of encryption: and munging of data for privacy, and
strong encryption. See https://bugzilla.mozilla.org/show_bug.cgi?id=19184#c30
for details.
Comment 281 Reece H. Dunn 2004-10-08 09:10:11 PDT
I am in favour of a feature like this. Here are a few ideas and comments about
how it should behave:
*  It should work cleanly with Firefox extensions. That is, the preferences for
extensions should be password protected in the same way as the main Firefox
preferences. This would allow me to, for example, block certain sites as an
administrator (using the AdBlocker extension), so regular users can't change
this list. From an implementation PoV, perhaps having integrated preferences
where extensions integrate their preferences into the Firefox preferences
instead of having them within the extension itself (e.g. in an "extension" section).
*  I basically want to set an administrator-style password that would allow you
to modify the prefences (and change/update the password) upon entering a correct
password. Thus, anyone who does not know the password will not be able to alter
the browser settings. The password should be required every time you select
"Tools -> Options...". In terms of implementation, all this really needs is a
"please enter password..." prompt before allowing access to the preferences dialog.
*  If you are not worried about altering preferences, having the administrator
password empty would skip the "please enter password..." prompt.
Comment 282 Jason Bassford 2004-10-08 09:16:39 PDT
> It should work cleanly with Firefox extensions.
 
<sigh> This is not a Firefox bug.  It's targeted against Mozilla (Seamonkey) and
may, or may not, be ported over to Firefox in some fashion if it ever does get
implemented.  If you want to see this appear in Firefox, please check to see if
there's one open for it already, if there was one that was WONTFIXd (not at all
unlikely), and, if neither of those is the case, file a new bug against Firefox
specifically.
Comment 283 Gerry 2005-02-08 09:38:16 PST
Yeah I also want to see it ported over to Firefox. I truely couldn't agree more
with every single one of Peter Lairo's posts, that were related to the
implimentation of this bug. I think it sad that this bug has been left
unimplimented for so long.

FYI: I run Windows at home with only one user account for the entire family, for
various good reasons (which would take too long to explain). However it would be
great to have some sort of (even insecure) password protection that would be
enough to keep the computer illiterate members of my family from messing with my
profile.
Comment 284 Matija Polajnar 2005-02-08 11:32:38 PST
I have the same situation under Windows, but I would like at least some simple
(Caesar shift?:) encryption algorythm, just to make sure intruders can't read
e-mail folders "by hand" (text viewer), possibly by discovering the files just
"accidently" (huh, what's in this file - wow, these are his emails! ...).
Comment 285 Matija Polajnar 2005-02-08 11:33:56 PST
I have the same situation under Windows, but I would like at least some simple
(Caesar shift?:) encryption algorythm, just to make sure intruders can't read
e-mail folders "by hand" (text viewer), possibly by discovering the files just
"accidently" (huh, what's in this file - wow, these are his emails! ...).
Comment 286 Simon Lucy 2005-02-09 02:50:12 PST
Life hasn't changed.  If you create separate users in the OS then you get
separate profiles, it isn't this application's responsibility to manage the
users of the machine.
Comment 287 Jason Bassford 2005-02-09 04:56:10 PST
> it isn't this application's responsibility to manage the
> users of the machine

If that were really true, then Mozilla wouldn't have its own profile manager.
Comment 288 Simon Lucy 2005-02-09 05:26:33 PST
Profiles are not necessarily about users.
Comment 289 Gerry 2005-02-09 23:35:59 PST
(In reply to comment #286)
> Life hasn't changed.  If you create separate users in the OS then you get
> separate profiles, it isn't this application's responsibility to manage the
> users of the machine.

I don't want that, I want it to manage users of the application.
Comment 290 chunyip.geo 2005-02-11 02:53:20 PST
I find an extension called ProfilePassword. It claims to provide password
protect at interface level, but not file level. However I am not sure whether it
is safe enough and bug free as its version is 0.5

See URL below.
https://nic-nac-project.de/~kaosmos/profilepassword-en.html
Comment 291 Gerry 2005-02-11 11:18:44 PST
(In reply to comment #290)
> I find an extension called ProfilePassword... However I am not sure whether it
> is safe enough and bug free as its version is 0.5

Yeah me either. I couldn't even find a screenshot and Google only provides a few
links on the extension, none of which were helpful. When I try accessing the
site I also receive warnings about the certificate that is being used. Does
anybody here know anything about the extension?
Comment 292 Jo Hermans 2005-05-31 12:45:26 PDT
*** Bug 296105 has been marked as a duplicate of this bug. ***
Comment 293 Martin Wildam 2005-06-01 12:11:34 PDT
(In reply to comment #291)
> (In reply to comment #290)
> > I find an extension called ProfilePassword... However I am not sure whether it
> > is safe enough and bug free as its version is 0.5
> 
> Yeah me either. I couldn't even find a screenshot and Google only provides a few
> links on the extension, none of which were helpful. When I try accessing the
> site I also receive warnings about the certificate that is being used. Does
> anybody here know anything about the extension?

I am using the profile password extension since some weeks without any problem.
Comment 294 yamahog66 2005-06-30 15:01:09 PDT
just a simple password to open the user local folders (inbox etc)
nothing  more is needed, like Foxmail has.
just to keep out the kids when you go to the bathroom, exit TB, and reopening 
asks for PW on any action. get, send, look in inbox.
K.I.S.S.


Comment 295 Matthias Versen [:Matti] 2005-06-30 19:27:55 PDT
*** Bug 299304 has been marked as a duplicate of this bug. ***
Comment 296 Steve England [:stevee] 2006-08-07 05:03:27 PDT
*** Bug 347726 has been marked as a duplicate of this bug. ***
Comment 297 Steve England [:stevee] 2006-08-07 05:04:34 PDT
*** Bug 347724 has been marked as a duplicate of this bug. ***
Comment 298 Daniel Veditz [:dveditz] 2007-03-12 10:24:10 PDT
*** Bug 373620 has been marked as a duplicate of this bug. ***
Comment 299 Daniel Veditz [:dveditz] 2007-05-21 11:08:39 PDT
*** Bug 381399 has been marked as a duplicate of this bug. ***
Comment 300 :Gavin Sharp [email: gavin@gavinsharp.com] 2007-05-21 22:09:47 PDT
*** Bug 381536 has been marked as a duplicate of this bug. ***
Comment 301 Daniel Veditz [:dveditz] 2007-05-25 18:39:52 PDT
*** Bug 336838 has been marked as a duplicate of this bug. ***
Comment 302 Francis Balfe 2007-10-09 15:20:00 PDT
I wanted to log an RFE and a bug against the Software Security Device (SSD) but it seems that there are two views with regards to bugs logged against it.

1. Those who are just users Thunderbird who think the SSD should lock access to the Thunderbird app.
2. Those who contribute to Thunderbird who know what SSD is and think the SSD should only protect passwords (as it was designed for).

My RFE would be to add an option in Tools->Options->Privacy to use a Master Password to lock Thunderbird so as to hide access to locally stored mail through the Thunderbird application (not encrypt the mail folders)
This would also clear up the bugs/RFEs that have been logged against the ability to 'x' out of the SSD several times and 'gain access' to the locally stored mail

Another RFE/bug I had related to this was that my accounts (and their local folders) and the message view panes were visible prior to me entering my password for the SSD. I, assuming that SSD was a Thunderbird lock, was annoyed that others could see my message subjects and senders (as well as my local folders)

All these RFEs/bugs seem to arise from average (not contributing) users thinking that the SSD locks the Thunderbird application (as you would lock your computer). This is a very easy assumption to make and I was under the same impression until I read up on the bug lists.

Should this be logged as an RFE or are the average users like myself going to be told to stop being stupid, "don't you know the SSD is to protect your passwords" ?
Comment 303 zug_treno 2008-01-28 16:09:22 PST
*** Bug 342378 has been marked as a duplicate of this bug. ***
Comment 304 Matthias Versen [:Matti] 2008-08-22 08:27:35 PDT
*** Bug 451685 has been marked as a duplicate of this bug. ***
Comment 305 shrek-m 2009-02-27 14:26:17 PST
i have found what i need.
these should be in tb or at least official add-ons.

http://nic-nac-project.org/~kaosmos/
ProfilePassword
ProfileSwitcher

you can protect your profiles with passwords
you can protect your current thunderbird window
you get a message that this is no real protection



additional info - tb3 beta 2
tb is asking for the master password if you have one.
nice but not directly what i am looking for.
Comment 306 Ludovic Hirlimann [:Usul] 2009-05-23 02:21:53 PDT
*** Bug 494545 has been marked as a duplicate of this bug. ***
Comment 307 Daniel Veditz [:dveditz] 2009-09-08 13:58:49 PDT
*** Bug 515236 has been marked as a duplicate of this bug. ***
Comment 308 Ludovic Hirlimann [:Usul] 2009-11-05 05:48:48 PST
*** Bug 526720 has been marked as a duplicate of this bug. ***
Comment 309 mozilla 2009-11-11 09:50:38 PST
Ok, I realise that this is a "P5 enhancement" but it has been over 10 years and this has over 130 votes. Why does Mozilla still have nothing to show for this? Obviously this is something that is highly desired by many people, even if it isn't a perfect solution it is at least *something* beyond what we have now.

If I wasn't so busy with school (as I probably will be for the next 2 or 3 years) I would look into working on this myself.
Comment 310 Jason Bassford 2009-11-11 10:09:21 PST
In the latest trunk builds of SeaMonkey this is now *almost* implemented if you've set a master password.  Now, when you launch SeaMonkey, you get prompted for your master password before you get to the browser UI proper.   The only problem is that if you hit <Esc> (twice I think) SeaMonkey finishes loading anyway.  If it forced you to enter a correct master password, and not let you <Esc> past it, I'd almost consider this bug fixed...
Comment 311 Daniel Veditz [:dveditz] 2010-02-20 13:25:17 PST
*** Bug 547436 has been marked as a duplicate of this bug. ***
Comment 312 Robert Longson 2010-02-26 02:24:01 PST
*** Bug 548780 has been marked as a duplicate of this bug. ***
Comment 313 Jo Hermans 2010-03-14 16:28:33 PDT
*** Bug 552335 has been marked as a duplicate of this bug. ***
Comment 314 Jo Hermans 2010-05-03 02:15:19 PDT
*** Bug 563292 has been marked as a duplicate of this bug. ***
Comment 315 Mike H 2010-05-09 19:52:42 PDT
In case this has not been mentioned before, one possible workaround would be to create a dedicated user account within your operating system just for your email account, and then use the "runas" (or equivalent) command to run the application under that account. In Windows XP (and later using the sysinternals patch) you can even select the "runas" option from the right-click menu of the program shortcut.

The only other thing you might want to do is make the account invisible from the login screen. Not sure how to do this in Windows though.
Comment 316 :Gavin Sharp [email: gavin@gavinsharp.com] 2010-07-06 09:32:07 PDT
*** Bug 577105 has been marked as a duplicate of this bug. ***
Comment 317 Daniel Veditz [:dveditz] 2010-08-27 12:44:34 PDT
*** Bug 591360 has been marked as a duplicate of this bug. ***
Comment 318 heraldo 2011-01-25 23:54:29 PST
Just use Truecrypt already, this will probably never be implemented in Firefox / Tbird.
Comment 319 Charles 2011-02-08 07:14:54 PST
(In reply to comment #318)
> Just use Truecrypt already, this will probably never be implemented in Firefox
> / Tbird.

Truecrypt doesn't solve the problem of a shared computer with multiple users accessing the same Thunderbird, but different TB profiles...

Profile password protection would seem to me to be a necessity... but I don't happen to use it that way, so it isn't a problem for me...
Comment 320 [Baboo] 2011-02-28 09:44:02 PST
(In reply to comment #319)
> 
> Truecrypt doesn't solve the problem of a shared computer with multiple users
> accessing the same Thunderbird, but different TB profiles...

It is possible to have a profile folder on a different partition. Also, it might be possible to have a folder point to the contents of a partition.
Comment 321 Matthias Versen [:Matti] 2011-06-18 10:01:00 PDT
*** Bug 665287 has been marked as a duplicate of this bug. ***
Comment 322 Martin Wildam 2011-08-19 07:49:29 PDT
Since this exists since 1999, I also do not think this gets implemented any more.

In former times there were several issues with Windows when not working under an Administrator-enabled account and logging on two users in parallel wasn't possible either. I assume both is possible now without hassle with Windows 7 (even if I don't care anymore, because switched to Linux on all of my boxes and hence my Thunderbird profile is put under my user home with appropriate limited permissions and same applies to my wife and we both can be logged in in parallel just switching sessions).

When I subscribed to this bug many years ago, I was still on Windows, only having one computer in a shared use. The need to log off and on all the time was annoying even if I just wanted to do a short email check. Quick email check nowadays is even quickly done with the mobile phone and anyway I have my own machine now.

So I don't see the need of this feature any more either.

So I think, it is time to set this to "WONTFIX".
Comment 323 spiralofhope 2011-08-19 09:06:15 PDT
@Martin Wildam
> Since this exists since 1999 ...
A bug is not invalid just because it is old.

> In former times there were several issues ...
A bug is not invalid because your version of your operating system has a workaround.

---

This issue is valid for everyday users on older computers.  So the question becomes:  Since there is a reasonable solution[1] on a contemporary computer, does support for older computers matter?

The answer is:  Yes, but not by Mozilla.  Microsoft's older operating systems are designed to be insecure, and should not be used or supported by Mozilla.  Use the current insecure Windows.  =)

So this bug could be closed because direct support seems like misplaced effort.  Or this bug could stay open to allow community development.

Even if some partial implementation is accepted into the mainstream Firefox, it would be easier for simple users to use this functionality than set something up at the OS level.  I argue that it's reasonable to implement minor "silly" features for simple users.

The uncomfortableless of a "this security isn't secure" warning screen shouldn't prevent a feature like this.  Teaching users about the horrors of security should be every developer's sadistic pleasure.  >=)


[1] - Separate OS login, "run as <user>".
    - Optional encryption at the OS level.
Comment 324 Benjamin Smedberg [:bsmedberg] 2011-08-19 09:25:51 PDT
To avoid further confusion and bugmail, I will happily decide to close this bug. Please do not comment in it further.
Comment 325 Flávio Etrusco 2011-08-19 10:39:49 PDT
@spiralofhope Only 'Professional' and up versions have file and disk encryption.
@Benjamin: I don't see the point of closing a bug with 134 votes just because it's old. Will we close as WONTFIX every P5 bugs?
I bet won't be a long time before interest in this is revived because of Fennec...
Comment 326 :aceman 2011-09-27 13:12:43 PDT
The ProfilePassword extension is still alive. Is it not enough?
https://nic-nac-project.org/~kaosmos/profilepassword-en.html#PPFF
Comment 327 spiralofhope 2011-09-27 14:20:37 PDT
(In reply to Flávio Etrusco from comment #325)
> @spiralofhope Only 'Professional' and up versions have file and disk
> encryption.

Good point.


(In reply to aceman from comment #326)
> The ProfilePassword extension is still alive. Is it not enough?
> https://nic-nac-project.org/~kaosmos/profilepassword-en.html#PPFF

Comment #290 already brought that up.
Comment 328 Jo Hermans 2012-02-07 02:47:13 PST
*** Bug 607269 has been marked as a duplicate of this bug. ***
Comment 329 jakov 2012-06-24 10:04:37 PDT
Would it be realistic to implement a wizard that helps to install truecrypt and then  creates and mounts a volume for a firefox profile? Truecrypt is FOSS software, so i think a colaboration (if even needed) would benefit both parties and it would be a milestone in security.
Comment 330 Thomas D. (currently busy elsewhere; needinfo?me) 2012-09-06 09:17:12 PDT
*** Bug 788958 has been marked as a duplicate of this bug. ***
Comment 331 Thomas D. (currently busy elsewhere; needinfo?me) 2012-09-06 09:53:17 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #324)
> To avoid further confusion and bugmail, I will happily decide to close this
> bug. Please do not comment in it further.

Benjamin, don't you think it's a bit odd to just walk in and close down a bug with 141 votes and 35 duplicates (and counting) with an ironic two-liner without any explanation of your reasons for this resolution nor of your function within Mozilla that entitles you to do so?

In the same line, "NO SPAM PLEASE" and pointer to netiquette in whiteboard of this bug both sound pretty inpolite given that for a lot of users, this is a real-life UX problem they want to see addressed. It also looks like a case of UX-error-prevention as many users seem to believe that SSD protects their profiles (browser or mail) while it does not. It's common practice for such cases that whiteboard should at least point to an authoritative comment that explains the problems at hand and the reasons for wontfix.
Comment 332 mjfwalsh 2013-10-24 04:24:19 PDT
The problem with TrueCrypt is that you need administrative privileges to install it, so it can't be used by users of Portable Firefox for example.

If this bug is going to stay as a WONTFIX, Firefox's master password feature should be disabled, as it offers only illusory protection.
Comment 333 YF (Yang) 2014-04-27 23:45:08 PDT
*** Bug 1001973 has been marked as a duplicate of this bug. ***
Comment 334 Wayne Mery (:wsmwk, NI for questions) 2014-05-21 08:32:23 PDT
*** Bug 1011956 has been marked as a duplicate of this bug. ***
Comment 335 :aceman 2015-03-13 17:30:04 PDT
*** Bug 939594 has been marked as a duplicate of this bug. ***
Comment 336 Abdy 2015-04-28 10:42:07 PDT
I see this has been closed but I also feel obliged to give my "2 cents".

This feature, though you consider it below yourself is NOT below 98% of your users. All they are asking for is when Firefox is set to open the profile manager and you select the profile you are prompted to enter a password before opening it. Nothing too complex, not it is NOT 100% secure, but as IT professionals really can any of us answer anything that is 100% secure other than a computer shut off and unplugged?

As I write this comment realize Google is already releasing developmental features allowing you to lock a profile and require the password before opening that users profile.

Another piece of advice, you are writing software for your users, think like one and not the IT professional you are. Users want this simple piece of "protection", so what is the IT professionals problem with implementing this "feature"?

Note You need to log in before you can comment on or make changes to this bug.