AMO Review Policies

In order to ensure all add-ons hosted in our gallery are safe for users to install, Mozilla requires all hosted add-ons to undergo review. We offer two types of review and developers are free to choose the best fit for their add-on.

  • Full Review — a thorough functional and code review of the add-on, appropriate for add-ons ready for distribution to the masses. All site features are available to these add-ons.
  • Preliminary Review — a faster review intended for experimental add-ons. Preliminary reviews do not check for functionality or full policy compliance, but the reviewed add-ons have install button cautions and some feature limitations.

Detailed descriptions of each option are below. After selecting a review process at submission, the add-on will be placed in the queue. Add-ons are reviewed by the AMO Editors, a group of talented developers that volunteer to help the Mozilla project by reviewing add-ons to ensure a stable and safe experience for users. Developers will receive an email with any updates throughout the review process. Review times can fluctuate depending on reviewer availability and the complexity of the add-on being reviewed. Regular updates of review queue status are posted in the Add-ons Blog.

While waiting for review, add-ons will not appear anywhere in the gallery publicly, but direct links to the add-on's details page will work. This allows the author to blog or share the link with friends, inviting them to try it out, even when not yet reviewed.

Full Review

Full reviews are appropriate for add-ons that are well-tested, stable, fast, and have wide appeal to our users. If you aren't confident that your add-on meets that criteria, please consider working out the kinks while in preliminary review and accumulating user feedback first.

Testing Methods & Common Issues

When performing a full review, editors will:

  • install the add-on, making sure it functions as described and is free of major defects
  • perform a source code review, looking for performance and security best practices
  • ensure the add-on's privacy policy is in line with its functionality
  • look for compliance with all of Mozilla's policies, detailed in these documents

Some of the most common issues we see when performing these reviews are:

  • JavaScript namespace pollution. Be sure to wrap your loose variables
  • proper preference naming - all preference names should begin with "extensions.", followed by the add-on name or some other unique identifier
  • remote JavaScript execution or injection
  • synchronous XMLHttpRequests
  • obfuscated code
  • binary components or executables
  • inclusion of third-party software
  • errors generated in the Browser Console
  • memory leaks
  • possible conflicts with other add-ons
  • application start-up or page load performance degradation

For information on how to avoid these problems, please see our available documentation. Some of these practices, such as binary or obfuscated code, are allowed under certain conditions outlined below.

Many of the above restrictions are tested automatically by an extension scanner that will flag suspicious add-ons for editor review. You can read more about this scanner in the Validation Help document.

If the add-on is site-specific, it is recommended that a test account is provided for use during the review process. Additionally, including detailed testing instructions will allow an editor to better understand how the add-on functions and expedite the testing process. This information can be placed in the Notes to Reviewer field when editing a version in the Developer Hub.

After the Review

Once an add-on is granted full review, it will immediately be available in the gallery, showing in browse and search results with a warning-free install button. All features, including voluntary contributions and beta channels will be available.

Subsequent versions of the add-on will automatically be placed in the full review queue. Until the review is completed, the new version will only be displayed on the Version History page of the add-on. Once reviewed, the version will be updated across the site and deployed through the automatic update service.

If a version does not meet the criteria for full review, it can either be granted preliminary review or disabled if there is a security concern. The author will receive an email explaining the action taken and how to fix it. In most cases, the developer can simply fix the problem and re-submit for full review.

Preliminary Review

Preliminary reviews are appropriate for experimental add-ons and provide a way to get user testing and feedback without going through the more thorough review process.

Testing Methods

When performing a preliminary review, editors will review the source code for security issues and major policy violations, but will not install the add-on to test functionality in most cases. Preliminary review will be granted unless a security vulnerability or major policy violation is discovered.

After the Review

Once preliminary review is granted, the add-on will be immediately available in the gallery, showing in browse and search results but ranked lower than fully-reviewed add-ons. Install buttons will have caution stripes and a notice that the add-on is experimental and not fully reviewed by Mozilla, though no click-through is required. Additionally, these add-ons cannot use the voluntary contributions and beta channel features.

After being granted preliminary review, Mozilla may later revoke the review if other serious problems are reported to us by users.

Subsequent versions of the add-on will automatically be placed in the preliminary review queue. Until the review is completed, the new version will only be displayed on the Version History page of the add-on. Once reviewed, the version will be updated across the site and deployed through the automatic update service.

Policies on Specific Add-on Practices

Prohibited Add-ons

The following add-ons are not permitted in any form:

  • Add-ons that embed known spyware or malware
  • Illegal and criminal add-ons, such as click fraud generators, warez download and directory assistants, child pornography finders, etc.
  • Add-ons that violate the Acceptable Use Policy for Mozilla services
  • Add-ons whose main purpose is to facilitate access to pornographic material, or include references to this material in their descriptions
  • Add-ons that, upon installation, auto-install or launch installers of non-Firefox software
  • Add-ons that provide their own update mechanism for code or search engines
  • Add-ons that make changes to web content in ways that are non-obvious or difficult to trace by their users
  • Add-ons that snoop on or intercept the network traffic of other users

Changing of Defaults and Unexpected Features

Surprises can be appropriate in many situations, but they are not welcome when user security, privacy, and control are at stake. It is extremely important to be as transparent as possible when submitting an add-on for hosting on this site. A Mozilla user should be able to easily discern what the functionality of an add-on is and not be presented with unexpected experiences post-install.

Whenever an add-on includes any unexpected feature that:

  • compromises user privacy or security (like sending data to third parties),
  • changes default settings like the homepage or search engine, or
  • changes settings or features in other add-ons or deactivates them altogether

the features must adhere to the following requirements:

  • The add-on description must clearly state what changes the add-on makes.
  • All changes must be opt-in, meaning the user must take non-default action to enact the change.
  • The opt-in dialog must clearly state the name of the add-on requesting the change.
  • Uninstalling the add-on must restore the user's original settings if they were changed.
  • Any changes or additions to browser interfaces or web content must clearly indicate that the add-on is responsible. This means, for instance, that any content added to web pages must clearly display the add-on name, and acknowledge it as their source.

For the purposes of this requirement, any features which are not directly related to the add-on's primary function are considered unexpected.

These are minimum requirements and not a guarantee that the add-on will be approved. This section applies to all add-ons hosted on the site, including preliminarily reviewed add-ons.

Private Browsing Mode

Add-ons that store or otherwise handle browsing data must support Private Browsing Mode. During a Private Browsing session, no browsing data can be written to disk, and all of this data must be cleared when Firefox quits or the Private Browsing session ends.

Binary Components & Obfuscated Code

Add-ons may contain binary, obfuscated and minified source code, but Mozilla must be allowed to review a copy of the human-readable source code of each version of an add-on submitted for review.

If an add-on contains binary or obfuscated source code, the author will receive a message when the add-on is reviewed indicating whom to contact at Mozilla to coordinate review of the source code. This code will be reviewed by an administrator and will not be shared or redistributed in any way. The code will only be used for the purpose of reviewing the add-on.

If your add-on contains binary or obfuscated code that you don't own or can't get the source code for, you may contact us for information on how to proceed.

Last updated: April 23rd, 2015

What happens after your add-on is submitted? Learn about how our Editors review submissions.

Document Tags and Contributors

 Contributors to this page: wbamberg, Jorge.villalobos, kmaglione
 Last updated by: wbamberg,