Your Search Results

    AMO Review Policies

    In order to ensure all add-ons hosted in our gallery are safe for users to install, Mozilla will begin requiring 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.

    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.

    We aim to perform full reviews in under 10 days, though most add-ons are reviewed in much less time.

    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 — the most common violation. 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
    • remote XUL
    • synchronous XMLHttpRequests
    • obfuscated code
    • binary components or executables
    • inclusion of third-party software
    • errors generated in the Error 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 How-to Library. 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 longer, more thorough review process. We aim to complete these reviews in under 3 days.

    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 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
    • Conduit-based toolbars without explicit pre-approval

    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 restores the user's original settings if they were changed.

    *Unexpected features are those that are unrelated to the add-on's primary function.

    These features cannot be introduced into an update of a fully-reviewed add-on; the opt-in change process must be part of the initial review.

    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. These add-ons are ineligible for preliminary review and must choose the full review process.

    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: January 13, 2011

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

    Document Tags and Contributors

    Contributors to this page: kmaglione
    Last updated by: kmaglione,
    Hide Sidebar