Blocklisting/Admin

Blocklist entries are added through the Kinto Web Administration tool. Only authorized members of the Add-ons Team can manipulate the blocklist.

Login via the Kinto admin page (VPN connection is required)
Authentication method: Basic Auth
Username: jdoe@mozilla.com. This is your full LDAP email address.
Password: your_ldap_password

All blocks are first created in the staging bucket, are later moved to the blocklist-preview bucket for testing and review, and then deployed to the final blocklists bucket.

Extension blocks

Staging

Click on staging bucket :: addons
Click on "Create" (or edit/delete icons if you need to change an existing record)
Enter in the appropriate fields. Example below (see the current list¹ for more examples)
- Keep the Enabled checkbox checked.
- You'll generally want to enter the add-on ID, version range (0 to * to block all versions), and severity of the block.
- The OS can be set to any of these, but OS-specific blocks are rarely needed.
- The Target Application is only necessary for blocks that only target specific applications, which should also be very rare.
- The Preferences fields are used in case the add-on changed important Firefox preferences that need to be reset.
- The name, why, who, and bug fields are shown to end users, so they need to be clear as to why the block was put in place and what options are available. If the extension being blocked is malware, add " (malware)" at the end of the name. bug should be a Bugzilla URL.

¹ Data for the blocklist can be found in the public JSON endpoint, or on addons.mozilla.org.

Testing

JSON Example

{
   "guid":"{de71f09a-3342-48c5-95c1-4b0f17567554}",
   "blockID":"i1493",
   "enabled":true,
   "last_modified":1484867614757,
   "details":{
      "who":"All users who have this add-on installed.",
      "created":"2017-01-12T22:17:59Z",
      "bug":"https://bugzilla.mozilla.org/show_bug.cgi?id=1329654",
      "name":"Search for Firefox Convertor (malware)",
      "why":"This is a malicious add-on that is installed using a fake name. It changes search and homepage settings."
   },
   "versionRange":[
      {
         "targetApplication":[

         ],
         "minVersion":"0",
         "maxVersion":"1.3.9",
         "severity":3
      }
   ],
   "prefs":[

   ],
   "id":"d6ec9f54-9945-088e-ba68-40117eaba24e",
   "schema":1484335370642
}

Deploying

Plugin blocks

Go to the blocklist detail page and click on Add blocklist detail.
Enter a clear name and descriptions for the block. End users will read these, so they need to be clear as to why the block was put in place and what options are available. If the extension being blocked is malware, add " (malware)" at the end of the name.
- See the Blocked Add-ons page for examples.
Set the Bug field to the blocklist bug. The bug should also have instructions for end users if the plugin is heavily used.
In the Blocklist Plugin #1 section, set the identification criteria and Severity.
- Plugins rarely have a GUID, so we use the filename field to identify plugins. Since filenames are OS-specific, the OS field is usually redundant.
- The OS can be set to any of these.
- Plugin version numbers can also be tricky and inconsistent, specially on Linux, where the version number isn't properly detected. We generally use regular expressions in the Name or Descriptions to identify the versions to block.
- Regular expressions in plugins should be meticulously tested. Regexp Pal is a good tool for this.
- The Severity should be 1 for soft blocks and 3 for hard blocks. A severity set to 2 (reserved for a medium block), or no severity will also produce a hard block. To avoid ambiguity, these options shouldn't be used. Hard blocks should be limited to malware.
- A Severity set to 0 has different meanings depending on the vulnerability status value. If not set, it is an update prompt block. If set to 1 or 2, it means it's a click-to-play block (1 when there's a known fixed update, 2 when there isn't).

To limit a block to a specific application versions, the detail can be added with an invalid filename, to keep it temporarily disabled. Then you can add a blocklist app item and link it to the detail item. Once that's done, the Severity or GUID can be set to their real values.

XML Examples

This is how the different block types look in blocklist.xml.

Soft block on Mac OS (where version numbers work correctly):

<pluginItem  blockID="p85">
  <match name="filename" exp="JavaPlugin2_NPAPI\.plugin" />
  <versionRange  minVersion="0" maxVersion="13.6.0" severity="1">
  </versionRange>
</pluginItem>

Update prompt block:

<pluginItem  blockID="p134">
  <match name="name" exp="Java\(TM\) Platform SE 7 U[5-6](\s[^\d\._U]|$)" />
  <match name="filename" exp="npjp2\.dll" />
  <versionRange  severity="0">
  </versionRange>
</pluginItem>

Hard block with target application:

<pluginItem  blockID="p27">
  <match name="name" exp="QuickTime Plug-in 7[.]1[.]" />
  <match name="filename" exp="npqtplugin.?[.]dll" />
  <versionRange >
    <targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
      <versionRange  minVersion="3.0a1" maxVersion="3.*" />
    </targetApplication>
  </versionRange>
</pluginItem>

Graphics card blocks

Go to the blocklist detail page and click on Add blocklist detail.
Enter a name and descriptions for the block. These detail pages aren't exposed to users, so these descriptions aren't very important.
Set the Bug field to the blocklist bug.
In the Blocklist Gfx #1 section, set the data that should have been detailed on the blocklist bug.

XML Examples

<gfxBlacklistEntry  blockID="g95">
  <os>WINNT 6.1</os>
  <vendor>0x1002</vendor>
  <devices>
    <device>0x9802</device>
    <device>0x9803</device>
    <device>0x9803</device>
    <device>0x9804</device>
    <device>0x9805</device>
    <device>0x9806</device>
    <device>0x9807</device>
  </devices>
  <feature>DIRECT3D_9_LAYERS</feature>
  <featureStatus>BLOCKED_DEVICE</featureStatus>
  <driverVersion>1.0.0.0</driverVersion>
  <driverVersionComparator>GREATER_THAN_OR_EQUAL</driverVersionComparator>
</gfxBlacklistEntry>