Join MDN and developers like you at Mozilla's View Source conference, 12-14 September in Berlin, Germany. Learn more at https://viewsourceconf.org

This article needs a technical review. How you can help.

This article describes the set of requirements a social provider must meet in order to be exposed to the Firefox user base, as well as criteria that could result in a social provider being blacklisted from exposure. These requirements are designed to balance the needs of both developers and users of social apps. Developers want fair, consistent requirements that they can trust to build a business on.  On the other hand, users want assurance that apps are safe and that the app will do what it says it'll do.

If a social provider is distributed via the add-on preferences menu, a review will be required prior to listing.

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

  • Criteria will be applied in a fair and consistent manner. The review process is designed to ensure that quality of Firefox experience is maintained for Firefox users while also helping developers be more successful.
  • Reviewers are not a QA team! During the review process, someone will look over the social provider and spend a few minutes exercising the application as a normal user would.
  • If a provider fails review, the developer will be given a clear explanation of the problems found, steps to reproduce the issue, and suggestions on how to improve the experience.
  • We always give developers the benefit of the doubt. If unsure whether a provider should be rejected, reviewers will ask questions before issuing a rejection. Social providers 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 provider to work.

Security

Full details of the socialapi security architecture are available here: TODO

  • The social provider content must all be served from the same domain.

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 social providers that violate our Content Guidelines will not be made available through any Mozilla resource.
  • Violation of our guidelines, whether listed by Mozilla or not, may result in the social provider being blacklisted.

Content Guidelines

This list describes types of content that are inappropriate for exposure within Firefox. This list may be updated. If a social provider is found to be in violation of these content guidelines, Mozilla will immediately remove the provider from Firefox. 

  • 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 other 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.

Quality

We want to see your service provider succeed and be a great part of the Firefox experience. Your provider will integrate into Firefox in a way that general web pages do not; it will run over extended periods of time, and is displayed differently than a normal web page. The way that users will interact with your provider is going to be different. As such, we have a few recommendations for areas to focus your testing on to ensure you deliver a consistent, stable, and valuable experience:

  • Ensure your functionality works as designed and fits in the constraints of the service's UI components (sidebar, panels, etc.) Test all your UI elements and make sure they are designed for these panels. For example, loading a normal web page into a panel should be avoided as it will not present the user with a way to "go back" to the previous page.
  • Ensure that your branding appears appropriately and integrates well where we use it within the Firefox UI (e.g., Toolbar button, menus, Add-ons Manager, installation panels, etc.)
  • Ensure your manifest contains all the necessary data to appear correctly in the Add-ons Manager, and to ensure a consistent activation and management experience. For example, clicking on your entry in the Add-ons Manager should display details about your service.
  • Ensure that your activation page works correctly for every version of Firefox you wish to support. Note that activation has changed between Firefox 21 and 22. You can uninstall, disable, and enable your provider from the Add-ons Manager.
  • Watch your memory use! Unlike normal web pages, your provider may be running in the browser for extended periods of time. You can load the about:memory?verbose and about:compartments pages to examine memory usage and ensure that your pages are released when the user switches between providers. Try to "burn-in" for a period of time, a few days if possible, to make sure you do not leak memory over time. Is your memory usage released when you switch to a different provider? What does your memory usage look like with a lot of Firefox tabs and windows open for extended periods of time? How well does your service perform a high volume of activity?
  • Does your provider recover well if Firefox crashes? You can use the CrashMe addon to test this.
  • If you need further guidance in your testing, feel free to contact our SocialAPI QA Engineer, Anthony Hughes.

Blacklisting policy

We hope we never have to use it, but we do reserve the right to remove ("blacklist") any published social provider that is found to violate any security, privacy, or content requirements, or social providers that seriously degrade system or network performance. Developers will be informed of the situation before a social provider is blacklisted and will receive assistance from the review team to communicate what's going on to get the problem resolved. Specific examples of situations where blacklisting is warranted include:

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

Document Tags and Contributors

Tags: 
 Contributors to this page: Sheppy, ajsb85, kscarfone, Ashughes, ncubeeight.com, Mixedpuppy
 Last updated by: Sheppy,