Sandbox Review System
New Add-ons
New add-ons submitted to the site are marked as experimental by default, requiring the user to indicate their understanding that the add-on has not been reviewed by an Editor and may harm their computer. After an experimental add-on is installed, no updates will be sent to the user until the add-on is reviewed and public.
Authors of experimental add-ons can request Editor review by nominating their add-on for public status through the Developer Tools provided. The add-on will then go into a queue of other nominated add-ons, awaiting review based on the criteria listed below and in the Add-on Submission policy.
Testing Methods & Common Issues
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.
All add-on submissions that wish to be public must be reviewed by an Editor. As part of this process, an Editor will review your add-on's source code and any changes that have been made since the last version, if applicable. During the review, the Editor will look for common issues, including:
- JavaScript namespace pollution - the most common reason for being retained in the sandbox. Be sure to wrap your loose variables.
- 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
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.
All add-ons are tested in a virtual machine to allow the editor to install the add-on and test the user experience without damaging their systems. 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 your add-on is site specific, it is recommended that you provide a test account for use during the review process. In addition, including detailed testing instructions will allow an editor to better understand how your add-on functions and expedite the testing process.
Prohibited Add-ons
Editors will also check for add-ons which are not allowed on this site, even in experimental form. These include:
- Conduit-based toolbars without explicit pre-approval
- 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 include pornographic material or seem to be developed purely as a vector to inject advertisements for pornography, warez, etc.
- Add-ons that, upon installation, auto-install or launch installers of non-Firefox software
- Add-ons that provide their own update mechanism for chrome-privileged resources
Binary Components & Obfuscated Code
Add-ons may contain binary or obfuscated source code, but Mozilla must be allowed to review a copy of the human-readable source code of each version submitted for review.
If your add-on contains binary or obfuscated source code, you will receive a message from an Editor when they review your add-on indicating whom you should contact at Mozilla to coordinate review of the source code. Once Mozilla has received and reviewed your source code, approval will be given to an Editor to review the non-binary aspects of your add-on to determine if it's ready for public status.
After the Review
After an Editor has reviewed your add-on, a decision will be made about your add-on's acceptance into public, non-experimental status. There are several possible outcomes of this review:
The add-on can be pushed public. If your add-on met all of the criteria and the Editor feels it's ready for primetime, the add-on may be made public and users will be able to download the add-on without restrictions and receive updates after installation. You will receive an email informing you of this status change. Only the latest version of your add-on will be pushed public; older versions that were not reviewed will remain in the sandbox. New versions to public add-ons still require Editor review, as described below.
The add-on can be retained in the sandbox. If there were some problems with your add-on, it will be held in the sandbox and you will receive an email with the Editor's comments. After addressing these concerns, you may re-nominate your add-on for review. Editors will check to see if their previous requests were addressed, so re-nominating your add-on without changes will likely hurt your add-on's chances of being public.
The Editor may request additional information from you. If the Editor needs additional information about your add-on in order to process the review, he or she will request information from the developers, which will send an email with information on how to respond with the requested details.
The add-on may be escalated for super-review. If your add-on has potential copyright/trademark violations, has binary or obfuscated components, or has other issues that need special attention, the Editor may request that a Senior Editor or Administrator look into their concerns. This does not alter the status or position in the queue of your add-on, but the action the super-reviewer takes likely will.
If you have any questions about your add-on's review, you may contact the Editors. For best results, please include the site email you're responding to in your message, or at least information about your add-on.
Updates to Public Add-ons
New versions of public add-ons are kept in the sandbox but automatically added to a queue for Editor review. An Editor will review your new version, focusing on the changes made since the last version. The potential outcomes of the review are the same as for new add-ons listed above.
Last updated: October 8, 2009
