Closed Bug 267888 Opened 20 years ago Closed 5 years ago

Windows Group Policies support (make Firefox configurable with domain group policy objects)

Categories

(Firefox :: General, enhancement)

All
Windows
enhancement
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: tvdham, Unassigned)

References

(Blocks 2 open bugs, )

Details

Attachments

(7 files)

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: Firefox v1.x

Group Policy support in the windows version of Mozilla / firefox would be good 
for central configuration to be pushed, for example proxyserver settings.

Reproducible: Always
Steps to Reproduce:
I'd like to add my own 2 cents to the issue

Firefox's main object... conquest of the enterprise and education market is not
currently possible until Firefox is controlable by Group Policy and/or through
Active Directory

Interopability with the built-in Windows "Favorites" feature would be a plus as
well (plus its a kinda pain having to manage two separate Favorites/Bookmarks lists)

On SlashDot, we hear stories of people approaching their SysOps to install
Firefox, only to be turned down... citing security concerns... the security
isn't with Firefox, but rather... because Firefox isn't controlable via Active
Directory, that the company's "wishes" to prevent the internet being used for
non-productive reasons (Read: surfing over to miniclip.com during a meeting)

Surely integration with Group Policy, Active Directory, and the existing Windows
infrastructure can't be too hard?

And an official MSI release would be of benifit too... as it would allow SysOps
to install Firefox without having to do things manually, nor hunt around Google
for an appropriate package

Perhaps if Mozilla.org/Products/Firefox linked to this page?
"http://biomicro.mit.edu/people/patpaul/mozilla-msi.html" [Mit.edu]

After pains to incorporation of Mozilla in some Czech University I
think we really *need* Group Policy implementation. Some ideas why and
how is possible to make it.

Why?

Window admins like it 8-) You cannot want for them to learn settings
for each installed program. Instead of they want some common
principles (Group Policy). Once implemented you only need to make text
ADM Policy files which defines you configuration. Mozilla.org or some
people from community can create large ADM file or many simple ADM
files specialized for large and small sites (e.g. one for proxy and
homepage, one for security etc.) - ADM files are simple and
localizable plain text files with help (simple example in attachment).
And admin can use them via PolEdit (free) where they can only click
and click to set up Mozilla or Firefox in small network to simply
setup more user profiles from Win98 to WinXP on several computers.
Large organizations can use them on Windows Server (more powerfull
than PolEdit 8-) to simply prepare thousand of user profiles.

Advantage?
They can setup e.g. 1000 of accounts on the first try and really do
not now nothing about Mozilla or Firefox configuration and pref.js
files. 


How?

Mozilla and FF are multiplatform and nobody want to break it. Well,
Mozilla preferences are stored in text files, Group Policy can use
only registry. Grrr! What compromise? Can we Mozilla on WIN32 look for
some predefined values in registry too? Yes? Because this can solve
everything.

E.g. branch:
HKLM(HKCU)\Software\Mozilla\Mozilla Firefox\Preferences

containing:

browser.startup.homepage
network.proxy.http
etc.

We can implement strings, numbers and booleans here like in Mozilla prefs.

Mozilla:

1) read default values from defaults/pref/*.js and greprefs/*.js
2) and user values from PROFILE/prefs.js 

We need to incorporate one step: read values from e.g.
"HKLM(HKCU)\Software\Mozilla\Mozilla Firefox\Preferences" probably
between step 1 and 2, which means that users can still change their
prefs. But exact sequence (and choose between HKLM and HKCU) is
discutable.

If it meens that Mozilla will look in registry more often so it can
slow it, we can have some default pref("general.groupPolicy.enable",
false); for people who do not want this feature.


This is my simple idea. I am afraid that many people hate registry and
one-platform (especially Windows-only) solutions. But I am afraid also
that if we do not implement Group Policy or someting such efficient,
the door of large networks will be closed for us.
Example of simple ADM file for proxy, homepage and JavaScript settings (real
ADM files can be more large, look in Windows Resource kit)
Screenshot of PolEdit with ADM file from attachment #173560 [details] (on Windows Server,
there are some more efficient tools then this simple poledit.exe 8-)
> Why? [...] You cannot want for [an admin] to learn settings for each installed
> program.

I think an admin of a 1000-seat network won't have much choice of learning about
Mozilla's preferences system, Group Policy or ADM yes or no.
Note that you may not want MSIE to use the same HTTP proxy as Mozilla, because
you  don't want MSIE to talk to the Internet.
> I think an admin of a 1000-seat network won't have much choice of learning about
> Mozilla's preferences system, Group Policy or ADM yes or no.

May be. I have response from some admin which want Firefox, but won't do it
without Group Policy. If some company decide to use Mozilla then it will
calculate costs. Training of admins for configuring Mozilla preferences will
cost some money (and they very probably know Group Policy already).

> Note that you may not want MSIE to use the same HTTP proxy as Mozilla, because
> you  don't want MSIE to talk to the Internet.

Probably you do not exactly understand this solution. There is no restriction
for same proxy for IE and Mozilla. This proposal is only about storing/using
some values from registry which can be distributed via system of Group Policy in
the network in user profiles. Thats all, but this can do a lot (ask some admin).
(In reply to comment #2)
> Mozilla and FF are multiplatform and nobody want to break it. Well,
> Mozilla preferences are stored in text files, Group Policy can use
> only registry. Grrr! What compromise? Can we Mozilla on WIN32 look for
> some predefined values in registry too? Yes? Because this can solve
> everything.
> E.g. branch:
> HKLM(HKCU)\Software\Mozilla\Mozilla Firefox\Preferences

No! You shouldn't use this registry location for registry keys that you want to 
configure using Group Policy.

*Please* follow the Microsoft guidelines here:
http://msdn.microsoft.com/library/en-
us/policy/policy/implementing_registry_based_policy.asp

*All* registry keys to be altered with Group Policy should be under a subkey of 
either:
HKEY_CURRENT_USER\Software\Policies
or
HKEY_LOCAL_MACHINE\Software\Policies

I quote:
'You can create registry keys in the folder of your choice, at one of the 
previously listed Policy keys. However, it is recommended that you mimic the 
directory structure of any associated preferences that you have under the 
Policies key that you suggest'

There is a good reason for this, the Policies key is locked down by default so 
that users can't change the settings, and I think it also gets cleared out 
every time Group Policy gets refreshed, so that settings don't 'tattoo' the 
registry of the system. (That is, if you set an option, and then later unset 
it, then unless it's in the above registry keys, it'll stay set, which is not 
the behaviour that Windows admins will expect. In Group Policy, if you set and 
then subsequently unset an option, the expected behaviour is that it goes back 
to the default.)

Also, cosmetically, you won't be able to see the policy settings by default in 
the Group Policy editor unless they're in the above registry keys. (You'd have 
to disable the 'Show Policies Only' option - which is enabled by default 
precisely because Microsoft want you to avoid using policies that will tattoo 
your system).

Whoever gets round to implementing this, please read the above Microsoft 
guidelines first. Let's get it right!
Short URL for MSDN link in above post:
http://tinyurl.com/rbi0
*** Bug 271351 has been marked as a duplicate of this bug. ***
Further to my previous post about the location of the registry keys, here are 
some suggestions about how to implement it.

Comment #2 has a good solution - however, I don't agree with all of it, so here 
is my suggestion, based on my own experience 

of using Group Policy in a Windows 2000/XP/2003 environment.

First off, you need to understand that when you set a policy in Group Policy, 
admins expect it to be just that, a policy, NOT 

a preference. So whatever gets set in the registry has to override whatever 
preferences the user has set in their profile, or 

whatever preferences are set up on the machine. The whole point of Group Policy 
is that admins can force certain settings to 

be applied across the network, no matter what.

Currently per-computer preferences are stored in 'greprefs' 
and 'defaults/pref/*.js' inside the Mozilla install directory, 

and per-user preferences are stored in PROFILE/prefs.js

This makes for (I paraphrase from Comment #2) a preference reading order of:

1) Per machine preferences from 'greprefs' and 'defaults/pref/*.js' (not sure 
how these two interact, or if certain settings 

go in one and certain in another, but it's not so important to know for our 
purposes right now really).
2) Per user preferences from PROFILE/prefs.js.

In other words, per user preferences override per machine preferences. Good 
stuff.

I don't know how FireFox is coded, but I guess there must be a subroutine 
somewhere that reads the settings in from these 

files and works out what the 'active' setting is.

What I suggest, similar to what Comment #2 suggested, is something like this:

Policy registry values are read from two registry keys:
HKLM\Software\Policies\Mozilla\FireFox
HKCU\Software\Policies\Mozilla\FireFox

Inside these keys are any number of values which take their name from the 
original Mozilla configuration values that they are 

overriding - e.g.
'browser.startup.homepage'
'network.proxy.http'
'network.proxy.http_port'

These values will be populated by .pol files created by PolEdit or the Group 
Policy Editor - the programmers of Mozilla don't 

need to worry about creating them, just reading them. We can worry about making 
the .ADM files with the settings that most 

people will need later.

If the original Mozilla value is a boolean, then FireFox should expect the 
Registry value to be a REG_DWORD set to either 1 

or 0.

If the original Mozilla value is an integer, then the Registry value should be 
a REG_DWORD.

If the original Mozilla value is a string, then the Registry value should be a 
REG_SZ.

When Mozilla reads in a setting, it should do so in the following order:

1) Read the per machine preference files (as at present).
2) Read the per user preference file (as at present).
4) Read in the per user policy value.
3) Read in the per machine policy value.

Then take whatever you end up with as the definitive value.

Alternatively:

1) Read in the per machine policy value. If it's there, stop. If not, carry on.
2) Read in the per user policy value, If it's there, stop, If not, carry on.
3) Do whatever you do at the moment.

(I *think* you'll end up with the same results either way. The second method 
might be a bit quicker).

Basically, the registry policy values should override ANY user or machine 
preferences, and the per machine policy values 

should override the per user policy values. This is the way that most Windows 
policy values work, and the way that Windows 

admins familiar with Group Policy will expect the Mozilla ones to work.

Incidentally, if people want to use the registry to set *preferences* as well 
as policies (that is, the admin sets the 

default value, but the users can change it) then you should store them in a key 
like HKCU\Software\Mozilla\FireFox, in a 

similar format. Maybe the code could be altered to do that as well in future. 
For now, my guess is that most admins want to set things in a way that users 
won't be able to subsequently break them (like proxy settings), which means 
policies.

In another bug it was asked which values would be the best ones to support. To 
be honest, unless Mozilla is coded in a funny 

way, I would say that you would be better off putting the support in to set 
*any* of the configuration values by policy, and 

then let those who create the .ADM template at the end decide which ones they 
want. If you 'hijack' the current routine that 

retrieves the value of a particular preference (please tell me there's just 
one?), and put this code in, it will be instantly 

extensible for *any* new configuration variables that are set up in future 
versions. All that will be needed is a new .ADM 

template to tell PolEdit / the Group Policy Editor about the new values, which 
is trivial.

One more issue. Eventually you should put some code into the actual places 
where these values can be set inside the user 

interface, and 'grey out' (disable) the boxes if a registry based policy is 
set, so that it is clear to users that they 

cannot change these values. That is, if 'browser.startup.homepage' is set in a 
policy, then the 'Home Page' box should be 

greyed out in Options/General. However, this isn't an essential for the moment -
 so long as changing the 'Home Page' box and 

clicking 'OK' has no effect on the actual used value 
of 'browser.startup.homepage'.

It would be nice to get the 'greying out' functionality into about:config 
fairly quickly so that admins can see for 

troubleshooting purposes which options FireFox has set by policy and which ones 
can still be set by the user, but for the 

moment let's just get the restrictions going and worry about the interface 
later.

(Incidentally in XP SP2 Microsoft enabled all of the settings on the Security 
page in Internet Explorer to be set by group 

policy, but they haven't put any 'greying out' code into the actual Security 
page yet. So by default users can change all the 

settings, but they don't have any effect. The current 'recommendation' from 
Microsoft is just to disable the whole Security 

page. So don't worry, even Microsoft do it ;)

Finally, speed issues. As far as I know reading from the registry isn't that 
slow under Windows, but if it was an issue then 

as Comment #2 suggested let's have a new preference called something 
like 'general.groupPolicy.enable' that is set to 'false' 

by default. However, I would request that this particular setting should 
*always* be read from the registry as well as the 

pref files. That is, you can set this setting in the registry along with a 
whole load of other ones, from a default install 

of Mozilla, and everything will work. I think most Windows admins would like 
not to have to fiddle with .js files whatsoever.

A long post, but hopefully helpful to whoever ends up implementing this.
D'oh. I hate Notepad. Sorry that all the line breaks in my previous post were 
messed up. Is there any way to edit a comment once you've posted it?
I'm going to request 1.1 blocking just to see if this bug has any traction from
the developers.

You would probably want 2 registry keys per preference.  One to set the
preference and another to set if the preference is locked.  In the current
release of Firefox, if the preference is locked the user cannot change it.  That
could add up to a ton of keys though.
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1? → blocking-aviary1.1-
(In reply to comment #12)
> You would probably want 2 registry keys per preference.  One to set the
> preference and another to set if the preference is locked.  In the current
> release of Firefox, if the preference is locked the user cannot change it.  
That
> could add up to a ton of keys though.

Right, so what you're saying is something like in the 
Software\Policies\Mozilla\FireFox key having a set of values 
like 'browser.startup.homepage' which contain the values that the administrator 
wants to set, and then maybe in Software\Policies\Mozilla\FireFox\Locked having 
a set of REG_DWORD values that are also called things 
like 'browser.startup.homepage' but that are either set to 1 or 0 depending on 
whether they are allowed to be changed or not.

Having thought about this for a bit, it sounds like a good solution to me. 
It'll be easy to create a Group Policy template .adm file to put in a 'locked' 
checkbox inside the individual policies, and it'll provide the most 
flexibility. I didn't realise Mozilla already had the lockPref functionality, 
it looks like it should be quite easy to leverage that to what we want.

Yes, it's a lot of registry keys, but I'm not sure there's any way round that, 
and hopefully most people won't need to configure them all.

Just thinking about it now, would it be better if the default was for a setting 
to act as a 'locked' setting, and that you only need to set the second registry 
key if you want to make it a preference? I think most people will want the 
LockPref functionality, and this will reduce the number of registry values that 
need to be made, and also the number of clicks in setting up the policy through 
the Group Policy editor. In that case, the subkey should be called 'Unlocked' 
instead of 'Locked' of course!
Oh yes, here is a link to another project who are trying to achieve a similar 
thing, except with something that (I think) you have to put in your logon 
script. Good enough as a stopgap, but we really need this support built in in 
the first place if FireFox is going to be widely accepted - my guess is most 
sysadmins won't fiddle with their logon scripts just to get a second browser 
working how they want it to:

http://sourceforge.net/projects/firefoxadm
(In reply to comment #14)
> Oh yes, here is a link to another project who are trying to achieve a 
similar 
> thing, except with something that (I think) you have to put in your logon 
> script. Good enough as a stopgap, but we really need this support built in 
in 
> the first place if FireFox is going to be widely accepted - my guess is most 
> sysadmins won't fiddle with their logon scripts just to get a second browser 
> working how they want it to

I'm the author of FirefoxADM, and Christopher asked me to comment on this 
bug.  A lot of this comment is based on what I'm doing with FirefoxADM...

How FirefoxADM works is that the login and startup scripts act as a converter 
of the registry entries I'm using to the relevant preference file in Firefox.  
The startup script converts per-machine settings to locked settings, the login 
script converts per-user settings to user preferences.

You just add the login script and startup script (either could be excluded if 
you aren't setting preferences or locks respectively) at the same level as the 
OU or GPO you are installing Firefox from, as well as add the ADM template.  
Any lower OU overrides of Firefox settings just requires the ADM templates and 
not the login or startup script.  I don't buy the argument that adding a login 
script, which you don't change at all, is any more difficult than adding at 
least 1 ADM template.

In terms of how you'd expect a Group Policy based settings to work, this fits 
into Firefox's existing preferences setup:  LockPrefs override all, Prefs can 
be overridden by a user.

A clearer idea can be found at:  
http://homepages.ed.ac.uk/mcs/FirefoxADM/Readme.htm

It would be good if there was a way of getting this built in to Firefox to 
read directly from the registry (from Software/Policies as already said).  
However, I have a few concerns.  Firstly, for it to work, there would have to 
be a special kind of preference created.  This would make it so that any 
setting read from registry is a held-in-RAM-only and discarded at the end of 
each Firefox session, and not rewritten to the prefs.js file.  If it wrote to 
the prefs file, it would then be "tattooed" to the profile (ie. still be set 
even if group policy is removed from Scope of Management) and thus act like an 
unmanaged group policy.  This whole process would obviously lead to a 
relatively big overhead, of over a second, where every load of Firefox is 
accompanied by a profile read.  At the moment I prefer to do it at 
login/startup as you only get the performance hit once (and, note, this is how 
IE sets a lot of its settings - they use a Client Side Extension, I use 
scripts for flexibility and extensibility reasons).

The use of registry entries you are suggesting is another concern - 2 per 
setting?  Is that in HKLM or HKCU or both?  If you just have it in one side or 
the other, you lose a great deal of flexibility from an inability to use 
security filtering properly.  If both, you very quickly get into an 
extraordinarily complicated situation -  user locks override user prefs, but 
machine locks override all?  In a large AD, that'll be a nightmare to debug.  
In FirefoxADM, I have made the call that locks are machine specific and 
preferences are user specific for this reason and because it fits into 
Firefox's existing preferences structure.

Lastly, I'd say that having ALL the preferences in the registry and letting 
individuals write the ADM templates is a bad idea as (a) you need people to 
know how to write ADMs, (b) you get back to that requirement for people to 
know how the config structure of Firefox works and (c) several settings need 
to he grouped together in order to activate certain settings in Firefox (for 
instance, if you only set the http proxy in about:config, it wont set that 
until all proxys are set).

Anyway, keep requesting this.  I don't think its a 1.1 blocker, but should be 
something for the developers to think about.  I'll keep an eye on this, as it 
gives me ideas for my project as well and if you have any questions about it, 
feel free to mail me.

Cheers,

Mark
(In reply to comment #15)
> The use of registry entries you are suggesting is another concern - 2 per 
> setting?  Is that in HKLM or HKCU or both?  If you just have it in one side 
or 
> the other, you lose a great deal of flexibility from an inability to use 
> security filtering properly.  If both, you very quickly get into an 
> extraordinarily complicated situation -  user locks override user prefs, but 
> machine locks override all?  In a large AD, that'll be a nightmare to debug.  
> In FirefoxADM, I have made the call that locks are machine specific and 
> preferences are user specific for this reason and because it fits into 
> Firefox's existing preferences structure.

This is why I think that, at least at first, we should just worry about 
creating registry-based 'locks' rather than 'preferences'. It should be easy to 
implement (the locking system is already there) and doesn't have any of the 
headaches associated with 'preferences'. The only precedence to worry about is 
that per-machine locks override per-user locks, as is usually the case with 
Group Policy. If people still want registry-based preferences, that can be done 
later, but my guess is that this will do for most situations. It's certainly 
all I need in my school situation.

I think registry-based preferences should be implemented in a slightly 
different way anyway. Group Policy does have a separate way of dealing 
with 'preferences' rather than 'policies' (locks) which I haven't got time to 
talk about now.

By the way, it *is* important that we can set these 'locks' both at the per-
machine AND the per-user level. Some settings lend themselves to per-machine 
(proxy settings) and some to per-user (security settings).

> Lastly, I'd say that having ALL the preferences in the registry and letting 
> individuals write the ADM templates is a bad idea as (a) you need people to 
> know how to write ADMs, (b) you get back to that requirement for people to 
> know how the config structure of Firefox works and (c) several settings need 
> to he grouped together in order to activate certain settings in Firefox (for 
> instance, if you only set the http proxy in about:config, it wont set that 
> until all proxys are set).

It's simply a question of convenience and upgradeability. Ideally an 'official' 
ADM will be supplied on the FireFox site which will have all of the settings 
most sysadmins need inside. So your average sysadmin will just download 
the 'official' ADM file and have all the settings they need, without knowing 
anything about the FireFox config system. Any new settings can be made 
available with a simple upgraded ADM file rather than having to delve into the 
code. Grouping settings together can be accomplished with ADM files really 
easily.
*** Bug 297819 has been marked as a duplicate of this bug. ***
Assignee: firefox → nobody
Component: General → OS Integration
QA Contact: general → os.integration
Summary: Windows 2000/XP/2003 Group Policies support → Windows 2000/XP/2003 Group Policies support (make firefox configurable with domain group policy objects)
Version: unspecified → Trunk
*** Bug 301908 has been marked as a duplicate of this bug. ***
There is plenty of scope in Deer Park's new extension developer features with 
the better registry control functionality and abilities to control installs of 
extensions to write an extension that will make all the features below 
necessary.  In fact, I have already written one, and will release it in time 
for Firefox 1.5's release.

Test release can be found:  http://homepages.ed.ac.uk/mcs/admxpi.xpi (if 
downloads as admxpi.zip, rename to admxpi.xpi)

The core functionality is:

*  reads from keys Software\Policies\Firefox.XPI and 
Software\Policies\Firefox.XPI\Locked on both HKCU and HKLM

*  enumerates through values in these keys which have same name as pref it is 
going to set in Firefox

*  values set at Firefox.XPI level are prefs, at Firefox.XPI\Locked level are 
locks

*  sets to 4 levels of granularity:  user pref, comp pref, user lock, comp 
lock - in that order (so, for example, a value set in 
HKLM\Software\Policies\Firefox.XPI will be overridden by a value set in either 
HKCU\Software\Policies\Firefox.XPI\Locked and 
HKLM\Software\Policies\Firefox.XPI\Locked)

*  So, installed extension and then template such as:

CLASS USER
CATEGORY "Mozilla Firefox XPI Settings"
KEYNAME "Software\Policies\Firefox.XPI"
POLICY "General Settings"
PART "Homepage" EDITTEXT REQUIRED
VALUENAME browser.startup.homepage
END PART
END POLICY
END CATEGORY

CLASS MACHINE
CATEGORY "Mozilla Firefox XPI Settings"
KEYNAME "Software\Policies\Firefox.XPI\Locked"
POLICY "General Settings"
PART "Homepage" EDITTEXT REQUIRED
VALUENAME browser.startup.homepage
END PART
END POLICY
END CATEGORY

etc etc etc

is all that is required.


Anything else needed?  Feel free to test the above extension (DP only!).  Any 
feedback appreciated (email:  mark.sammons at ed.ac.uk).  Hopefully the code 
can be the groundwork for a patch for Firefox itself.
Depends on: 289136
It would be convenient to have an administrative option in the Firefox extension
manager GUI to install an extension for all users instead of just the user that
is currently running Firefox.

Maybe Firefox could make use of the "All Users" profile for this purpose, which
would have its own Extensions folder, etc.  Future extensions could be written to
store some of their settings in here so that an administrator could (for
instance) mandate that NoScript is installed for all users and never allows
JavaScript globally.
No longer depends on: 289136
Some of the comments on .POL files are disturbing. .POL files have not been used since Windows 2000 came out. They are certainly valid for a Windows NT / 9x codebase deployment, however considering that all of those products are end of life / discontinued there should be very little focus in that area.

Instead focus on HKLM/HKCU \Software\Policies. This is the core of GPO/Active Directory based administration.

I agree with comments pertaining to both keys that you need settings at both levels. Generally speaking however... Firefox is a "User Application" and this lends mostly to the key settings under HKCU.

As for locked settings... I agree this should be the case, but I think something has been missed here. I don't think you need to specify it as an addidional item... aren't you by definition asking it to be locked by setting it?
Setting the key should automatically lock the key. It is my experience as an admin that if I am going out of my way to deploy a setting via ADM/GPO that I want it to be set and locked.

Something else that may be of interest to posters of this bug is that a company called frontmotion seem to have already implemented this feature in an altered build of firefox... given that, could it be possible to source the changes to the codebase from them?

http://www.frontmotion.com/Firefox/fmfirefox.htm

Login Scripts can be messy and potentially unreliable, scripted / etc XPI installations can be messy and potentially unreliable. The best way of resolving this issue is to incorporate it into the appliation itself then there will be no chance of potential script error / execution / installation.

Just my 2 cents coming from an enterprise administration viewpoint.

Regards,
Matt
(In reply to comment #21)
> As for locked settings... I agree this should be the case, but I think
> something has been missed here. I don't think you need to specify it as an
> addidional item... aren't you by definition asking it to be locked by setting
> it?
> Setting the key should automatically lock the key. It is my experience as an
> admin that if I am going out of my way to deploy a setting via ADM/GPO that I
> want it to be set and locked.

IE has a useful mode in its GPO settings that allows you to specify settings as "preferences" rather than enforced settings. That way, you can set a home page preference which will be the default, but you can still allow users to change it if they want. Other settings covered in there include proxy settings, default programs for opening files and search site choice. These can be overridden with a setting from a GPO not in preference mode.

I'd find this quite useful as a way of allowing users some control over their desktops without upgrading rights. Presumably Microsoft customers also find this useful if it made its way into their GPO settings.
(In reply to comment #21)
> 
> Something else that may be of interest to posters of this bug is that a company
> called frontmotion seem to have already implemented this feature in an altered
> build of firefox... given that, could it be possible to source the changes to
> the codebase from them?

Frontmotion has also been mentioned as a possible solution to bug #231062 (Firefox MSI package).  The lack of an MSI package is also a corporate issue.
I'm actively working on this right now.

I'm not sure if I want to integrate it into the CCK or not.

Step one is to define exactly what we are going to allow to be customized.

Can we hash out what preferences people need/want controllable from the policy?
Here are a few ideas:

User Policies:
* Home Page
* Disable installing extensions
* Specific User Interface Theme
* Disable installing themes
* Disable javascript
* Disable java
* Disable tabbed browsing
* Disable automatic update checking
* Change default download folder
* Hide download manager
* Disable popup blocker
* Manage popup blocker whitelist
* Disable "remember passwords" option
* Disable "saved information entered into webforms" feature
* Clear private data when closing firefox

Computer Policies:
* Disable installing extensions
* Disable installing themes
* Disable javascript
* Disable java
* Clear private data when closing firefox
* Connection settings (proxies, etc)

Any thoughts on how it will be implemented? Is the policy system going to be a separate system, or will it tie into the existing settings system, perhaps adding locked "session" settings. That way the ADM templates could be easily extended in the future - just map the registry values to match the firefox settings.
Any reason that making all of the preferences available for control in this way would be harder than making just some of them available?

Also would be nice to be able to determine what is done with updates (when they are installed, etc.) and which extensions and search engines are installed by default.
My plan is to map things exactly to Firefox preferences where I can.

There will be a admService.js files that reads the reg values and sets the necessary prefs/values.

Some of these things are prefs, some aren't.
mkaply, for long-term use I think it would be more productive for the prefservice to just read group policy as default prefs and pref-locking instructions from the appropriate registry hives, rather than hackery with a separate service and userprefs, which is fragile.
(In reply to comment #28)
> mkaply, for long-term use I think it would be more productive for the
> prefservice to just read group policy as default prefs and pref-locking
> instructions from the appropriate registry hives, rather than hackery with a
> separate service and userprefs, which is fragile.
> 

But then we would be putting enterprise features directly into Firefox :)

That's fine. Then we need to come up with the correct way to do this so it works in any app (including XUL runner apps)

locked prefs are a kind of interesting problem. If we are going to describe the pref in the registry as foo with a value of bar, how do we put something in there that says which pref is locked? In previous implementation, people went with a subtree in the registry called "Locked"

I was looking at doing something like foo.locked = 1/0 to indicate that foo was locked.

What do people think of that?
Well, if a company is using a group policy, access to the registry should be locked from the beginning. At that point, couldn't you just use a reg DWORD like prefs.locked set equal to 1 to tell Fx to not allow registry-based prefs to be altered?
(In reply to comment #30)
> Well, if a company is using a group policy, access to the registry should be
> locked from the beginning. At that point, couldn't you just use a reg DWORD
> like prefs.locked set equal to 1 to tell Fx to not allow registry-based prefs
> to be altered?
> 

They might be using a group policy to set the initial values of the prefs, but still allow users to change them (like home page for instance)

Firefox supports the locking of individual preferences, and we need some way to convey that in the registry entry for those prefs.
mkaply,

What you are describing is similar functionality to the Group Policy extension I wrote (more as a proof of concept).

The way I did it was to work with the concept of values set in the registry which match preference names, in one of 4 registry locations - HKEY_CURRENT_USER\Policies\ADM\Firefox, HKEY_LOCAL_MACHINE\Policies\ADM\Firefox HKEY_CURRENT_USER\Policies\ADM\Firefox\Locked & HKEY_LOCAL_MACHINE\Policies\ADM\Firefox\Locked.  These represent set per-user, set per-machine, set and lock per-user and set and lock per-machine.  And they override in that order.  So, for instance, a user with visual difficulties could have their homepage locked to a high contrast page which overrides a policy which sets a homepage on a per-computer basis, but a computer with a very specialist purpose could be set and locked on a per-machine basis to a relevant homepage.

As a patch the way I envision this working is it reads from the registry and sets accordingly and then loads the preferences from the normal prefs.js after that.  This would mean that locked values from the registry would be locked but if a user has their own value stored in the prefs.js, it would override any set (but not locked) values it got from the registry.  I've wanted to look to doing this as a patch, but cannot figure out where the relevant processing lies.

In terms of the group policy processing, Firefox has everything you need.  As you know, since Firefox 1.5 you can enumerate registry keys, read in each preference there, and set and/or lock accordingly using the already defined APIs in Firefox.  Firefox will not allow you to set illegal values, or illegal preferences.  The functionality would be entirely extensible (while Firefox uses the existing preferences system).

As I said, I did an extension for this (which I release as public domain) and you can find this code and example template here:  http://homepages.ed.ac.uk/mcs/GPOforFirefox.zip

Hope that helps.
Thanks Mark. I'm aware of your work and it is great stuff.

I'd like to figure out how we can bring together the three separate ADM Firefox projects we have no into one. That's really what this is about.

Incidentally, we need to make sure everyone knows this isn't just about preferences - things like the XPI and popup whitelists are not set via preferences.

So this is really a more far reaching discussion than that.

Right now I'm looking at the Internet Explorer ADM to see how much of that we want to emulate.
i'd consider adding an option to use the IE Group Policy settings for Firefox (where possible).
That way i'd have to set Proxy, Homepage,... only once and dont have to maintain the settings twice.
(In reply to comment #34)
> i'd consider adding an option to use the IE Group Policy settings for Firefox
> (where possible).
> That way i'd have to set Proxy, Homepage,... only once and dont have to
> maintain the settings twice.
> 

Does anyone know where these are? I looked through all the group policy stuff and couldn't figure out where to set the IE proxy and homepage. I saw lots of other IE stuff for configuring settings, but not these two.
i'Ve just set an IE Setting and something appeard in
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{038D5F2C-0C14-42BE-8050-E52C739F7384}Machine\Software\Policies\Microsoft\Internet Explorer\Restrictions

(very easy to find ;)
(In reply to comment #35)
> Does anyone know where these are? I looked through all the group policy stuff
> and couldn't figure out where to set the IE proxy and homepage. I saw lots of
> other IE stuff for configuring settings, but not these two.

There are two areas in the Group Policy editor for setting Internet Explorer.  As you say, the majority are in the group policy but the bits that set branding, homepage and proxy are in the Internet Explorer Maintenance bit.  The problem is, that isn't like a typical part of Group Policy - its called a Client Side Extension.  Effectively, its a seperate module to the group policy.

It puts all values you set in there here:

C:\Documents and Settings\<username>\Application Data\Microsoft\Internet Explorer\Custom Settings\Custom0\install.ins   (its a text file inside)


This is the rather confusing MSDN page which describes it all in muddy detail:

http://technet2.microsoft.com/WindowsServer/en/Library/2904be16-6bc3-4dfa-b884-dd4b6c6b99941033.mspx?mfr=true

(In reply to comment #35)
> (In reply to comment #34)
> > i'd consider adding an option to use the IE Group Policy settings for Firefox
> > (where possible).
> > That way i'd have to set Proxy, Homepage,... only once and dont have to
> > maintain the settings twice.
> > 
> 
> Does anyone know where these are? I looked through all the group policy stuff
> and couldn't figure out where to set the IE proxy and homepage. I saw lots of
> other IE stuff for configuring settings, but not these two.
> 

Group Policy -> User Configuration -> Windows Settings -> Internet Explorer Maintenance

It seems to be implemented as a plugin, rather than an ADM. I think the IE settigns are split into two areas. The IE Maintenance area is probably what used to be called the ZAK (zero administration kit)

> They might be using a group policy to set the initial 
> values of the prefs, but still allow users to change 
> them (like home page for instance)

> Firefox supports the locking of individual preferences, 
> and we need some way to convey that in the registry entry 
> for those prefs.

I might be wrong on this, but the Firefox locking is set through functions - ie' lockPref. The preference stays locked until it is unlocked.

Windows policies shouldn't override user settings "underneath" - when the policy is removed, Firefox should revert to it's original settings. Also, couldn't the setting theoretically be modified if the user unlocked it after firefox was loaded?

One option might be to add a new preference "mode" - policy locked. There would be no corresponding "unlock", and the policy lock function would take a value. It would set the underlying setting, then permanently lock it until firefox was closed.

"Policy locked" settings would *never* be written to disk - once firefox is reloaded, it loads the original settings off of disk, reads the windows policy and applies them, then locks those settings again for the current session. 

Non-persistent "process" preference locking, in effect. It also gets around the problem of having to have a "IsLocked" for different preferences - you just need to check the status of the preference in that case ie/ Pref_IsLocked("blah")

At startup, firefox could enumerate values in certain registry keys (policies from HKCU and HKLM) and for each value, parse and set the temporary non-persistent lock. I might be wrong, but from what I understand Firefox has only user preferences - no shared "system" ones. It still would make sense to have policies in HKLM though - I could see a sysadmin wanting to apply something like proxy settings to groups of computers rather than groups of users using group policy.

Firefox could enumerate two policy keys, one in HKLM and one in HKCU. The trick will be deciding which one takes precidence - do computer settings override user settings, or vice-versa? Probably would be a good idea to carefully look into best practices in regards to that.

Good point about some things not being Firefox preferences, such as XPI/popup whitelists. I suppose for those cases the special values would just be hard-coded into the policy loader? 

Also, if I remember correctly ADM files can be configured to write to different base keys. If you want a "locked" policy you generally configure the ADM to use a key under Software\Policies.

An interesting implementation would be to create TWO ADM files for firefox - one for policies, and another that points to a user-modifyable registry key such as Software\Firefox\DefaultPrefs. The other ADM file would be used for settings the defaults that users could modify. The defaults would only be applied if the user has no preference set for that specific value, and would be persisted to disk.

Thoughts?
Speaking as a sysadmin with quite a bit of experience in Group Policy, what Mark has in comment #32 seems like the best thing to me. He's also got the order right in terms of application: you want per-machine to override per-user (this is generally 'expected behaviour' in Group Policy - it's the way the IE6 XPSP2 zone settings work for one thing).

The trouble with comment #38 is that if you don't put the settings in the 'Policies' key they are 'tattooed' onto the system: when you un-set the policy the settings remain. I don't know of many apps that still use this 'preference' mode of Group Policy - in fact, by default such settings are hidden inside the Microsoft UI, which means some people will have trouble finding them! I think an 'unlocked' and 'locked' key would be a better solution.
(In reply to comment #39)
> Speaking as a sysadmin with quite a bit of experience in Group Policy, what
> Mark has in comment #32 seems like the best thing to me. He's also got the
> order right in terms of application: you want per-machine to override per-user
> (this is generally 'expected behaviour' in Group Policy - it's the way the IE6
> XPSP2 zone settings work for one thing).

I must confess I'm totally confused on this. This seems backwards to me.

A user policy should override a computer policy.

In a company, I might have a policy that all computers have Java disabled. But then a group who has a specific need for Java would have a user policy that overrides the group policy that says "no Java"

shouldn't user policies override computer policies? Since any user can be on the computer in theory?
(In reply to comment #40)
>
> shouldn't user policies override computer policies? Since any user can be on
> the computer in theory?

My background is in the antivirus industry, and where I work it is absolutely clear that computer policy overrides user policy.

For example, if the computer policy says that realtime scanning (RTS) must be on then a user policy that says that the user can stop the RTS is ignored.  The rationale is that the user's action to stop RTS could impact the entire computer and then subsequently other users on that computer.
Computer Policy should definately override User Policy.
If you are applying a base secure policy to a large number of desktops, you do not want a user policy to override that setting because of a simple mistake in GPO inheritance.
Is there any active work being done on this currently? perhaps we should put together a working group?
mkaply, I think you're thinking of having User Foo in Group Bar, which overrides the defaults from Group Baz, unless you use something like No Override to block anything overriding Group Baz.  Its a combination of multiple groups, instead of per-user bits.  I think that we should leave how group/user policy interact to Microsoft and just work the way Microsoft defines it.

I don't know what a working group would accomplish, its pretty clear that what this needs is patches, not discussion.
First Cut FirefoxADM File with many settings requested within this bug. Looking at the best way to integrate these registry settings to reflect in firefox configuration as I write this.

Comments/Suggestions more than welcome.
this js file has been altered to work with the GPO File I have uploaded earlier. I don't have any skills in Java / Javascript and there is a bug in it that renders the true/false component broken. Anyone is welcome to try and alter.

I make no claims on this code. It is not mine. Full credit goes to the developers at http://sourceforge.net/projects/firefoxadm/

Hopefully with some minor tweaking with this script and an easy integration using an MSI Transform can easily add this to an existing Firefox MSI Project.

Regards,
Hewfish
So should the computer settings from the policy be automatic locked preferences? Should we allow user settings to be locked at all?

I originally pictured that in the ADM, a given setting would have a "Locked" checkbox which set another item in the registry we would read to see if the preference was locked, but it sounds like that might not be necessary...

As far as code goes, I am working on an adm service right now to test some of this out and then we can look at integrating it into the code.
There should be two different settings for registry-based policy: there are group "preferences" and group "policy". Preferences indicate a default that can be changed by the user, and policy indicates an administrator setting which cannot be changed by the user (which maps pretty closely to our locked-pref model).

So, the order of reading GP should be:

System Group Preferences
User Group Preferences
User Group Policy (locks pref)
System Group Policy (locks pref)
OK in my reading of the comments that have followed my posting, I should have 2 sub sections under Mozilla/Firefox

/Preferences/(settings)
/Policies/(settings)

Does this follow the line of thinking? if so the ADM file can be easliy changed to refelect these needs. the JavaScript may be a little harder.

Cheers,
Hewfish
a simpler alternative I guess would just be to have an "enforced" option within the GPO i.e. Mozilla/Firefox/Enforce Settings (true/false)

Cheers,
Hewfish
I have added an option for Policy Enforcement i.e. Lock vs Unlock within Firefox.

Cheers,
Hewfish
forgot to mention that I did not update the Javascript to reflect the ADM file change as I do not know enough about the Javascript API for firefox.

Cheers,
Hewfish
looking closer at the Javascript Code. It may only be a matter of changing the value from a string true/false within the ADM to a 0/1 for True vs False for accurate reflection of changes within Firefox. This will not address the Locked issue within the script, however I may be able to write some code to do that task.

I'll keep this Bug Posted. :)

Regards,
Hewfish
(In reply to comment #49)
> OK in my reading of the comments that have followed my posting, I should have 2
> sub sections under Mozilla/Firefox
> /Preferences/(settings)
> /Policies/(settings)
> Does this follow the line of thinking? if so the ADM file can be easliy changed
> to refelect these needs. the JavaScript may be a little harder.

Hewfish,  Read comment #32.  The script you attached was from that extension I wrote.  The script already does what you mentioned above!

To be honest, I don't think its worthwhile creating elaborate ADM templates at the moment, especially as we will need ADMX templates as well (for Vista).  mkaply's approach of writing this as a service is the right way to go.

There is probably merit in a special value in the preferences called enforced.  However, what I would envision this to be is a special value which makes sure that if a pref is locked by group policy, it cannot be changed by other sources.  The obvious "attack vector" here is people who wish to change locked values such as a proxy and do it via an extension (although I haven't tried to write an extension like this to see what's possible/not possible).

Some other important points:

If a user has a preference in their prefs.js that is then locked by policy, the user's original preference value should be written to the prefs.js when Firefox is closed.  

Secondly, it should recognise environment variables like %USERNAME% and %HOMESHARE%%HOMEPATH%.

Thirdly, it should be extensible to other non-preference values such as pop-up whitelists.

Although my extension does it the "right" way by group policy way of user pref, comp pref, user lock, comp lock, I have to agree with bsmedberg about user prefs override computer prefs.
Thanks for your comments, my only concern is that a fully fledged service is overkill and not likely to make it into the firefox build.

The js solution ( thanks by the way :) ) is a simpler method of setting the preferences (although it does have some drawbacks and or issues)

Without a well defined ADM template, how do you propose that the appropriate coding can take place? I don't wish to start a flame war, I just don't see a reason to be negative about creating a well defined template that uses the existing firefox preference names for values.

The extension change issue would only be relevant if xpi installs are permitted and if the user has an xpi already loaded that has that functionality. Existing group policy techniques with IE currently have the same flaw even if you lock the setting, you can change it within the registry manually, although this does get overwritten within 15mins or within your defined group policy refresh window.
 
At this stage I will continue to work a non service approach because I believe that it is a "cleaner" more likely to be accepted scenario.

Vista stil has not hit "Gold" so I think reaching to far at this stage is a little ahead, and not within the scope of "here and now" although no less important.

Once again, thanks for your comments.
The reason I want to do a service approach to start is so we can verify the behavior before putting it into the build.

A have a few more questions for people.

Shouldn't the computer policy by it's very nature be locked?

Are group policied used to set default values that can be overridden? Or are they intended to set the only values.

In otherwords, shouldn't these all be locked prefs anyway?
I've been tracking this bug for a long time, and its good to see it getting some traction.  Has anyone investigated the system pref service or gconfig service, and if a similar implementation can be used here?  The source is located at: 

http://lxr.mozilla.org/mozilla/source/extensions/pref/system-pref/src/
and
the http://lxr.mozilla.org/mozilla/source/toolkit/components/gnome/
(In reply to comment #56)
> In otherwords, shouldn't these all be locked prefs anyway?

Not necessarily.

The example I would think of is where a policy wants to set up initial settings for a user.  For example, say you wanted to set the download folder location.  By default, you might want to redirect that to a user's network store.  However, the user might then decided they want to store all their downloads in a folder called Downloads within that network store.  It wouldn't be something you'd want to necessarily lock to a certain preference.  There should be that sort of flexibility.

You could of course argue that you only need one of per-user or per-computer preference setting in this case.  However, through FirefoxADM, I dealt with a lot of companies and you'd be really surprised at the level of complexity and granularity they put into their policies.  Best just to try and give them as much flexibility as possible, than ponder the ways and means of some system setups!  I still think the 4 possibilities of per-user set, per-computer set, per user lock and per computer lock would cover every feasible configuration.

I can't say that I have looked at either <a href="#c58">comment #58</a> But I just want to at least get a working solution in place that can be improved by anyone. Considering that no one else sems to be actively working inside this bug... there are plenty of great projects outside of this bug that seem to approach this issue from different angles.

Given that, I'll keep submitting until I am happy that I have created a solution that I am happy with. If people want to improve on it from there or have requests that I can fulfill then I will.

Locked vs Unlocked. Well I'll let the people implementing the policy decide which way they want to implement their policies, so at this stage I will work on both being in the solution I submit.

Regards,
Hewfish
Mike, "Group Policy" is actually policy+preferences, at least as IE implements it. I can send you a bunch of links if you're interested.
hi,
i'm involved in working on a solution in bug 337679 together with michael; the js is based on mark's admxpi, just a bit streamlined and prepared to be incorporated into michael's client customization kit (cck), which is (from my understanding) aimed at the very people that will use group policies as well.

i just read through this whole bug, my head still humming, so i'd like to sumarize the main points:

- where to store gp data: HK[CU|LM]\Software\Policies\Mozilla\Firefox seems to be the correct place to store locked preferences ("policies") according to common gpo policy. if i read comment #49 correctly, there ought to be a HK[CU|LM]\Software\Preferences\Mozilla\Firefox as well -- will this prevent tattooing of the registry as \Software\Policies does?
   christopher, you mentioned that there is a definite "gpo way" of handling preferences in #16 -- could you elaborate on that a bit more?
   i currently use the HK..\Software\Policies\Firefox.XPI[\Locked] in production systems, but the development version already uses Policies\Mozilla\Firefox[\Locked].

- apropos tattooing: afaik, all current implementations leave their marks in the firefox settings (typical example: i kick cck from my machine as admin to enable xpi installation on my account, but still have to change the setting in about:config back to enabled). from my understanding of firefox, there some kind of layer system in the preferences. if we could use that to put the preferences (non-locked) "below" the user prefs and the policy "above" (and lock it), the problem would be solved. can this work out?

- everything but the about:config-prefs will definitely require specific code for all (groups of) settings that should be changed; one of the groups (and i think the most important) is hostperm.1, containing black/whitelists for popups, cookies and xpi installation (and possibly more). adding the "magic" code would solve the most urgent problems.
   i'm not too sure, but i haven't seen any way of locking hostperm.1 settings the way i can lock preferences, thus the only meaningful configuration for hostperm.1 is "make sure /this/ line is included at startup". other groups of settings will probably require different strategies.

- how preferences are applied: a service is mentioned -- could someone plz briefly explain to me what this means?

- locked vs unlocked, HKLC vs HKCM: i second mark's comment #58 that every combination is necessary. custom adm templates can hide the "abundant" functionality from admins who have a clear picture of what is a computer and what is a user preference, what should be locked and what not.

just my 2 kB ;-)
(In reply to comment #61)
> if i read comment #49 correctly, there ought to be a
> HK[CU|LM]\Software\Preferences\Mozilla\Firefox as well -- will this prevent
> tattooing of the registry as \Software\Policies does?

No. If you put *anything* outside the Policies key it will be tattooed. There is nothing special about any registry key called Software\Preferences: in fact, I know of no application that uses such a key.

>    christopher, you mentioned that there is a definite "gpo way" of handling
> preferences in #16 -- could you elaborate on that a bit more?

All I was referring to is the fact that if you put things outside the Policies registry key they are referred to (by Microsoft) as 'preferences' - because the user is able to change them, unlike the contents of the Policies key. The Policies key is protected by a more restrictive ACL which means that by default it can only be modified by Group Policy or an administrator. It is also cleared out and regenerated on each Group Policy refresh, in order to prevent tattooing.

>    i currently use the HK..\Software\Policies\Firefox.XPI[\Locked] in
> production systems, but the development version already uses
> Policies\Mozilla\Firefox[\Locked].

I think this (the second option) is the best way, personally. One section for 'unlocked' preferences the user can change, and one for 'locked' policies  that they can't. Don't put anything outside the Policies registry key; people will not be expecting anything to be tattooed, and besides the ability to write outside the Policies key goes back to the days of 9x/NT4; none of Microsoft's 'flagship' products (Windows, IE, Office) use this capability of Group Policy any more so far as I am aware.
(In reply to comment #61)
> hi,
> i'm involved in working on a solution in bug 337679 together with michael; the
> js is based on mark's admxpi, just a bit streamlined and prepared to be

Glad you found a use of the code and, yeah, it would have needed "streamlining".  I don't write the tightest code there is!

> be the correct place to store locked preferences ("policies") according to
> common gpo policy. if i read comment #49 correctly, there ought to be a
> HK[CU|LM]\Software\Preferences\Mozilla\Firefox as well -- will this prevent
> tattooing of the registry as \Software\Policies does?

As Christopher says, only ever use /Software/Policies.

>    i currently use the HK..\Software\Policies\Firefox.XPI[\Locked] in
> production systems, but the development version already uses
> Policies\Mozilla\Firefox[\Locked].

The Firefox.XPI is my fault, and was never meant to be in there in a released version.  I only used that key when I was developing it to remind myself this is the key for values for admxpi, as opposed to the other key which I use for FirefoxADM.  I too think it should be as you have in the development version.

> about:config back to enabled). from my understanding of firefox, there some
> kind of layer system in the preferences. if we could use that to put the
> preferences (non-locked) "below" the user prefs and the policy "above" (and
> lock it), the problem would be solved. can this work out?

This is what I was getting at in comment #32, paragraph 3.  As I see it, the ideal way it would work would be:

On Firefox load, apply default prefs, apply prefs from registry, apply users prefs in that order.  That would get the right combination of prefs.  The tricky part is how to unapply the prefs on Firefox close so no group policy settings get pushed to the prefs.js.  

One possibility would be, when applying user prefs, if a value in the user's prefs.js file is already locked, you store it in an array.  Then on Firefox close, you reset to default all locked values, reset to default all preferences where the user hasn't changed them from the grou policy set values, apply the array of stored user prefs and then close firefox.  That would write out the correct prefs.js (I think).  Although there are about a dozen different strategies you could use here.  However, that was kind of direction I had hoped for, for admxpi.  Unfortunately, haven't had enough time to get my head round the Observer Service, which would be necessary to fire things off on Firefox close.

>    i'm not too sure, but i haven't seen any way of locking hostperm.1 settings
> the way i can lock preferences, thus the only meaningful configuration for
> hostperm.1 is "make sure /this/ line is included at startup". other groups of
> settings will probably require different strategies.

This is basically what I did with FirefoxADM - just make sure the hostperm.1 file was overwritten every time.  The only other solution I can think of is, is there a way to disable parts of the interface?
Feature request: block user access to about:config

Right now, I use the following in userContent.css to hide about:config's contents; of course a GP would be preferrable:

        #configTree {
             display: none !important;
        }

I'm glad to see work getting done on this issue; thanks.
(In reply to comment #64)
> Feature request: block user access to about:config

FYI, The CCK does that - http://www.mozilla.org/projects/cck/firefox
This feature and the fact that the installer is not a msi file is stopping firefox from being easily installed and maintaint in big MS windows using corporations. PLz fix this ...

I think the New Year is a good time to reflect on this one and try and find a way forward.

The problem, as I see it, is that currently there are several almost-competing projects trying to fix this issue and very few are really looking at providing a native solution.  For instance, there are my FirefoxADM and Firefox Group Policy Extension projects, Frontmotion's efforts, Sandusky's Firefox Corporate Project, Wetdog and Mike Kaply's CCK project and I wonder instead of these producing seperate solutions, if we could find a common ground.

The reason I stopped actively developing FirefoxADM and started work on the Firefox Group Policy extension is that I hoped that the extension, using native APIs, could be developed into a patch.  Unfortunately, I am stumped as to which component, which part of Firefox and what nature this patch should take, and I would love some input from the developers on this.  All I know to date is that copying the code from my extension to the end of the nsBrowserContentHandler.js works, but I don't really consider that a submittable patch.

This really needs to be looked at sooner rather than later to be considered for Firefox 3...
My suggestion for adding this is to add Windows Registry read support to libpref, so that when we "compile" all the prefs.js, user.js, all.js, etc. together, we also pull from the Registry, specifically the Group Policy Objects tree.

We still need a way to denote a preference as locked or unlocked/preset.  One thought would be to have parallel trees inside ...\Software\Policies\Mozilla\Firefox\ like ...\lockedPrefs\general.useragent.extra.firefox and ...\unlockedPrefs\browser.startup.homepage

That may make the ADM more difficult to create, since the KEY would need to change based on if the "Lock this pref" checkbox was checked or not.

Thoughts?
lilmatt: that sounds reasonable, though I would use the following names:

S\Policies\Mozilla\Firefox\defaults (defaults, not locked)
S\Policies\Mozilla\Firefox\policies (locked)

As for the ADM, I think we should just have duplicate panels: one for policies, and one for preferences. Though we should see what the IE ADM panel looks like.

If you (or anyone) is interested in implementing this, I'd like to talk to you about an extensible pref provider that would make this a lot easier.
Attached image IE ADM section
(In reply to comment #69)
> As for the ADM, I think we should just have duplicate panels: one for policies
> and one for preferences. Though we should see what the IE ADM panel looks
> like.
IE has two different parts: The "Maintenance" section, where you set things like UA strings, browser title bars, and your corporate Favorites list, and the actual Administrative Templates bit (the ADM) where you're fine tuning things, turning off ActiveX for domains that end in .bad and the like.

I've attached screenshots highlighting the two sections.  You can also see my experimental Fx ADM in the tree in the first shot.

> If you (or anyone) is interested in implementing this, I'd like to talk to you
> about an extensible pref provider that would make this a lot easier.

I am interested in implementing this.  I was chatting with mconnor quite a bit about this, noting how there appears to be no less than 4 differing ways to customize your Fx install. (autoconfig.jsc, the all.js/foo.cfg ROT13 thing, prefs from LDAP, CCK, MCD, need I go on?)

Given my previous lives in quasi-corporate IT, my experiences deploying and maintaining Fx using mkaply's CCK, and previous to that, the .cfg/ROT13 method, I'd like to bring some focus to this effort so IT folks can at least see some progress and possible contributors, users, and testers can give us feedback.

Things like autoconfig.jsc predate Group Policy by a longshot, and look to have been around when LDAP was just a baby.  As a result it has implemented many of the things that Group Policy had to implement itself (dealing with being offline, caching the settings, etc.).  Maybe we can rework some of that so instead of hitting http://server/autoconfig.jsc, we alternatively hit the GPOs in the Windows Registry, and reuse the caching/offline code?  Perhaps?  Just thoughts at 1:45am.

The salient point here is that if we find that some of our existing solutions are not up to what administrators of computer labs or large-scale deployments are looking for, perhaps those should be phased out as we create a more modern, and hopefully more robust solution.

That said, I don't want to tear out things that are well-tested and work well for us.  In my discussions with mconnor I noted how one of the benefits of our current prefs.js system is how you can carry your Fx profile to multiple machines using a USB-key and Portable Firefox.  If we stored all our prefs in the Windows Registry instead, that sort of thing could easily become a nightmare to replicate.  

I also don't want to end up with Active Directory + Group Policy as the _only_ way to manage Fx on a bunch of Windows machines.  We're all about choice and openness.

My preference would be an architecture where we write a bridge between the prefservice and your management system, and document how to do so.  Then we can make a AD/GP connector, an Apple Open Directory connector, a gconf connector, etc.  If Novell wants a ZenWorks connector, great.  They can write one.  And if folks make a nice little solution for mom n' pop shops with 5 Windows boxes and no need for AD/GP, that's good too.

So in closing, my goal is to figure out how to make our own .js file preferences system, which has served us well up to this point, mesh with the disparate systems implemented by the various vendors.  If in doing so we can simply the codebase and also clarify what the suggested-by-Mozilla path for customization and continued maintenance is, then I'll call it a success.
Assignee: nobody → lilmatt
Since there doesn't seem to have been any communication from the assignee for over a year, I am guessing that he is no longer working on it. With big help of Michael Kaply (mkaply), we went into a different approach with this bug.

Instead of doing our own ADM template, we decided to do an implementation using generic IE policies (gpedit.msc) that both browsers can share. For example, setting the home page and enforcing full screen, and even disabling tabs! This won't be the best solution, because Firefox and IE are different in many ways. But it gives us something to start with, as IE is already in the corporate world, we might as well try imitating some of their success ;)

We haven't implemented every policy (only slightly over a dozen). And it definitely needs some polish to the functionality and the code. There are some ways to get around certain policies (we don't do any preference locking), but it is certainly better than not moving forward.

The code was designed to go into the mozilla\extensions directory. It works with the latest version of Firefox3 (Firefox3.0b5pre), but not Firefox 2 (started using fuel). You can check out the source code via svn: 
svn://cdot.senecac.on.ca/ff-ad/trunk

I am also making available an extension you can use. I haven't done much testing with it, other than it installs and works with no tab browsing and enforce full screen:
http://matrix.senecac.on.ca/~cdolivei/files/grouppolicy.xpi

I also made a list of policies that we implement. Please feel free to look and give feedback.
http://spreadsheets.google.com/pub?key=pqlMBxIY5x3i2yeezToYGfg

So now I am requesting community feedback. What is going to stop this from one day getting into the tree (I assume everyone on the CC list wants something like this in)? Other than using IE's policies, of course ;)

I think I got everything. If something is not working, feel free to email me.
There is a long list of comments to read thru for this request, so I may have missed what I was looking for:  In businesses and schools I'd love to be able to set a default computer(or user) policy that disables file downloads.  IE has such a feature, and is somewhat flexible in that you can specify to disable file downloads in the Internet "zone", yet allow downloads in the Intranet zone.  Many of my clients do not want their users to download ANYTHING, especially schools.  Of course it would be nice to be able to have a more granular policy than IE - by adding acceptable or forbidden file extensions...  This feature alone would greatly improve security for any business or school!
saying what they can download and what not is something you could do with a proxy server.
(In reply to comment #73)
> Instead of doing our own ADM template, we decided to do an implementation using
> generic IE policies (gpedit.msc) that both browsers can share. 

It sounds like a great idea in principle, but I think it could lead to undesirable behavior. For example, an organization might have Firefox and IE deployed on all of their machines, but have IE policies set up. If this change were added to the Firefox trunk, an upgrade to a newer version of Firefox would cause a "breaking change" - behavior the administrator did not intend would be applied to the browser. Maybe they intentionally want IE to have different settings from Firefox.

The existing ADM templates were specifically designed for IE in mind, not generic browser policies - it might just be more trouble than it's worth compared to a clean house "Mozilla-only" solution. 

There's a lot of great discussion here about various implementations. One common theme is the desire for a mechanism to set "default preferences" similar to how IE works in regards to group policy. It also seems as though that at it's core, Firefox doesn't have the internal mechanisms to support this model - ie/ different levels of "default" preferences, etc.

What if we initially focused on delivering a solid "policy" system for Firefox. It would be considerably easier to implement in the near future. Once the policy system is stabilized, we could look into the mechanism for specifying default preferences using policy.

* Modify Firefox's prefs loading system so that after the JS files are processed, it enumerates and reads the HKCU/HKLM firefox policies from the registry. The registry keys and values are named after the existing Firefox policy name/value pairs and stored as REG_SZ.
* Add some sort of in-memory flag for each preference that prevents it from being saved to prefs.js.
* Use the existing "lockPref" system (likely via internal code instead of JS) to prevent the setting from being modified and provide the proper UI (ie/ grayed out text boxes and buttons in the settings dialog).
* Don't worry about ADM / ADMX templates yet - once the "loader" is complete, the ADM / ADMX is relatively easy. 

Thoughts? 
(In reply to comment #73)
> Since there doesn't seem to have been any communication from the assignee for
> over a year, I am guessing that he is no longer working on it. With big help of
> Michael Kaply (mkaply), we went into a different approach with this bug.
> 
> Instead of doing our own ADM template, we decided to do an implementation using
> generic IE policies (gpedit.msc) that both browsers can share. For example,
> setting the home page and enforcing full screen, and even disabling tabs! This
> won't be the best solution, because Firefox and IE are different in many ways.
> But it gives us something to start with, as IE is already in the corporate
> world, we might as well try imitating some of their success ;)

For that matter, can it just do something like when you first set up a profile and "import IE settings" right from the get-go. That way, Firefox can piggyback on everything else done for IE. It would sure be a lot easier to implement/deploy ONE setting than many. Just thinking out loud here.
Flags: blocking-firefox3.6?
I think we should that to the policy editors. For Firefox the override mechanism would be enough and I really think comment78 sums up quite nicely what needs to be done for that. The resulting system would be very clean, very easy to understand and it would satisfy all basic requirements.
Has support for Group Policy support been added yet?  I would have thought after a few years it would have been a natural progression to add such a feature - so FireFox can be more readily configured in organizations with AD...  Or is this request stuck in limbo?
Currently it seems to be stuck in limbo and we really, really need this. Actually, we needed it some time ago, but we still do.

My University wants to deploy Firefox, but they can't because of this.

Allowing overrides for settings is not all that's needed (centralized updates and remote administration for bookmarks and so on are needed as well), but this and MSI support ( https://bugzilla.mozilla.org/show_bug.cgi?id=231062 ) are definately the most pressing issues.
This would be addressed after bug 231062 has been fixed. Keep in mind that we will also need updates working as part of bug 231062 before this bug is addressed. Also note that bug 231062 has been given priority for Firefox.next
WOW!  I can't reason why Mozilla released a new version 3.5, yet still has not addressed configuring their software at the corporate/institutional level.  I am going to probably switch all my clients back to IE, as we need truly AD configurable software.  What a bummer :(  I guess somebody just doesn't "get it"...
or have time / resources available to do it
Not the nicest way to say it, but the point is valid. But it's good to see it's scheduled for .next.

I'm willing to help to the best of my abilities with the MSIs, but I'm afraid I'm not familiar enough with Firefox' internals for this.
I did not mean to offend all the hard-working FF developers.  It's just frustrating that such a mature product is missing such a vital component.  I can only imagine how many more businesses would use FF if AD was officially supported by Mozilla...
No offense was taken.
regarding #78:

"Modify Firefox's prefs loading system so that after the JS files are
processed, it enumerates and reads the HKCU/HKLM firefox policies from the
registry. The registry keys and values are named after the existing Firefox
policy name/value pairs and stored as REG_SZ"

It's important that these settings in Registry should be under HKLM/Software/Policies, as this is where Group Policy puts them. In fact, the term "preferences" is being used in group policy, these are settings specified in the policy but NOT under /Policies branch; and this is exactly what we DON'T need.

"* Use the existing "lockPref" system (likely via internal code instead of JS)
to prevent the setting from being modified and provide the proper UI (ie/
grayed out text boxes and buttons in the settings dialog)."

No need, this is something Windows takes care of. If the user opens Regedit and changes a value, Windows will immediately restore it from the group policy. What's needed is that Firefox re-reads the policy settings from the Registry every time (every request), so it always uses those restored values.
"provide the proper UI (ie/grayed out text boxes and buttons in the settings dialog)."

yes, this is what needs to be.
Flags: blocking-firefox3.6? → blocking-firefox3.6-
So, whats the status of this most important and glaring missing feature?

Question: Does this bug also apply to Thunderbird? Meaning, when this is implemented, will Thunderbird be able to take advantage of GPOs as well?

Also - is work actually in progress? Is this planned to be implemented sometime in the reasonably near future (year? two?)?

The lack of GPO support is what prevents any company (Windows network) with more than 50-100 PCs (this includes 3 of my clients) from rolling out Firefox and Thunderbird. Now that TB3 is finally out and getting better with every release, there is even more interest from 2 of my large clients in switching to Thunderbird+Lightning - they don't use most of Exchange's fancy features, and are still on 2000, so realize they need to upgrade sometime in the next year or two - or better, lose Exchange altogether (yes, they are prepared for the user pain), so TB+Lightning would be an option for them if it had GPO support.
(In reply to comment #92)
> So, whats the status of this most important and glaring missing feature?
It has a status of New and hence is not fixed.

> Question: Does this bug also apply to Thunderbird? Meaning, when this is
> implemented, will Thunderbird be able to take advantage of GPOs as well?
Not without additional work by the Thunderbird developers.

> Also - is work actually in progress? Is this planned to be implemented sometime
> in the reasonably near future (year? two?)?
I would not say it is planned but it definitely is desired. MSI will be implemented before this will be.

> The lack of GPO support is what prevents any company (Windows network) with
> more than 50-100 PCs (this includes 3 of my clients) from rolling out Firefox
> and Thunderbird. Now that TB3 is finally out and getting better with every
> release, there is even more interest from 2 of my large clients in switching to
> Thunderbird+Lightning - they don't use most of Exchange's fancy features, and
> are still on 2000, so realize they need to upgrade sometime in the next year or
> two - or better, lose Exchange altogether (yes, they are prepared for the user
> pain), so TB+Lightning would be an option for them if it had GPO support.
I agree that many companies rely on GPO but I've consulted at many large enterprises with 10's of thousands of desktops that don't deploy using GPO and instead rollout / upgrade with silent installers, rollout as systems reach end of life with new imaged systems, etc. I'm not saying we don't want this... just that there are many ways to deploy without GPO, etc.

If you are looking for GPO for Thunderbird you should file a bug to add GPO for Thunderbird... I don't believe there is one yet.
(In reply to comment #93)
> (In reply to comment #92)
> > So, whats the status of this most important and glaring missing feature?

> It has a status of New and hence is not fixed.

Well, yeah, but I meant, is this being actively developed, or is it still in limbo with no active development, as it has been for the last 6+ years?

>> Question: Does this bug also apply to Thunderbird? Meaning, when this is
>> implemented, will Thunderbird be able to take advantage of GPOs as well?

> Not without additional work by the Thunderbird developers.

I already filed bug 547546 for Thunderbird, but someone commented that it *might* be a duplicate of this one (if it were moved to 'Toolkit', whatever that means)...

> I agree that many companies rely on GPO but I've consulted at many large
> enterprises with 10's of thousands of desktops that don't deploy using GPO and
> instead rollout / upgrade with silent installers, rollout as systems reach end
> of life with new imaged systems, etc. I'm not saying we don't want this...
> just that there are many ways to deploy without GPO, etc.

GPO is deployment, yes, but many would say it is even *more* importantly about *configuration management*. Without GPOs, configuration options cannot be managed - with GPO support, they can be pre-defined, changed and even optionally *locked* to prevent the user from changing them.

This is an extremely important enterprise requirement for some companies, and without this support, management won't even consider the software, regardless of any other features it may have.

> If you are looking for GPO for Thunderbird you should file a bug to add GPO
> for Thunderbird... I don't believe there is one yet.

see bug 547546...
> I agree that many companies rely on GPO but I've consulted at many large
> enterprises with 10's of thousands of desktops that don't deploy using GPO

GPO compliance has 2 features: (1) installation as MSI file (2) settings in the special part of Registry, where o/s enforces them. #2 is most important, since without it any user can change the settings, which is exactly what prevents Firefox from being used in corporate network. #1 is less important, but still the number of questions everywhere "how to convert setup.exe to msi in order to deploy by group policy" is high and constant - anybody can google this exact question to see how popular it is. There's number of very expensive products called "repackagers" doing exactly that. Note also that you can deploy msi by all those other methods, silent installers, scripts, sms, etc.

These two features, #1 and #2, are fully independent; the only thing in common is that both can be in in group policy.
There is currently a community-edited version at:
http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm

They provide a .MSI as well a ADM-template, altough the current template is a horrible thing to use for the average administrator at the moment I think.
(In reply to comment #96)
> There is currently a community-edited version at:
> http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm
> 
> They provide a .MSI as well a ADM-template, although the current template is a
> horrible thing to use for the average administrator at the moment I think.

Has anyone (from Mozilla) approached them about incorporating any of their work and/or assisting in making this happen?

In my opinion, this should be made a *top* priority, since implementing true/full .msi/GPO support would automatically make it possible for Firefox (and Thunderbird - please, please don't forget TB when doing this work) to increase by an order of magnitude (or more?) its [their] user/install base.
The lack of MSI aware app update in that distribution is a show stopper as far as being able to use the distro. There has been just as huge of an outcry for MSI support and that is being worked on first.

We typically implement things for Firefox in a way that other apps can ride along with little effort in comparison to the initial implementation but that doesn't negate the apps having to do some work as in bug 547546 for Thunderbird.
regarding the adm effort - (In reply to comment #96)
> There is currently a community-edited version at:
> http://www.frontmotion.com/FMFirefoxCE/download_fmfirefoxce.htm
> 
> They provide a .MSI as well a ADM-template, altough the current template is a
> horrible thing to use for the average administrator at the moment I think.

The critical drawback of the adm template is that true group policy is enforcing the settings on the local machine, which then are being read by the controlled application on every transaction. It's enforcing them continuously, i.e. not just at user logon, or application start. If the user opens registry edit and changes the setting, for example to allow himself to download add-ins, then in the next second the controlled setting will be restored by the system. This community adm template allows to specify the settings in the form of group policy, but they are then imported into Firefox native settings, and if the user then goes and changes these "converted" settings in the firefox, then he will be using changed settings. This makes all this effort useless. What it creates is not a policy.

The true GP compliance can be achieved only by programming Firefox to read policy-controlled settings directly from the registry on every navigation.
The list of policies that Chrome supports:

http://dev.chromium.org/administrators/policy-list-2

and their roadmap is: http://dev.chromium.org/administrators/roadmap

Might be useful, assuming they've done some research on what's most required.
Google just announced support for Group Policy Administration and MSI deployment in Chrome.
http://googleenterprise.blogspot.com/2010/12/chrome-is-ready-for-business.html
Chrome MSI is an excellent example of what to avoid if Firefox developers decide to go ahead with MSI. It's not a real MSI, it's a wrapper around the executable, i.e. instead of deploying files, registry settings etc., it simply unpacks and launches the usual setup.exe.

Google is not the first one to do it. For instance, Adobe Flash and Reader are the same fakes. While this method does allow to deploy by group policy, it's missing practically all the advantages of Windows Installer (see http://download.microsoft.com/download/6/c/1/6c13d1b1-5891-4b81-b4fc-3c92a96d1539/wininstaller.doc ), and in many cases the administrator will have to repackage it into true MSI installation prior to deployment.

In order to simply launch setup.exe by group policy, one does not need to create this fake MSI. There's little known feature, so called ZAP files ( http://support.microsoft.com/kb/231747 ), that also can be deployed by GP, and it's basically an inf file that will launch the same setup.exe.
Blocks: 547546
What would be important for me:
- no access to about:config (send to homepage?)
- no access to profilefolder locally or on netwurk
- set proxy-settings and make inaccessible
- set homepage and make inaccessible
- no plug-ins by user
- no add-ons installing by user, except some standards
- no updates only after packaging
- limit cachesize
- block sync

Work in progress:
https://wiki.mozilla.org/Enterprise
https://wiki.mozilla.org/MSI
http://sourceforge.net/projects/firefoxadm/
http://homepages.ed.ac.uk/mcs/FirefoxADM/Readme.htm

chrome has done some work:
http://downloadsquad.switched.com/2010/09/25/admin-policy-templates-google-chrome-enterprise/
http://www.chromium.org/administrators/policy-templates

We have some resources available, but guidance would be great.
Regarding firefoxadm project, if I'm not mistaken, it's what I wrote in Comment 99 above. It's not enough to present the settings in the form of ADM template and import them to the native settings on startup. For those settings to be true policy, the work must start at the application (i.e. Firefox), which has to look for these settings in the designated areas of the registry. Indeed, Chrome did it right, according to this description from their page:

Policy settings can be stored in the registry under HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER in the following paths:

    Google Chrome: Software\Policies\Google\Chrome\
    Chromium: Software\Policies\Chromium\

Only these designated areas are under Windows "supervision", and if the user opens regedit and changes them, they will be restored. If this does not happen, then this is not a policy.

The only way to make it a true policy is to code Firefox to look under software\policies in the registry; settings that are found there should override settings specified in the Firefox native settings file. Sending them back and forth by these javascripts only pretends to be a policy.
Blocks: 749400
Blocks: 438872
Blocks: 438872
As my team is responsible for the updater, and we've had several conversations about this topic (and this bug), I'm closing this as WONTFIX.

There are a variety of solutions for those who need verbatim MSI (some mentioned in these comments, as well as our own mhoye's bespoke.io -- see http://exple.tive.org/blarg/2011/03/22/here-we-go/).

For everyone's edification: the common perception is that MSI would automatically provide everyone with what they need. That is only partly true: it is not automatic -- specific functionality would need to be both created and supported, and that could (and probably would) vary for each consumer of the common use case, which is handling enterprise deployments. We are not well suited or staffed to keep up with individual enterprise solutions in perpetuity.

[Accordingly, you can refer to bug 1034988 for a kind of contract that we could conform to in the future.]

At any rate, keeping this bug open ongoing doesn't help anyone, and only serves to make people wonder what our intentions and opinions are. If anyone can make a case for keeping this bug open, I'm all ears; in the meantime, it's closed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
See Also: → 1034988
This isn't the MSI bug, this is the Group Policy bug.

I think you meant to close bug 231062
> - specific functionality would need to be both created and supported, and that could (and probably would) vary for each consumer of the common use case, which is handling enterprise deployments.

Not so. MSI supports so called transform, which is an add-on file that modifies the base MSI. Network administrator can create one or more transforms which will customize the MSI for his organization, and further to create different transforms for various groups of users within his organization. This is standard technique, and major software vendors even provide the tool for network administrators to customize their installations (Microsoft Office, Adobe Reader, and more)

I personally would be glad to take on development of the MSI of Firefox.
Assignee: mattwillis → nobody
mkaply is correct -- in my EOD hurry, I updated the wrong bug, having scrolled to the bottom of long comments thread. Argh.

vadim -- then you will want to comment to the same effect in bug 231062.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Since 2000/XP/2003 are dead products anyhow, maybe this should go back to "WONTFIX", and start this over in a new one for current Windows versions.
2000/XP/2003 are listed only because at the time when this BR was created, 13 years ago, they were current. Group policies have not changed since, they are the same in today's Windows as ever.

If you are going to mark "wontfix" and start over anything that mentions specific Windows version whenever there's a newer one, it looks like there will be a lot of work to do.
Maybe correct the title of the bug then, and the platform.
Status: REOPENED → NEW
OS: Windows 2000 → Windows
Hardware: x86 → All
Summary: Windows 2000/XP/2003 Group Policies support (make firefox configurable with domain group policy objects) → Windows Group Policies support (make Firefox configurable with domain group policy objects)
This is one of the features that Firefox lacks to enter the corporate world. My system admin refuses categorically to validate the deployment of Firefox because it can not administer the rights with the GPO. Chrome has this feature and therefore has the favors of my admin. Can you advance on this subject please?
Since there are already patches existing, can someone please update them to be current? That way, at least there will be a decent jumping off place to getting this moving again. Thanks.
Flags: needinfo?(robert.strong.bugs)
I don't have the time myself and this isn't actually a "shell integration" bug anyways. If it is to have a "decent jumping off place to getting this moving again" I personally don't see the value in doing so since the approach would likely need to be reworked.
Flags: needinfo?(robert.strong.bugs)
(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #117)
> I don't have the time myself and this isn't actually a "shell integration"
> bug anyways. If it is to have a "decent jumping off place to getting this
> moving again" I personally don't see the value in doing so since the
> approach would likely need to be reworked.

Then what component should this be filed under, if not "shell integration"?
Not a shell integration bug. I suspect this is a Firefox -> General bug but moving to General though preferences might be appropriate since this deals with preferences.
Component: Shell Integration → General
1. It's not a bug, it's in fact a request for feature.

2. In fact it deals with two very different features. One is not about Firefox itself, but rather about creating a special form of the installation package of it, compliant with corporate network deployment practices. See the comment from Stéphane Aulery above.

Another one deals with the place where Firefox stores, and reads from, the settings, including blocking certain features. In order to be compliant with the same corporate networks, that place must be a specially designated place in Windows registry. It can be in addition to the "regular" settings, and it does not have to be controlled from within Firefox itself, but any settings specified there (by other means, familiar to network administrators) should override the settings specified by the user (more specifically, the user should see them as disabled).
I just read in press about https://wiki.mozilla.org/Firefox/EnterprisePolicies#Deploying_the_configuration_file, but it looks like this is a serious feature regression. A mozilla.cfg setting file that is already the same featue https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment allow setting preferences with pref(), defaultPref(), lockPref() and clearPref(). The new JSON file has no indication that locking or defaults are possible.

That means a clear feature regression. Additionally I see nothing about a setting refresh every 6 hours (can be reconfigured for GPOs) like a GPO does by default.

Does one of you know in what case this new no-brainer feature will be implemented?
As I understand it, the design of the policy engine is intended to be platform-agnostic from an implementation standpoint, with group policy integration being the near-term-priority client. And, while I'm not running that show, the whole point of group policy is setting and locking default settings on a windows domain. So I expect that your concerns will be addressed in the initial release of that product.

However, as you note, much here is still in flux and there are decisions still to be made. With that in mind, if we could find a way to talk about feature parity or architectural concerns without condescension ("no-brainer feature", etc) that would be very helpful.
Being able to differentiate between locked and default preferences (whether it be in a config file, a GPO, etc) would definitely be a plus. I've seen some organizations where all users MUST use the same homepage (for instance), but I've also seen ones where they set a default and allow the user to change it if they want. Just my 2c.
@Mike: Honestly - there is documentation that is public and looks final roadmap and it is wrong as it is a regression.

We see here a case that is 13 years old and still unresolved and now someone works into the wrong direction by destroying features. Since day 1 of Firefox I cannot administer Firefox properly / as needed. The door is closing for Mozilla as all goes to Chrome that provides all this features. But as a Firefox lover we do not like to move into this direction. Now others may force us to move as we have no solution here. This ignorance and wrong priorities make people only aggressive.

I agree on having something platform-agnostic, but it should have been implemented 13 years ago. As it was not, things need to move a lot *faster* now or Firefox is done. I guess we do not want this to happen or we woulnd't be here.
> @Mike: Honestly - there is documentation that is public and looks final roadmap and it is wrong as it is a regression.

What specifically are you referring to?

This has been implemented.

Status: NEW → RESOLVED
Closed: 7 years ago5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.