Customizing Firefox - Blocking Add-ons
Another question that comes up a lot is how to prevent users from installing add-ons. There's a preference, xpinstall.enabled, but it's useless because it does nothing to prevent access to the Add-ons Manager. The reason this is a problem is because you can install add-ons from AMO there from the Get Add-ons tab. In addition, when you try to install an add-on with the pref set to false, Firefox lets you enable it with one click. So we need to make that preference more effective and we need to hide the add-ons manager.
These code samples build on our previous posts about customizing Firefox, so I'm going to assume you've read them.
First let's prevent the user from accessing the Add-ons Manager. There are three main entry points to add-ons manager, Tools->Add-ons, Firefox Button->Add-ons and about:addons. For the menus, we're going to follow the procedure to locate the menus that we talked about earlier. Here are the changes we need in our overlay to remove the menuitems as well as disable the command (this takes care of the keyboard shortcut - Ctrl+Shift+A):
<command id="Tools:Addons" oncommand=""/> <menuitem id="appmenu_addons" style="display: none"/> <menuitem id="menu_openAddons" style="display: none"/>
Removing about:addons requires changes to the chrome.manifest that we learned about here.
override chrome://mozapps/content/extensions/extensions.xul data:text/html,Disabled
There's one other place in the UI where a user can get to the add-ons manager, so we should take care of that. It's in preferences. At the bottom of the first tab, there is a button to open the Add-ons Manager. In order to remove this button, we'll need to create a new overlay file because we're not overlaying the main window, we're overlaying the preference window. Just copy your main window overlay to a new overlay called pref-main-overlay.xul. In chrome.manifest, we'll need to reference that new file:
overlay chrome://browser/content/preferences/main.xul chrome://myextension/content/pref-main-overlay.xul
Then we'll need to put some code in the overlay to hide the add-on groupbox in preferences. Looking in mxr, we can see that the groupbox that contains everything has an ID of addonsMgrGroup so we can just use that to hide it all:
<groupbox id="addonsMgrGroup" style="display: none"/>
Finally we need to address that preference. The secret to using the xpinstall.enabled preference is that you have to lock it. When you lock a preference, Firefox will prevent the user from changing it. Locking xpinstall.enabled does more than that, though. When it is locked, it tells the user that add-ons have been disabled by the administrator.
The preference xpinstall.enabled doesn't exist by default in Firefox, so before we lock it, we need to add it. You can add preferences to an extension by creating a JS file in the defaults/preferences subdirectory where you've created your add-on. It can be named anything as long as it ends in JS. We'll create a file called myextensions.js that contains our default value:
pref("xpinstall.enabled", false);
Now that we've set the preference, we need to lock it. The easiest way to lock a preference is by using an autoconfig file. We want everything to be self contained, though, so we are going to do something different.
Up to this point, when we've talked about overlays, we've only indicated they can contain XUL. But they can also contain Javascript. At the top of your main window overlay, add this:
<script type="application/x-javascript">
<![CDATA[
Components.classes["@mozilla.org/preferences-service;1"]
.getService(Components.interfaces.nsIPrefService)
.getBranch(null)
.lockPref("xpinstall.enabled");
]]>
</script>
Now the xpinstall.enabled preference will be locked, so a user cannot install add-ons.
If you type about:addons into the browser, you'll notice something kind of annoying - we lose the URL bar. This is because about:addons is a special URL that removes the chrome in the browser. We can fix this by modifying the list that Firefox keeps of these special URLs. Just add this to your Javascript block:
XULBrowserWindow.inContentWhitelist =
XULBrowserWindow.inContentWhitelist.filter(function(e) {e != "about:addons";});
And there you have it. Users shouldn't be able to install add-ons or access the add-ons manager.
Does this also prevent the Ctrl-Shift-A keyboard shortcut from opening the addon manager?
Yes. By overriding the command, we prevent they keystroke.
I think I would hate having to work under a systems admin who enforces all the various restrictions you've detailed in your blog. Hopefully if I'm ever in that situation I'll have the option to use personal computing equipment.
I don't think you understand where customizations like this are used. They might be used in a hospital for computers that they can't risk getting misconfigured. Or in a public setting where someone could step in and mess with the machine. Or at Lowe's in the wallpaper department where the machine is used by many people and you don't want it to be customized it. It's not about controlling people, it's about making sure the machine does what it needs to do. Not everyone uses a computer as their primary tool, and for those people, there are cases where you need to limit what they can do. It's just common sense.
It's also worth noting that it's seldom the systems administrators that are looking to bring down the iron fist of enforced system settings. As Mike pointed out, sometimes there's a single-purpose system that needs to go to one web site, and that's it. Settings like this prevent the system from being abused.
Other times, it might be a corporate and/or security policy that dictates these settings.
Trust me; systems adminsitrators have better things to be doing than messing with lowly end-users. I should know...I found this page looking for settings I was told I had to implement. I don't have a choice, and if I did, I wouldn't bother.
On a related note: remember that at work, you're using someone else's property (computer, Internet connection, etc.). It's up to them to decide how you're allowed to use them, not the other way around. Don't like it? Start your own company where the property will be yours...but then I think you'll quickly gain an appreciation for the locking-down of user workstations once it's YOUR money and business on the line.
Great thoughts, Eric.
Does this also block chrome://mozapps/content/extensions/extensions.xul?pants ?
If I remember correctly, overlays don't work right with search params, because it'd just doing a dumb string match on the whole URL, instead of the pre-search part...
(I probably would overwrite it to javascript:window.close() instead, so if some other UI triggers it, it still would just close the new window.)
Wow. I didn't know about that. That's just plain dumb. I hope there is a bug on that.
Again, though, my methods aren't designed to completely block access to things. They are to designed to remove the typical user's access. A typical user wouldn't know about that URL.
Yep, that's bug 486352. Songbird was using query params to choose which subset of your music to show, which was how we found it.
be even better if the addon compatibility check would at least check to see if there is an internet connection instead locking up firefox when starting up.
Thanks for the great information. Since I started looking into this, my company decided to not block any add-ons or extensions.
Good for them.
A variation of the theme. Could this somehow be modified to prompt for a password and if password is OK add-on management is allowed?
What we are aiming for in our organization is a customized base, and then a few "trusted" persons can install extra add-ons needed within their department.
That would be a little trickier.
If I did that, I would probably enable add-ons for everyone and add the password into the "install add-ons" dialog.
It would say "add-ons can only be installed with a password" or something like that.
I can't get the URL bar back.
I've added the code you suggested but it doesn't work.
Did I add it in the correct place?
Here is what I have now:
I apologize for missing this, but some code got lost in your comment. Are you still having this problem?
Is there a way to do the same thing via the CCK wizard, i have been trying to find a way of doing this and we already use the CCK wizard.
thanks
I'll consider adding this to the CCK.
Better yet.. Get xpinstall.enabled to work again as it should:
The only reason the add-on wizard allows installs from about:addons/etc is because Mozilla whitelisted 3 domains (getpersonas.com,marketplace.firefox.com,addons.mozilla.org)
Add the 3 domains whitelisted for install by Mozilla to the denied list of domains in CCK Wizard before creating your addon.
Set and lock xpinstall.enabled to false and xpinstall.whitelist.required to true in CCK Wizard.
Use CCK Wizard to build an addon that you drop into distribution\bundles
Always runs, even if Firefox is started in safe mode. Undoes the damage mozilla did to xpiinstal.enabled by adding preconfigured whitelisted domains for add-on installs by adding them back as blocks and then requires any future xpi install to be on the whitelist (which is now empty of any "allow" domains). No editing of original mozilla files. Sure, they can get to the add-on manager, but they are not going to get anything installed by it.
Not quite sure, but I guess users can still just copy a (extracted) extension to there profile\extension folder ... and voilà: they can use it!
I think the only way to stop that, is to allow only signed or white-listed extensions -but FF is far away from integrating this. So I will promote Chrome for our users and sooner or later quit FF ...
If you are locking down Firefox, but then allowing your user to make any modifications to the operating system, why would you bother locking down Firefox?
Any user with a command line can make any changes they want...
Tried that, didn't work for me. Removed the whitelisted sites, locked xpinstall.enabled to false. Was still able to install addons from the extensions tab of Add-ons Manager.
Please see my newer post here:
http://mike.kaply.com/2013/02/18/allowing-only-certain-sites-to-install-add-ons/
I don't have any code right now that completely removes the Extensions discovery page. I'm working on it.