Marketplace review criteria

Here are Mozilla's expectations of what app review is and is not:

• Criteria will be applied in a fair, compassionate, and consistent manner. The app review process is not intended to be a gatekeeper, but rather a trusted touch point that provides feedback to help developers be more successful.
• Reviewers are not a QA team! During the review process, someone will look over the app manifest and spend a few minutes exercising the application as a normal user would.
• If an app fails review, the developer will be given a clear explanation of the problems found, steps to reproduce, and where possible, the reviewer should point the developer in the right direction by providing links to relevant supporting documentation or make recommendations on what changes need to be made.
• Reviewers make no judgment on how an app looks, only on how the app works. For example, an app with a paragraph of red text on an orange background wouldn’t be rejected because it’s ugly, but might be rejected if it’s not readable.
• We always give developers the benefit of the doubt. If unsure whether an app should be rejected, reviewers will ask questions before issuing a rejection. Apps will not be (knowingly) rejected due to platform issues that are outside of the developer's control; however we may withhold approval if we can't get the app to work.

Security

Full details of the app security architecture are available here: https://wiki.mozilla.org/Apps/Security

• The app manifest must be served from the same origin as the app.
• The app manifest must be served a Content-Type header of application/x-web-app-manifest+json.
• Apps should not use redirects or iframes to load content that the developer isn't authorized to use.
• Requested permissions must be specified in the app manifest with description of why the permission is needed.
• Apps of type privileged will undergo further checks, including code review, due to the potential for malicious activity and user data loss with privileged APIs.
• The Content-Security-Policy (CSP) defined in the app's manifest determines what the app's code can do.  The default, if unspecified, for non-privileged apps is the same as any website; apps of type privileged have a more restrictive default.  The validation report created on submission to Firefox Marketplace will indicate potential CSP violations in your app - though beware false-positives and usage in parts of 3rd party libraries you don't use.

Privacy

• The developer must link to a privacy policy during submission, but there are no requirements for the format and content of this privacy policy. Feel free to use our privacy policy template. Also take a look at our privacy policy guidelines.

Content

• Any apps that violate our Content Guidelines below are not allowed. If you think you have an edge case, please ask the review team for clarification, even if the app isn’t yet ready to be submitted. We want to help you stay on the right track, rather than invest development time into content that will be rejected.
• Starting in January 2014, all apps must receive a rating from the International Age Rating Coalition (IARC).  To obtain this rating, we'll direct you to a brief questionnaire during the submission process, and you'll receive the rating immediately.  More information about the rating process is available here.
• Screenshots and descriptions submitted to the Firefox Marketplace must accurately represent the app.  You may include 1-2 "marketing" images that show compatibility, compare features, or otherwise generate interest, but there must be at least one screenshot of the app in action, so that users can preview what they're actually getting.  If one of your screenshots is a splash or launch screen, you must also include a screenshot of the functional part of your application.
• In the app manifest, the locale keys should match the localizations that your app supports. By providing a locale key in Polish, users will expect your app to be available in that language.
• The app icon should follow the Firefox OS app icons style guide. Only a 128 x 128 icon is mandatory, but we also recommend a 512 x 512 icon too (for more details, see Icon implementation for apps.) Note that icons can be round, rounded corner square, or square, as per the style guide.

Content guidelines

This list describes types of content that are inappropriate for the Firefox Marketplace. This list is illustrative, not definitive, and may be updated. If an application is found to be in violation of these content guidelines, Mozilla has the right to immediately remove the application from the Firefox Marketplace.

• No obscene pornographic materials, or graphic depictions of sexuality or violence.
• No content that infringes anyone’s rights, including intellectual property or other proprietary rights or rights of privacy or publicity.
• No content that is designed to harm Mozilla or users (such as malicious code, viruses, spyware or malware).
• No content that is illegal or promotes illegal activities.
• No content that is deceptive, misleading, fraudulent or is designed to phish or perform other identity theft.
• No content that promotes gambling.
• No content that engages in the advertisement of illegal or controlled products or services.
• No content that exploits children.
• No content that degrades, intimidates, incites violence against, or encourages prejudicial action against someone or a group based on age, gender, race, ethnicity, national origin, religion, sexual orientation, disability, religion, geographic location or other protected category or constitutes hate speech.
• No content that misleads a user into making a purchasing decision.

Functionality

• The reviewer must be able to perform the app's primary advertised features. Cosmetic flaws and minor inconveniences will be reported to the developer, but will not prevent an app from being approved.
• The app must not compromise system performance or stability.

Usability

• The developer must make a reasonable attempt to optimize app layout for the target platform. The intent of this requirement is to catch obvious failures, such as:
  • An app submitted for mobile that's obviously a desktop site.
  • An app that very obviously doesn't stretch to fill available screen space (imagine a 320x480 app that only takes up the top corner on a tablet, with the rest of the screen blank. This is surely not intended!)
• The app must implement its own method of navigation and not rely on browser chrome or a hardware back button, which will not be present on every device.
  • For example, an app will be rejected if the reviewer navigates somewhere within the app and isn't able to navigate back. Apps are NOT required to implement a button bar common to native apps.
  • On Firefox OS v1.1 and greater, you can add the chrome manifest property to add minimal navigation controls.
• Navigation elements, such as buttons and links, must be easy to click or tap.

Blocklisting policy

We hope we never have to use it, but we do reserve the right to remove ("blocklist") any published app that is later found to violate any security, privacy, or content requirements, or apps that seriously degrade system or network performance. Developers will be informed of the situation before an app is blocklisted, will be assumed to be a good citizen unless we have specific evidence otherwise, and will receive full assistance from the app review team to communicate what's going on and get the problem resolved. Specific examples of situations where blocklisting is warranted include:

• Phishing
• Spamming
• Changing content from Puppy Pictures v1.0 to Brutal Violence v1.0 (without updating the content rating)
• Severe misbehavior of app for a large percentage of users — degrading phone performance, causing reboots, causing user data loss, etc. where users can't tell that it's because of the app and where it isn't solved by rebooting the device.
• An app being used for attacks on the network, such as a distributed denial of service (DDOS).

More information

The following resources provide more information on the review process and app reviewers:

• Reviewers test criteria — this page describes the tests that app reviewers will perform on your apps
• App reviewers — how to contact the app review team and get involved to review apps