Firefox 60 ships with Windows Group Policy Support
Mozilla is working on integrating Group Policy Support for Firefox running on Windows devices in the upcoming Firefox 60 release.
Firefox 60 is the next Extended Support Release of the web browser which replaces Firefox ESR 52.x, the last official version of Firefox to support the old extensions system. Mozilla made Firefox 60 the next ESR target and not Firefox 59.
According to the Firefox release schedule, Firefox 60 will be released on May 8, 2018.
Mozilla Firefox supports an automatic configuration system for Firefox installations already using autoconfig files which works on any supported desktop platform.
The new Policy Engine in Firefox reads data from the Registry created by Group Policy Objects and applies the policies if found to be valid.
Development bug 1433136 documents the implementation progress and bug 1433173 work on the Policy Engine.
Firefox 60: the policies
All available policies are listed under Computer Configuration > Administrative Templates > Firefox and User Configuration > Administrative Templates > Firefox after the policy template files are added to the relevant directories on Windows.
The following options are available at the time of writing:
- Block About Addons -- prevents access to about://addons to manage addons.
- Block About Config -- prevents access to about://config.
- Block About Support -- prevents access to the troubleshooting page about://support.
- Block Set Desktop Background -- users cannot set the wallpaper of the desktop using Firefox.
- Create Master Password -- prevent the creation of a master password.
- Disable Update -- block Firefox from updating.
- Disable Developer Tools -- turn off the Developer Tools in the browser.
- Disable Firefox Accounts -- prevent sign-in to accounts and syncing.
- Disable Firefox Screenshots -- turn the Screenshots tool off.
- Disable Firefox Studies -- turn participation in Firefox studies off.
- Disable Form History -- prevent Firefox from remembering the form history.
- Disable Pocket -- turn off Pocket in Firefox.
- Disable Private Browsing -- block Private Browsing functionality.
- Display Bookmarks Toolbar -- show the Bookmarks Toolbar by default.
- Display Menu Bar -- show the Menu Bar by default.
- Don't Check Default Browser -- block checks for default browser.
- Homepage -- set a homepage (or multiple), and optionally disallow the changing of those.
- Remember Passwords -- allow or disallow the saving of passwords.
- Bookmarks -- Set default bookmarks.
- Permissions: Addons -- Allow addon installation on specified URLs.
- Permissions: Cookies -- Set URLs to allow or block cookies on.
- Permissions: Flash -- Set URLs to allow or block Flash on.
- Permissions: Popups -- Allow popups on selected sites.
Note that the template file and integration is a work in progress and that additional policies will be supported when Firefox 60 launches. This may include network.proxy, data reporting, or update policies according to Mike Kaply, a developer who works on the implementation.
Chrome admins have access to a similar set of policies.
Closing Words
Integration with Group Policy on Windows machines should make things a lot easier for system administrators who deploy Firefox on a computer network. Regular Firefox users may use the policies as well to modify certain browser settings.
Now You: What's your take on the development?
Where is the “fix” for Linux users ?
Too cheap, lazy, or Stupid to supply ?
If you have windows server 2008 (like my company does, and upgrading is but a distant dream… no budget(!)) then it seems these group policy profiles are ignored. Isn’t it just possible to set a HKEY Machine / HKEY currentuser entry in the registry somewhere and have these defined?
Also – as a side note: putting a footer on your website stating that advertising revenues are falling across the web is stating the obvious. Nobody pays attention to adverts, they are just an annoyance. If you are looking for other ways to fund the site, move to a cheaper hosting provider and skip one or three pints in the pub every week!
can we use GPO to restrict url in firewall ?
I’ve attempted to use GP settings to activate Flash on websites (our timesheets system still requires Flash). To cover the bases, I configured the same settings under Computer Configuration and User Configuration and applied the test GPO to a computer OU and a user OU. Unfortunately, I still have to manually activate Flash for the specified website.
I set “Activate Flash on websites” to Enabled, as well as specified URLs under “Allowed Sites” — both settings found under Policies/Administrative Templates/Mozilla/Firefox/Flash
Any ideas on what I may have missed or done incorrectly?
Do you know of any plan to create policies for the stigs for Firefox security implementation?
https://nvd.nist.gov/ncp/checklist/356/download/3178
As FF is used on other operating systems (e.g., Linux) what kind of policy engines might be available. I currently use the about:config as my primary tool.
About time that they did this. There were other Firefox Group Policy projects in the past, but they were third party and spotty.
If you want enterprise mass adoption, make it easy for administrators to do centralized configuration!
Not one comment (yet) about how someone’s rinky-dink extension doesn’t work with Quantum. Nice!
Good for network admins to prevent users from wrecking FF inadvertently and it gives easy access to some of the settings tweakers want to change but leaves out most of the privacy settings.
Only Windows versions that have access to gp editor are Win Pro and Server, so these seem intended to get more FF network installs.
You can install gpedit in Windows 10 Home, http://www.justfuckingoogleit.com “windows 10 home group policy”
We’re not done yet. What privacy settings are you referring to?
As far as Windows without GP Editor, you can use the JSON file in those cases.
Firefox ESR 52 will be the last version of FF I’ll use. It’s a shame what’s become of it. It started going downhill with version 4. I miss the days of 3.6.
“ships with”
sigh…
Will similar exist on Linux?
The Policy Engine is for all OSs, yes. Mozilla will soon launch a campaign on Firefox targeted at enterprises to promote the new feature.
I’ve started updating the docs here (https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment) with how it works on Linux and Mac
Very interesting, I just hope it won’t give problems to portable versions…
Portable versions have already problems with v.57+
I’m presently using the Firefox autoconfig feature. I’m curious to know if this autoconfig will continue to run alongside Windows Group Policy for Firefox and if so which of the two will prevail.
Autoconfig is really handy, not only to have a basis for new profiles but as well to impose a user setting which otherwise (when set from regular about:config/user.js) can, in certain situations, be invalidated by an extension. For instance I run a dedicated ‘new tab’ extension which not only builds a personalized new tab page (which is its purpose) but moreover replaces the about:home by its new tab : with autoconfig I can block about:home to my preferences hence forbidding it from being changed by an extension…
Not sure Group Policies will be as feature-rich as Autoconfig, the settings definitely won’t concern all those of Firefox when Autoconfig has for only limit that of about:config. We’ll see.
If you have an autoconfig.js under -> Mozilla Firefox / defaults / prefs / this should continue to work!
However, “security.enterprise_roots.enabled = true” must be set so that your own certificates can be better used. In addition, from Firefox 60 should be under Windows the Enterprise Police -> Mozilla Firefox / distribution / policies.json available.
Certificates must therefore be imported only once with the following example!
Policy-JSON-Sample:
{
“policies”:
{
“Certificates”:
{
“ImportEnterpriseRoots”: [true]
}
}
}
Youtube: https://www.youtube.com/channel/UCHJF_wP0UzdQUa5WtlpaQWw
Are you using the basic APIs in AutoConfig (pref, defaultPref, lockPref) or something else?
@Mile, I’m using lockPref,
I have a config a config-prefs.js in [Firefox install folder]\defaults\pref\ :
// config.js
pref(“general.config.obscure_value”, 0);
pref(“general.config.filename”, “config.js”);
calling config.js in [Firefox install folder] :
// config.js
// DISABLE CONTAINER
lockPref(“privacy.userContext.ui.enabled”, false);
lockPref(“privacy.userContext.extension”, “”);
lockPref(“privacy.userContext.longPressBehavior”, 0);
lockPref(“privacy.userContext.enabled”, false);
lockPref(“privacy.usercontext.about_newtab_segregation.enabled”, false);
//
// AUTO-RESETS TO TRUE ON START -> SET TO FALSE
lockPref(“devtools.onboarding.telemetry.logged”, false);
//
// ENFORCE HOMEPAGE
lockPref(“browser.startup.homepage”, “about:home”);
lockPref(“browser.startup.page”, 1);
Personal settings of course inherent to my context and wishes, but that’s the idea, now and here on Firefox 58.0.2
@Tom Hawack
I don’t know if as a user who wants to send *nothing* to Mozilla you need to protect against this, but if you do you might want to lock devtools.selfxss.count to 0 as well, since it’s part of the same thing: I don’t think it’s possible that a user has the “logged” pref set to false and “selfxss.count” to anything other than 0.
@Jamy, thanks for pointing this out.
I’m not an expert so I proceeded with basic logic : I wish(ed) to block Firefox’s onboarding so I checked its occurrences and settings in about:config. I was amazed that when right-clicking on devtools.onboarding.telemetry.logged (bold and true) it would reset to false and when restarting Firefox it would be set to true! It wasn’t then in my user.js file and I see no extension of mine which would set that darn preference to true on every Firefox start. Mystery. So, because the default is ‘false’ I’ve included it above.
My comment above is dated March 11, 2018 and the problematic remains here and now, January 20th, 2019 …
@Tom
Hi, sorry for the late reply. Couldn’t find the link again and since it’s an old article, I didn’t expect you to ever read my comment :)
Anyway, I added a second link but I must have failed to format it properly and Ghacks security botched it. What I meant to say was probably not right anyway, devtools.selfxss.count seems to increment on DevTools use, so not at the same time as devtools.onboarding.telemetry.logged.
In Firefox 64, Onboarding is not a system add-on any more, but possibly part of Activity Stream. There is this new pref, which I’m not sure what it does so if you know, I’m all ears:
pref(“browser.newtabpage.activity-stream.asrouter.providers.onboarding”, “{\”id\”:\”onboarding\”,\”type\”:\”local\”,\”localProvider\”:\”OnboardingMessageProvider\”,\”enabled\”:true}”);
This is the default value. Replacing true with false sounds like it would disable *something*.
Back to devtools.onboarding.telemetry.logged, the reason it keeps turning to true is that the code path where it happens seems to run on Firefox startup, specifically when Devtools are initiated: https://dxr.mozilla.org/mozilla-central/source/devtools/startup/devtools-startup.js#232
The highlighted function sets the logged pref to true regardless of anything. And this code path is triggered without unnatural conditions according to this comment in the code: // handle() can be called after browser startup (e.g. opening links from other apps).
Which leads me to think that few users have this logged pref set to false. Now if you have it set to false, look at what happens: https://dxr.mozilla.org/mozilla-central/source/devtools/startup/devtools-startup.js#337
It calls into telemetry and sets a value. This won’t happen if logged is true because telemetry doesn’t care about setting the value twice. In which case, we can make a guess that the logged pref means “telemetry already learned what it wanted”. So… should force-setting it to true before the very first start of a fresh Firefox profile ensure that telemetry will not learn about this ? Could be.
Disabling DevTools with a group policy should work too.
But if you try to create a brand new profile with no custom configuration whatsoever, no autoconfig, no group policy, then open it once, do nothing and close it, you will see that prefs.js already has logged set to true. Meaning this pref is not tied to anything the user does or any custom configuration he has. So I don’t think it’s a threat, and I don’t think it creates any leak to Mozilla on its on either. I’d say that its use is either local, or it’s a technical bit of data sent together with other things if needed, in which case we are only really interested in the switch to turn off the sending. (Probably the main telemetry switches in this case)
No certainty here, I just wanted to question that maybe force-setting that pref to false is either useless or counterproductive. (because nobody has it set to false and because when it’s set to false, it appears that telemetry logs a bit again then tries to set it back to true)
@Jamy, thanks for detailed explanations but I’m afraid this is too complex for me.
devtools.onboarding.telemetry.logged : set to false by me (within the above mentioned scenario)
devtools.selfxss.count is at 0, default, untouched by me (I should check that value without forcing above setting)
browser.newtabpage.activity-stream.asrouter.providers.onboarding here is set to “” by me
I could of course disable DevTools with a Policy template (‘disable the built-in developer tools’) but some extensions need it, i.e. ‘HTTPS Everywhere’ even if I’ve replaced that extension with HTTPZ and not concerned, and about:debugging won’t display with DevTools disabled.
I understand the brand new profile scheme but I won’t bother given that would lead only to a proof of concept and that the mystery is all in my profile’s configuration.
You write, “maybe force-setting that pref to false is either useless or counterproductive.”
Useless I can understand, imagine that; counterproductive “because nobody has it set to false and because when it’s set to false, it appears that telemetry logs a bit again then tries to set it back to true” triggers my curiosity. You may be so right but that negative effect would remain negligible I guess. Remains that if setting/forcing devtools.onboarding.telemetry.logged to false has no positive effect but is possibly counterproductive I should logically remove that forced setting. When symbolism defeats rationalism : I’m emotionally concerned with [whatever].telemetry.logged : telemetry gets me out of my mind :=)
Anyway, not an issue, rather a source of curiosity. I have your points in mind and I may remove that setting.
Thanks again, Jamy.
Great. Looks like you’re using the standard API, so you should be fine.
Those disable container prefs are interesting. I’m wondering if we should add a policy for that.
Of course, first line of config-prefs.js is // config-prefs.js and not // config.js
No impact, just for the sake of good sense…
@Mike Kaply, I had disabled containers at a time I was using an extension called ‘Cookie Autodelete’ which would modify the containers’ settings even though I had checked the extension’s option to avoid containers. I don’t use the extension anymore but neither the container feature so I kept its settings disabled.
Anyway, a very handy feature, that of autoconfig. The user decides, the application follows, “It’s good to be the king” :=)
Mike, great work on the implementation, looking really good. Thanks for coming by.
Cool, I like it.