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.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

32 thoughts on “Customizing Firefox - Blocking Add-ons

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

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

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

  4. Thanks for the great information. Since I started looking into this, my company decided to not block any add-ons or extensions.

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

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

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

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

  9. Guys, it looks like all of this is unnecessary now in Firefox 21.

    I'm using lockPref("xpinstall.enabled", false) and it will not allow anything to be installed, or allow the user to change anything.

    You get the "this has been disabled by your administrator" dialog box, and thats it.

    So it looks like this preference has been fixed/updated in FF21 to actually work properly.

    yay!

    ross

    • Actually, even if you do that, there are still ways to install add-ons through the add-ons manager, in particular by using the search box in the uper right. So this is still needed.

  10. Mike

    Thank you for your excellent blog! I have been able to implement many of the settings I need to deploy to my users via CCK-generated xpi and varoius other settings found on this site.

    While I have been able to follow your instructions and successfully block access to about:Addons...is there a way to block access to about:home? or the settings snippet on that page? I have not been able to figure that out despite my efforts and any advice would be greatly appreciated.

    Thank you

    • I believe that if you set the preference browser.aboutHomeSnippets.updateUrl to blank, you won't get snippets. They are cached, though, so you might see them for a while.

      Overridding about:home would be pretty straightforward, but it's not typically requested. Is there some specific reason you don't want about:home?

  11. I'm looking for a way to either prevent access to the add-on manager on a mobile device or prevent the uninstall of add-ons. I know you've addressed the computer angle but I really have been trying to figure out how to lock down the app on my phone. Thanks.

  12. For the interest of making a pertinent product comparisons,
    we've looked at routers in this range that reveal similar characteristics for example IEEE 802.11n wi fi standards, 2.4-ghz band and
    dual antennas. Nothing less than an n layer 3 switch is highly recommended, if you're searching for a new router.

    If you own a wireless g router, it might be advisable to upgrade to
    some wireless n layer 3 switch. The newest routers also raise speed with
    wifi Quality of Service software (QoS) common,
    which makes efficient usage of Ethernet connections by prioritizing multimedia traffic according to the program's
    sensitivity to delay. Many wireless-n routers also apply multiple-input and numerous-output (MIMO) radio
    antennae to boost speeds.