- 1 Review Decision Guidelines
- 1.1 Completing the Review
- 1.2 Examples
Review Decision Guidelines
This page provides guidance to support reviewers in making consistent review decisions based on our Review Policies. In addition, it explains how to best communicate with the developer when conducting add-on reviews. It is a supplement to our Reviewer Guide.
Completing the Review
Add-ons must be reviewed completely, noting issues in the review comments field as you find them. We want to avoid sending multiple partial reviews to developers and give them an opportunity to address all policy violations at once in their next submission.
In the following sections we will explain how canned responses should be used for the issues you find and guide you through the review actions. Finally, you are guided on how to respond if you find issues that cover multiple review actions.
Use of Canned Responses
To ensure developers receive consistent, actionable responses from the review team, AMO makes use of canned responses that cover many of our policy issues.
If no canned response is available for the issue you have found, you may write a custom response specific to the situation. Keep in mind that when writing a response to the developer, all responses must be in line with our policies. This is especially true when using custom responses. If you are unsure your response conforms with the policy, an admin reviewer will be able to assist you.
In addition, we’d love to hear from you believe the response is useful to add to the official list of canned responses. We would much prefer that reviewers use the canned responses to ensure consistent replies, therefore adding new canned responses could be very useful.
In some cases the developer responds to your review, either via email or by uploading a new version, making clear that they did not fully understand how to act upon the canned response. In such cases, sending the same canned response again will not help resolve the situation. Here it makes sense to explain the policy issue in a different, possibly more verbose way, using your own words.
While the review comments field is free-form, we have a de-facto standard approach that lists the review issues in numbered lists each with a headline. Note that your text is inserted into an email that handles all the formalities, you should not need to begin your review with “Dear Developer” or sign with your name.
Commonly, we use a numbered list item for each review issue, along with headings to separate sections as needed. Here is an example review text to give you an idea:
This add-on didn't pass review because of the following problems: 1) We don't allow add-ons to use remote scripts because they can create serious security vulnerabilities. We also need to review all add-on code, and this makes it much more difficult. Please insert those scripts locally from your add-on code. - pages/inject.html line 8 In addition, the following information is required to complete the review: 1) Please provide us with detailed information on how to test this add-on. If authentication to a website is necessary, give us a test username and password to facilitate our work. This can be provided in the Whiteboard field, which can be found in the Edit Listing page under the Technical Details section. This information is only available to reviewers.
With a reviewer reply, you can convey information to the developer. You can use this action to answer questions the developer may have about your review. All communication between developers and reviewers is captured on the review history page.
If you need the developer to take action, please make use of a delayed rejection instead. Doing so makes sure the correct email template is used and AMO knows to remind us when the developer has not responded to the request.
If you are unsure how to answer a response from a developer, or the developer is disputing your review, please get in touch with admins to make sure the developer receives a reply. Involving a second reviewer to confirm your review can also be helpful if the developer does not want to accept your reasoning.
If the add-on has minor policy issues that don’t require an immediate rejection, the delayed rejection action should be used. AMO will then reach out to the developer, asking them to resolve the issue within the requested time frame. If the developer fails to comply, the marked versions will be rejected.
To use a delayed rejection, select “Reject Multiple Versions”, and select the option to delay the rejection. All versions you have selected will be rejected after the time passes. You will need to determine when the developer started to use the code in question, so you can determine which versions to reject. Generally it is sufficient to check back until the last reviewed version, for example using a bisection approach. If the issue also exists in that last reviewed version, you will need to track back further.
If the developer responds, you will receive email with the developer’s response. At this time you should return to the review page to continue reviewing using the information you received from the developer. Note that the developer may follow up with further questions about the information you are requesting. In all cases, please answer developers in a timely manner (within 2 days). If you are answering questions that require no further action or response, please use the “reviewer reply” action.
If you cannot complete the review after the developer has provided information, please at least check if the developer has provided the information you have requested and leave a comment on the version so that other reviewers can continue your work.
Similarly, if you come across an add-on where the developer has provided information but the original reviewer has not followed up within that time, you are welcome to complete the review. The original reviewer may have prior knowledge that would speed up the review, but at the same time we do not want to keep developers waiting.
Rejecting an add-on’s versions can mean anything from showing an outdated version of the add-on to completely hiding the listing from addons.mozilla.org (when rejecting all public versions). Especially in the post-review model where add-ons are reviewed after initial approval, a rejection can lead to frustration from the developer. At the same time, we need to ensure that there are no policy violations that threaten user security or privacy.
Our general policy is to only reject immediately when necessary. Rejection is necessary when an add-on has security or privacy issues, doesn't meet our content policies, or fits one of the examples described later on.
When rejecting the add-on, you will need to determine all affected versions using the same approach as for a delayed rejection. You can then select the option to reject immediately.
In case of a rejection, developers may have questions on how to best resolve the policy issues, or if they have trouble understanding the message. Similar to the delayed rejection, please answer in a timely manner using the reviewer reply feature.
Multiple Categories of Issues
If you find multiple issues within the add-on where there are both delayed and immediate rejections, you may reject the add-on immediately. Please make sure to clearly separate information needed to complete the review from rejection reasons. An example on how this can be done is shown above.
Using the “Request Super Review” action will put the add-on into the admin queue. There are few select cases where this would occur, please see the examples below for further details. If you have a concern that needs immediate admin attention, please get in touch with the admins via the channel described in the Escalation section, as there are no specific notifications to admins when you request super review.
There are certain cases that are severe enough that the reviewer actions on addons.mozilla.org are not sufficient and you must inform the admin team. This is especially true for reporting child pornography, add-ons containing abusive functionality or being of malicious nature that must be blocked in accordance with our blocking policy.
In such cases, you should contact the admin team via email at amo-admins [at] mozilla [dot] com. You can find more examples on when to escalate later on this page.
The following sections show a few common examples on how to respond to certain policy violations. Please note however these are merely examples intended to convey the intent we have with the policies. It should not be considered a complete list of review decisions.
|The add-on sends all visited URLs to a third party service without adhering to the no surprises requirements.||Reject Immediately|
|The add-on uses means such as webRequest to circumvent the permission prompts for new tab page, homepage or search engine changes.||Reject Immediately|
|The add-on changes browsing behavior inhibiting user actions, such as closing or hiding about:addons or other special pages when opened.||Escalate|
|The add-on unexpectedly makes use of redirection to block the user from visiting certain sites without providing the user an option to circumvent the redirection. The add-on is violating the no surprises policy.||Reject Immediately|
|The add-on silently modifies web content, for example by exchanging words and images, or adding content. This feature is not part of the core functionality and is not described to the user in any way.||Delayed Reject|
| The add-on describes itself as e.g. “VPN Service”, while at the same time it also provides something completely unrelated to the add-on’s core function, such as altering the new tab page and providing affiliate search results.
The additional features are not stated in the description, and there is no opt-in for the additional feature, violating the no surprises requirements.
|An add-on provides UI to allow the user to make a no surprises choice, but the default action is to accept the choice (hence not an opt-in).||Delayed Reject|
|An add-on makes use of an “unexpected” feature as per no-surprises policy, but fails to indicate so in the add-on description.||Delayed Reject|
The content review policies are detailed in separate guidelines. Here are a few select examples for the content policy:
|Sexual Content: An add-on contains obscene or pornographic images in the icon, screenshots, or anywhere within the add-on UI.||Reject Immediately|
|Sexual Content: An add-on contains images of potential or actual child pornography.||Reject and Escalate Immediately|
| Hate Speech: The add-on listing or UI attacks a person or group based on the attributes described in the acceptable use policy.
If you are unsure certain phrasing is acceptable or not, please contact an admin.
|Spam: The add-on clearly has the sole purpose of linking to a product or website and at the same time does not offer any functionality (e.g. “WATCH THIS MOVIE ONLINE”).||Reject Immediately|
|Spam: The listing contains a large amount of words and links unrelated to the add-on’s functionality clearly intending to increase SEO rating.||Reject Immediately|
|Trademarks: The add-on is named “Mozilla Frobnicator”, “Firefox Spice Dispenser” or similar, instead of “Frobnicator for Mozilla” or “Spice Dispenser for Firefox”.||Reject Immediately|
|Trademarks: The add-on is related to Pocket, and is named “Pocket Reader” or similar, instead of “Reader for Pocket”.||Reject Immediately|
|The add-on’s code, functionality or service used indicates that payment is required to use the core functionality of the add-on but the developer has not selected this option in the listing.||Delayed Reject|
| The add-on only functions within a closed environment, such as only for employees of a specific company (“internal or private use”).
If the add-on has just been submitted to AMO, rejecting immediately is acceptable. Otherwise, delaying the rejection gives developers time to migrate their services to point to the new self-hosted location.
| Users can only sign up to the service using a “contact us” link on the website. There is no apparent web sign-up process (“only accessible to a closed user group”).
(Note that especially on sites with foreign languages, maybe you just missed it. Best to ask the developer to provide information on how a user would sign up. If they can’t provide the information or confirm there is no web sign-up process, the add-on can be rejected).
|The add-on is clearly a fork of another add-on, while not providing a significant difference in functionality or code. (This should be a joint decision, we want to make sure not to block creativity by being too strict on “significant difference”)||Request Super Review|
|The add-on listing is well described, but requires knowledge of the specific system being used in combination with the add-on.||Approve|
|The add-on advertises functionality as part of the extension, that is provided completely by a website or third party application. The add-on merely opens the website.||Reject Immediately|
|The add-on advertises itself as a companion for a website or third party application, and offers functionality to provide data to the website. The main functionality is provided by the add-on.||Approve|
|The add-on requires use of an external service that is only available with login credentials, and the developer has not provided them.||Delayed Reject|
| The add-on contains obfuscated code (as opposed to minified code).
(Please see the Source Code Submission page on how to differentiate obfuscated and minified code. Not everything that is unreadable is obfuscated.)
|The add-on contains obfuscated code that seems to intentionally violate the policy.||Reject Immediately and Escalate|
|The add-on contains transpiled, minified or otherwise machine-generated code and has not provided source code.||Delayed Reject|
|The add-on requests additional permissions that are not required for the add-on to function.||Delayed Reject|
|The add-on requests additional permissions that are not required for the add-on to function. The developer argues they will need them in a future update.||Delayed Reject|
| The add-on loads and executes remote code.
If there is reason to believe the add-on is intentionally loading remote code, please escalate to a block.
|Reject Immediately or Escalate|
| The add-on uses a http channel to exchange information, while it is possible for the developer to use https.
If the developer has control over the remote infrastructure and can enable servers to use https, you can reject as they need to take this step. If the choice of http is outside of the developers hands, you may approve.
| The add-on makes use of http as a result of the user entering an url that uses http.
Note: If such URLs can be upgraded to https, the developer should make reasonable effort to inform the user about an insecure connection and attempt to upgrade to https.
|The add-on contains a large amount of duplicate files, or files not loaded by the add-on.||Delayed Reject|
|There is a noticeable impact on performance, for example opening a new tab takes very long because the new tab page is very resource-intensive.||Reject Immediately|
| The developer has not provided links to third party libraries, the links do not point to the original maintainer’s website, the library does not match the original checksum from the developer.
The developer should be asked to provide the link where they received the library as per the Third Party Libraries Usage guidelines. If there is any indication that the modifications are intentionally violating policy, please reject immediately and escalate.
|The add-on sets a new tab page that redirects to a remote page.||Reject Immediately|
Data Disclosure, Collection and Management
|After code review it is clear that the add-on exchanges data with a third party service, but the add-on description and summary do not include a summary of the information collected.||Delayed Reject|
|The add-on provides a search box for Google, Bing, Amazon etc. and search requests go through another website.||Reject Immediately|
|The add-on collects tab urls and is sending them as part of a request that doesn’t relate to actions based on the URL. This is considered ancillary data collection.||Reject Immediately|
|The add-on collects personal data, technical data, or user interaction data, and does not have a consent prompt when the add-on is first run (e.g. installed).||Reject Immediately|
|The add-on has a consent prompt, but it does not describe the data being collected||Delayed Reject|
|The add-on has a consent prompt that makes use of dark patterns to entice the user to accept.||Delayed Reject|
|The main purpose of the add-on is to collect and analyze form data. Therefore, the add-on collects personal data such as the name and email of the user and sends the data to the service, but without an opt-in for personal data.||Reject Immediately|
|An add-on collects all visited browser URLs without notice, as part of a feature that does not relate to the primary functionality of the add-on.||Reject Immediately|
| The add-on exchanges data via native messaging that does not belong to the primary functionality of the add-on and fails to adhere to the no surprises requirements.
In severe cases, such as when sensitive data is being exchanged, please reject immediately.
|The consent experience only offers the option to accept the data collection.||Delayed Reject|
| The consent experience offers the option to accept or uninstall, but the main functionality of the add-on will technically work without this type of data collection.
If the developer argues that collecting the data is required for business purposes, e.g. to maintain the add-on, this does not warrant an accept or uninstall behavior.
|The add-on collects technical data and does not provide a way for the user to disable this type of data collection.||Delayed Reject|
|The add-on combines both personal and technical data into one option and does not provide a way to control them separately.||Delayed Reject|
Additional Privacy Protocols
|The add-on passes on cookies or other user-sensitive information to a native messaging application.||Reject immediately|
|The add-on stores information about tabs, but fails to exclude storing information from private browsing mode tabs.||Delayed Reject|
Monetization follows the same data disclosure policies as for other data and includes a few extra provisions to set user expectations. We define monetization as a feature of the add-on that results in a potential monetary benefit for the developer.
|The add-on monetizes by injecting ads into web pages, but fails to identify the content as belonging to the add-on.||Delayed Reject|
|The add-on includes a crypto-mining function that mines coins in the background for the profit of the developer.||Reject Immediately|
|The add-on contains a crypto-mining function for the profit of the user (this is still a performance issue).||Reject Immediately|
|The add-on shows information about crypto coins by querying a web service for information (this is not mining).||Approve|
|The add-on changes all Amazon/Yahoo/etc. links on web pages to add affiliate tags to profit the developer.||Reject Immediately|
|The add-on has links that include affiliate tags within the browser popup of the add-on.||Approve|
Security, Compliance & Blocking
|The add-on injects remote data into an extension page or web page using innerHTML or other methods without prior sanitation.||Reject Immediately|
|The add-on makes use of React’s dangerouslySetInnerHTML with remote unsanitized data.||Reject Immediately|
|The add-on makes use of remote CSS scripts, which can cause security vulnerabilities in combination with libraries such as React and Angular.||Reject Immediately|
|The add-on seems to be intentionally violating our policies, such as collecting a cryptocurrency private key and sending it to a remote server.||Escalate|