Why extensions are not allowed to modify pages like AMO by default and how to override this behaviour if you must

Particularily for my extension “User-Agent Switcher” users have repeatedly asked how they can use it to lie to Mozilla's own Add-ons site and pretend they use some current browser version. The reason for this being that many extension developers set their minimum required version too high – either because they simply don't care, or because there is that one tiny feature in there that is not supported in browser version X, with the rest of the extension working fine without it however. For these reasons some users on older browser versions prefer to just try the latest version rather that stick with an older version that declares support (if there is any).

This guide explains which services are blocked by default in particular and how to override this behaviour if you must. (Most of this text was originally posted on User-Agent Switcher's AMO page, but one day a reviewer came along and requested me to remove it from there, so it is now moved here instead.)

Which domains are affected and how?

Quite a few actually, you can view the latest list by opening about:config and searching for “extensions.webextensions.restrictedDomains”, but if you are just curious which kinds of domains are affected take a look at this list of restricted domains of Firefox 63:

  • Firefox Accounts:
    • accounts.firefox.com
    • api.accounts.firefox.com
    • oauth.accounts.firefox.com
    • profile.accounts.firefox.com
    • accounts-static.cdn.mozilla.net
  • Firefox Addons:
    • addons.mozilla.org
    • discovery.addons.mozilla.org
    • addons.cdn.mozilla.net
  • Firefox Sync (also uses Firefox Accounts):
    • sync.services.mozilla.com
  • Mozilla Help:
    • support.mozilla.org
  • Others:
    • content.cdn.mozilla.net
    • install.mozilla.org

Additionally at least the following types of browser requests are restricted as well:

  • Browser update checks
  • Certificate OCSP checks:
    Checks if the given certificate is still valid and has not been revoked. These requests occur whenever a not-recently-visited website is opened in the browser and its server does not implement OCSP stapling to prove the validity of its certificate during the initial response.
  • Google Safe Browsing checks:
    Used by the browser to check for known phishing domains when you open a new website for the first time.

The word restricted in this context means: May not be visible to WebExtensions whatsoever.

Hence extensions may not:

  • Observe any traffic sent from/to any of these domains
  • Have no access to cookies or similar site content of these domains
  • Cannot register any content scripts (scripts able to observe, modify or interact with the loaded page) on any pages loaded from these domains

… in other words: They are basically invisible to extensions. The only thing that extensions can see is when you open, navigate in or close a tab with such domain if they have the standard tabs permission.

Why was this restriction added?

The primary resource on this is the discussions on Mozilla bug 1279371 and Mozilla bug 1415644 (CVE-2018-5152).

In the reasoning behind most of these restrictions seems to fall into 3 general categories:

  • Extensions should not be able to reduce the security of the browsing software itself
    • Browser update checks
    • Probably also add-on installation and updates (no official statement)
  • Extensions should not be able to affect/weaken the security of websites loaded in non-obvious ways
    • OCSP & Safe Browsing checks
  • Extensions should not be able to indirectly access information they do not have any permission for
    • Mozilla Add-Ons has access to special browser (“Add-on Manager API”) that could be exploited by other extensions to install or uninstall any extension on that site
    • Firefox Accounts uses access tokens that can be used to remote-control several browser features
    • Firefox Sync may be used to read and possibly modify browsing history, bookmarks and the list of installed extensions while syncing

Disabling any of the restrictions mentioned in the last section, exposes you to the risk of extensions doing any of the bad things mentioned above.

How do I allow extensions access to these restricted domains anyway?

As for the OCSP, browser updates, Safe Browsing, … kinds of requests there does not appear to be any way to grant access to these to extensions. You would have to either load a classic bootstrapped or “WebExtension Experiment“ into an unbranded edition of the browser (such as Firefox Developer Edition) that allows this. The only known way these can be modified by default is to disable them entirely in the settings (some of these may require the use of enterprise policies or pref override files).

Some of the requests to the restricted domains mentioned in the first section however can simply be made “visible” to add-ons by opening about:config, searching for the previously mentioned “extensions.webextensions.restrictedDomains” preference and removing the domain in question from the coma-separated string list.

The Special Case: addons.mozilla.org

Now, if you try to remove the domain addons.mozilla.org from the list you may be disappointed at the result: Nothing will happen at all!

That is because Mozilla Add-ons also has access to a special API, called the “Add-on Manager API”. This allows the site to enumerate the list of add-ons installed in your browser and show you the “Uninstall” button for any extension you have already installed rather than just offering you the ability to install it again. All websites with access to this special API are also restricted from being accessed by any extension.

To remedy this create a new boolean pref (right-click → NewBoolean) in about:config with the name “privacy.resistFingerprinting.block_mozAddonManager” and value true. This will disable the Add-on Manager API and will now allow the Mozilla Add-ons site to be modified like any other.