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.

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. ***

Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.

Reassigning to myself.

*** 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.

*** 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.

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.

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?

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

*** 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

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)

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?

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

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.

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

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.

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.

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.

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

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

Comment on attachment 38283 [details] First XUL/JS/DTD patch for profile passwords obsoleting bug. aplogies for the spam

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

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.

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>

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.

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

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.

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?

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.

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.

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

Shouldn't Target Milestone be updated?

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

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.

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!

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. ***

Could someone (ANYONE) with sufficient rights please update the keyword for this bug? i.e., "mozilla1.3"

Mike, I'm tentatively reassigning this

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.

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: __________

*** 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?

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.