Closed Bug 16489 (profile-password) Opened 25 years ago Closed 13 years ago

Password Protection of Profiles

Categories

(Core Graveyard :: Profile: BackEnd, enhancement, P5)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugs, Unassigned)

References

Details

(Whiteboard: NO SPAM PLEASE. Before you comment, first read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html)

Attachments

(1 file, 18 obsolete files)

20.37 KB, patch
Details | Diff | Splinter Review
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.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: M18
There's a lot more than UI to this.  This isn't yet the right time to worry
about this feature.
*** Bug 16850 has been marked as a duplicate of this bug. ***
*** Bug 17186 has been marked as a duplicate of this bug. ***
OS: Windows 95 → All
Hardware: PC → All
Component: Profile Manager → Profile Manager BackEnd
Moving all Profile Manager bugs to new Profile Manager Backend component.
Profile Manager component to be deleted.
Reassigning to myself. 
Assignee: selmer → racham
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
*** Bug 44495 has been marked as a duplicate of this bug. ***
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?
*** Bug 26825 has been marked as a duplicate of this bug. ***
This calls for architectural changes for profilemanager code. Not doing it in
beta3. Moving the milestone to future.
Target Milestone: M18 → Future
*** Bug 60466 has been marked as a duplicate of this bug. ***
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).
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.
Assignee: racham → ccarlen
Status: ASSIGNED → NEW
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.
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. 
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 ;-)
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.
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.
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.
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
But lets also remember that password protection of profile was quickly dropped. 
It only appeared in 4.5 not in 4.7
...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.
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
.. 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.
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.
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.
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).
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).
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.
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.
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.
Blocks: 63092
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.
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'.
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".
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.
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.

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.

> 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.
And what happens if someone edits the plain text file which contains the
preference removing the password setting or reverting it?

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."
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.
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.
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).
 
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).
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.
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.
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!
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.


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?)?
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).
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.
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.
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.
> 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.
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.
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...?
could then someone who has the authority please add the keyword: helpwanted ?
Should this also be reassigned to nobody@mozilla.org?
Keywords: helpwanted
> 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. 

I really want Profile passwords to be implemented, even if it does not really 
secure the files.
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
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."
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.
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.
Assignee: ccarlen → nobody
Priority: P3 → P5
Whiteboard: [DONT SPAM] [LOOKING FOR VOLUNTEERS TO IMPLEMENT]
*** Bug 74636 has been marked as a duplicate of this bug. ***
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.
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.
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
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
OK, I've got the support of Juraj Betak on this, it's coming on nicely. Setting
assigned to moi

-mike
Status: NEW → ASSIGNED
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.
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.
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
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)
Assignee: nobody → mhearn
Status: ASSIGNED → NEW
Whiteboard: [DONT SPAM] [LOOKING FOR VOLUNTEERS TO IMPLEMENT]
Target Milestone: Future → mozilla0.9.3
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
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?
Keywords: helpwanted
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
Status: NEW → ASSIGNED
No problem Mike, my patch already has such a disclaimer :)

thanks for the screenshot though -mike
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...

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
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
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.
OK thanks Juraj, glad you're back on the case
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...
for some reason the last two attachments cannot be viewed or downloaded in build
2001-07-13 (bug?)
Hey thanks Juraj, it's coming on well :) Do you have anyone to r and sr?
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
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
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.
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).
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.
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.
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/>
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
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.
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.
For the properties dialog please see:
http://bugzilla.mozilla.org/show_bug.cgi?id=25196
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.
> 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 :-)
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...
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.
Whiteboard: [LGPL CODE included in current patch]
>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.
>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.
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.
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.
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).
Depends on: 91384
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.
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.
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, ...
is there a spec on mozilla.org for this new UI?
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.
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
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.
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.
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.
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
> 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.
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. :-)
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".
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. 
adding Paul Johnston to the cc list...
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
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.
Depends on: 92054
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.
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.
> 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>
this sounds like the "no security is better than false security" argument that
jar always talks about.
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.
<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\>
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').
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.
Changed email address, since subD suddenly decided they can't be bothered
running email any more, damn them.
Assignee: mhearn → mhearn
Status: ASSIGNED → NEW
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.
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
Target Milestone: mozilla0.9.4 → mozilla0.9.5
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.
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.
>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?
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.
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.
[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]
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.
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."
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.
do we plan to encrypt all the users data?  (bookmarks, prefs, local mail files,
including summaries?)
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?
if it was an extension, that could be optionally built (and optionally turned
on/off) that would solve impasse.

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.
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.
<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>
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.
[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]
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.
<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>
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.
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.)
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?
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...
>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.
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

What is the status of the patch? Is it ready to be checked in? What is the next
required step (jbetak, mpt)?
At least the application registry issue needs to be resolved, and then the
patches need to make it through review and super-review.
> 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.

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?
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
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.
> 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 :-)


ok thanks juraj. I've just found I'm not authorized to edit attachments, so can
somebody give me those access rights?
Michael: access granted
Attachment #37322 - Attachment is obsolete: true
Comment on attachment 38283 [details]
First XUL/JS/DTD patch for profile passwords

obsoleting bug. aplogies for the spam
Attachment #38283 - Attachment is obsolete: true
Thanks Juraj, do you know when the latest DLL will be posted? thanks -mike
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...
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
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
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
Target Milestone: mozilla0.9.5 → mozilla0.9.6
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.
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)
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. 
Well if you want to go that way then please make this extension honor
--enable-crypto and --disable-crypto.
Whiteboard: [LGPL CODE included in current patch]
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>
Whiteboard: [LGPL CODE included in current patch]
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.
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.
Whiteboard: [LGPL CODE included in current patch] → [Aufbau-P3] [LGPL CODE included in current patch]
Whiteboard: [Aufbau-P3] [LGPL CODE included in current patch] → [LGPL CODE included in current patch]
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
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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 ???
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?
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
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
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.





  
Attached patch Patch - 6th Dec 2001 (obsolete) — Splinter Review
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
Mass-obsoleting bugs using the new attachment feature. Well, I had to attach
something, didn't I?
Attachment #37881 - Attachment is obsolete: true
Attachment #38284 - Attachment is obsolete: true
Attachment #41678 - Attachment is obsolete: true
Attachment #42267 - Attachment is obsolete: true
Attachment #42268 - Attachment is obsolete: true
Attachment #42308 - Attachment is obsolete: true
Attachment #42606 - Attachment is obsolete: true
Attachment #42966 - Attachment is obsolete: true
Attachment #42967 - Attachment is obsolete: true
Attachment #42977 - Attachment is obsolete: true
Attachment #43312 - Attachment is obsolete: true
Attachment #43315 - Attachment is obsolete: true
Attachment #49288 - Attachment is obsolete: true
Attachment #60693 - Attachment is obsolete: true
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.)
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.
Attached patch Latest patch as of 7/12/2001 (obsolete) — Splinter Review
Changed "Password" to "New Password" as per sean cotters suggestion. Now to go
and bug ben about reviewing this one

thanks -mike
OK, ben is clearly not interested in this at all. MPT, can you give this patch
r= for the front end?

thanks -mike
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
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.

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.
Whiteboard: [LGPL CODE included in current patch] → [LGPL CODE included in current patch] NO SPAM PLEASE
"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.
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
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.
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).
Status: NEW → ASSIGNED
Whiteboard: [LGPL CODE included in current patch] NO SPAM PLEASE → NO SPAM PLEASE
Shouldn't Target Milestone be updated?
Target Milestone: mozilla0.9.7 → ---
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. 
Okay thanks Ben, I'll go poke someone in IRC to help review this
thanks -mike
how about timeless - he has spent considerable amount of time looking into this 
already...
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
Blocks: 123569
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.
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)
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.
Keywords: mozilla1.1
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?
Reassigning to his new e-mail address. P.S. Go, Mike, go!
Assignee: mhearn → mike
Status: ASSIGNED → NEW
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
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
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
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
*** Bug 157838 has been marked as a duplicate of this bug. ***
*** Bug 167215 has been marked as a duplicate of this bug. ***
Summary: [RFE] Password Protection of Profiles → Password Protection of Profiles
Could someone (ANYONE) with sufficient rights please update the keyword for this
bug? i.e., "mozilla1.3"
Keywords: mozilla1.1mozilla1.3
Mike, I'm tentatively reassigning this
Assignee: mike → jay
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
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".

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.
Status: NEW → ASSIGNED
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.
> 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.
> 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.
> 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.
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?
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
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:"
> "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.)
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".
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: __________
Blocks: majorbugs
*** Bug 196320 has been marked as a duplicate of this bug. ***
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. 
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.
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?
Keywords: mozilla1.3
Blocks: 98346
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.
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!
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.
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 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.
Attachment #60805 - Attachment is obsolete: true
Wow... 4 years this has been pending, and essentially no progress.  Impressive.
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"
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.
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.
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? :)
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
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.
*** Bug 227086 has been marked as a duplicate of this bug. ***
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.
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)
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.
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.
*** Bug 243622 has been marked as a duplicate of this bug. ***
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 ?
*** Bug 247961 has been marked as a duplicate of this bug. ***
Whiteboard: NO SPAM PLEASE → NO SPAM PLEASE. Before you comment, first read http://bugzilla.mozilla.org/page.cgi?id=etiquette.html
The password situation and lack of interest is the reason I quit participating.
So many ask for it...
> 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.
>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.
Still, many more would use Mozilla if it had this future ...
> 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 ...
> 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.)
(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.

*** Bug 248762 has been marked as a duplicate of this bug. ***
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)
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.
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.
> 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.
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.
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! ...).
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! ...).
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.
> 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.
Attachment #60696 - Attachment is obsolete: true
Profiles are not necessarily about users.
(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.
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
(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?
No longer blocks: majorbugs
*** Bug 296105 has been marked as a duplicate of this bug. ***
(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.
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.


*** Bug 299304 has been marked as a duplicate of this bug. ***
*** Bug 347726 has been marked as a duplicate of this bug. ***
*** Bug 347724 has been marked as a duplicate of this bug. ***
Alias: profile-password
Assignee: jay → nobody
Status: ASSIGNED → NEW
QA Contact: agracebush → profile-manager-backend
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" ?
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.
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.
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...
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.
Just use Truecrypt already, this will probably never be implemented in Firefox / Tbird.
(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...
(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.
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".
@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.
To avoid further confusion and bugmail, I will happily decide to close this bug. Please do not comment in it further.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
@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...
The ProfilePassword extension is still alive. Is it not enough?
https://nic-nac-project.org/~kaosmos/profilepassword-en.html#PPFF
(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.
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.
(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.
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.
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"?
Product: Core → Core Graveyard
See Also: → 35308
You need to log in before you can comment on or make changes to this bug.