It just occurred to me that there is no way to set a password that just protects the preferences part of mozilla. This is a major problem for schools and other places that have computers made publically available. At our school, we run a content filtering software through a proxy. The problem is that students can bypass the filter by reseting the proxy prefs to direct connection to the Internet. We have also had problems with students messing up settings in the preferences area. I would really like to see this ability added. I'm filing it as a bug (rather than an enhancement) because this is something that every browser should have. Let's hit IE hard with this release. Keep up the good work, and let me know if I can do anything to help with this project!

i think this would be handled in an enterprise version of the browser, yes? paul/matt, either of you know who should get this in that case?

Why not put it in the base? I'm sure there are more applications for this than just enterprise use. Maybe parent's want to keep their kids for resetting certain things??

confirming as an enhancement. still not sure who/which group should get this...

IMHO, I don't believe this enhancement should be delayed. At the school's technology department we have students tampering with settings and disabling the filtering proxy. The students can then engage in restricted activities. This filtering system is used in numerous schools throughout Nebraska. I believe password protection of the preferences dialog is a low risk/high benefit bug/enhancement. Thank you!

Should the browser security general area get this?

this would prolly be dependent on bug 19184 --and maybe even bug 60466 [or, the earlier version of the latter]. cc'ing gbush.

I'd like to keep this moving if we could. I really think this feature needs to be included. Could we target this mozilla1.0 or so?

Brian, if you're going to implement this yourself, or hire someone to do it, you can set it to any target you like. But bugs don't fix themselves, y'know.

Added help wanted keyword. I'm afraid I'm not going to have time to do this. :(

Nominating Mozilla1.0

Offloading to mozilla1.1

Taking.

See also bug 16489, `Password protection of profiles'.

i'm confused. are .cfg locked preferences really not good enough for you? (see netscape.com's 4.x documentation for more info. I've never used them since i'm not a coporation). secondly, if you only implement a proxy as an option and then are shocked when your students realize they don't need to use it, you're the fools, not them. The proxy was designed for cases where users could not have direct access (it's part of the concept of proxying...), your border between the students and the net should drop most packets on the floor, forcing students to go through proxies that live in your DMZ. Third, password protected profiles don't prevent pref changes, they prevent profile usage. Sorry, this isn't the goal here. Same problem w/ encrypted profiles. Fourth, expecting users not to figure out how to create their own profiles is idiotic. If you indeed represent a school, then I encourage you to *learn* from your students, I know that my peers knew a lot more about what could and could not be done than the people who tried to control computer/internet usage. Step 1 is of course to establish a real firewall that forces proxy usage. Step 2 is to admit that you can't win all the time. Part of this is accepting that unless the users have no writable space, they can duplicate whatever they need to do whatever it takes to get around whatever files you give them. [eg: You give them a profile on a readonly fs, they create a new one somewhere else. You give them a locked profile, they install a new browser.] I don't think that there is a feature we can give you beyond the ones we've already provided that will actually help. That asside, the Kiosk bugs (Bug 3341 and others that are mentioned, linked, or dependent) are probably your best bet. There are lots of problems w/ schools, some of them, in no particular order are: * too little funds * too much overhead * too much belief that technology can save education * too many people who don't think before trying to do something (teach, setup networks, lock networks, buy equipment) i'm clobbering the dependency because it's clear it wouldn't help the reporter. (i don't think we can help the reporter beyond what we've already done, and that should be clear from this comment, but that's unrelated.)

Unless the prefs.js and other relevant files have write permission denied at the operating-system level, there is NOTHING Mozilla can do to prevent the prefs from being changed. You can make it more inconvenient by creating user stylesheets that display: none the menu items for the Preferences panels, but there is readily available documentation all over the web about how to edit prefs.js by hand, and (especially in secondary schools, where a percentage of your users (and it only takes one) know computers about fifty times better than your IT staff) any reasonably determined user who knows how to use Google or Yahoo will find it in five minutes flat. Given motivation to do so, my mom could probably figure out how to do it. This is unfixable by Mozilla. Remember, people don't want to edit config files by hand; they don't like to do it, and in general they won't, but they _can_ figure out how if motivated, and nothing motivates them like somebody saying "you're not allowed to do this". That said, a school could use a locked-down operating system to prevent changes to the prefs files (and other things), but Moz doesn't attempt to write the prefs files until it's exited, so allowing a temporary bypass. Access to the prefs dialogs does also need to be denied in these cases. User stylesheets (which must be also write protected at the OS level) will do this if new-profile-creation is disabled -- which it effectively can be if you have just one default profile and disallow access to the commandline. (Disallowing access to the command line is necessary anyway; you need a custom X setup with no way to get to an terminal window of any kind, and only very limited applications, but that's inherent in such a setup. You also have to prevent physical access to the PC case, because if they can reboot it they can get to single-user mode...) This is all WAY beyond the scope of anything Mozilla can be expected to do, and if you don't do it, your users WILL be able to change the prefs behind Mozilla's back, regardless of anything Mozilla does or does not facilitate. It is possible to make Mozilla prompt for a password before popping up the prefs dialog, but that would be a placebo only, nothing more. Take the trouble to be secure, or don't, but let's not make believe.

retargeting

could this be done by doing a simple test and preventing access to the prefs dialog if the prefs.js file is readonly?

(In reply to comment #14) > secondly, if you only implement a proxy as an option and then are shocked when > your students realize they don't need to use it, you're the fools, not them. > The proxy was designed for cases where users could not have direct access (it's > part of the concept of proxying...), your border between the students and the > net should drop most packets on the floor, forcing students to go through > proxies that live in your DMZ. This is a good argument for a school, but not for a home user. I am interested in password protecting my preferences dialog for my home computer. As Mozilla and Firefox is getting more popular more non-technical parents, who can't set up a home network with a Linux box as a proxy server to the Internet are going to want to use their ISP's content filtering solution. Since most ISP's, like mine, want to allow unrestricted Internet access to most of their users, they only offer a Proxy based solution for those who want server-side (read free) content filtering.

(In reply to comment #15) > This is all WAY beyond the scope of anything Mozilla can be > expected to do, and if you don't do it, your users WILL be > able to change the prefs behind Mozilla's back, regardless > of anything Mozilla does or does not facilitate. > > It is possible to make Mozilla prompt for a password before > popping up the prefs dialog, but that would be a placebo > only, nothing more. > > Take the trouble to be secure, or don't, but let's not > make believe. There is a way to treat the insecure file-system as a untrusted source and still protect the preferences. 1. Require a password for the preferences dialog. 2. Hash that password and use it as the basis for an private key to encrypt a copy of the preferences. 3. Compute an PubKey/PrivKey digitally signed hash of the plaintext preferences. 4. Thow the private key away. 5. Store the digitally signed hash of the preferences file and the public key in plaintext. You can now detect changes to the plaintext version of the preferences file by comparing a has of the preferences file to the digitally signed hash sored by the save operation. If a change is detected, you can prompt for the user to enter the preferences password to re-generate the private key and copy over the plaintext version of the preferences file. This is well within the scope of what Mozilla can do and it can use the existing crypto libraries to do it. The difficult part will be to generate a private key (in a public key - private key cryptosystem) based on the password. But it is doable.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

If preferences would be protected with password, what stops users from creating new profile and set needed preferences there? And if you protect profiles.ini file at OS level, why you can't do the same for prefs.js? Propose WONTFIX this

Resolved per whiteboard