Personal tools

Blocklisting

From MozillaWiki

Jump to: navigation, search

Blocklisting is the ability to disable errant add-ons, plugins, and other third-party software for Firefox users. For graphics drivers, please see this policy.

Contents

Blocklisting Policy

No matter how secure, fast, or stable Firefox is, one encounter with bad third-party software can cause permanent damage to Firefox, your computer, or worse. That's why Mozilla considers it our responsibility to help users avoid those encounters. One tool we use to do that is blocking dangerous third-party add-ons, plugins, and DLLs from running in Firefox.

A High Bar

Blocking third-party software is a sensitive issue that must be carefully considered in every case. We must be certain that the issue at hand is so great that it outweighs the user's choice to install the software, the utility it provides, and the vendor's freedom to distribute and control their software.

Block Conditions

Blocklisting conditions are detailed in the Add-on Guidelines. However, the severity of the situation and the impact of doing the block will always be a significant factors in the decision. Acceptable reasons for blocking software include:

  • Critical security vulnerabilities.
  • A history of security vulnerabilities.
  • High crash volume.
  • Malicious in nature.
  • Severe performance impact (e.g. adds more than 75% to start-up time).
  • Severe bugs that unintentionally affect core Firefox features.
Note: The above conditions assume users have chosen to install the add-on or software in question. If the software is installed without user consent, the bar is significantly lower to blocking for the above and other reasons.

The following are not reasons to block an add-on:

  • Inclusion of advertisements or other "spyware" tactics, unless users did not choose to install the software or were not made aware of the offending functionality.
  • Intentional significant changes to or breakage of core Firefox features, unless users did not choose to install the software or were not made aware of the offending functionality.
  • At request of the vendor/developer, except in extreme circumstances.

Block Severity

There are several levels of blocking available to add-ons and plugins.

  • Hard-blocks disable an add-on and do not allow the user to enable it or override the block. This should only be used in cases where an add-on is malicious.
  • Soft-blocks disable an extension by default, but allow the user to override and continue to use the add-on. This is the preferred block type for extensions which are not malicious.
  • Click-to-activate blocks disable a plugin by default, but allow the user to enable the plugin for particular sites. This is the preferred block type for plugins which are not malicious.

Vendor Outreach and Block Ranges

Software should not be blocklisted without a reasonable attempt to contact the vendor/developer beforehand to alert them of the block and request a fixed version. If a fixed version will be provided in an adequate timeframe (0-3 calendar days), the block should be held so that users can update to the fixed version.

Block ranges should be as specific as possible to only target the offending versions in the affected application versions.

How to request a block

  1. Read the policy above and be sure your request meets the criteria
  2. File a bug using the appropriate request form and filling in all requested details:
  3. The request will follow the process outlined below until resolved.

If there is an existing bug to be morphed into a blocklist request, make sure the required information (indicated in the request template) is included in the bug before moving it to addons.mozilla.org :: Blocklisting. Please do not move bugs to Blocklisting until they are ready for blocklist consideration.

Blocklisting Process

  1. A request is filed with detailed information as described above
  2. The vendor or developer of the item in question will be contacted, directed to the bug, and encouraged to fix the issue.
  3. The request will be discussed in the bug among the Firefox and add-ons product drivers and other interested parties to agree upon validity of the request, block ranges, and severity
  4. The agreed-upon block range will be placed on the blocklist staging server for anyone to help test
  5. Once the tests have finished running without errors, the block will be pushed to production

What users will see

The blocklist UI hasn't changed since Firefox 4, so the screenshots below are still relevant.

Add-on block flow from a user perspective
Plugin block from a user perspective

Click-to-Play blocklisting was introduced in Firefox 17.

Click-to-Play plugin block from a user perspective

More Information