Blocklisting/Admin: Difference between revisions
(First version) |
(Added plugin block section) |
||
| Line 6: | Line 6: | ||
# 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. | # 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 [https://addons.mozilla.org/firefox/blocked/ Blocked Add-ons page] for examples. | #* See the [https://addons.mozilla.org/firefox/blocked/ 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 | # Set the Bug field to the blocklist bug. The bug should also have instructions for end users if the extension is heavily used. | ||
# In the Blocklist Item #1 section, set the add-on GUID, version range (0 to * to cover all versions) OS and Severity. | # In the Blocklist Item #1 section, set the add-on GUID, version range (0 to * to cover all versions) OS and Severity. | ||
#* The OS can be set to [https://developer.mozilla.org/en-US/docs/OS_TARGET any of these]. | #* The OS can be set to [https://developer.mozilla.org/en-US/docs/OS_TARGET any of these]. | ||
| Line 37: | Line 37: | ||
== Plugin blocks == | == Plugin blocks == | ||
# Go to the [https://addons.mozilla.org/admin/models/blocklist/blocklistdetail/ blocklist detail page]. | |||
# 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 [https://addons.mozilla.org/firefox/blocked/ 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 [https://developer.mozilla.org/en-US/docs/OS_TARGET 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. [http://mzl.la/SemegK Regexp Pal] is a good tool for this. | |||
#* The Severity should be 0 for update prompt blocks, 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. | |||
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 [https://addons.mozilla.org/admin/models/blocklist/blocklistapp/ 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): | |||
<pre><pluginItem blockID="p85"> | |||
<match name="filename" exp="JavaPlugin2_NPAPI\.plugin" /> | |||
<versionRange minVersion="0" maxVersion="13.6.0" severity="1"> | |||
</versionRange> | |||
</pluginItem></pre> | |||
Update prompt block: | |||
<pre><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></pre> | |||
Hard block with target application: | |||
<pre><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></pre> | |||
Revision as of 18:45, 3 September 2012
Blocklist entries are added through the AMO Admin Tools. Only authorized members of the Add-ons Team can manipulate the blocklist.
Extension blocks
- Go to the blocklist detail page.
- 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 extension is heavily used.
- In the Blocklist Item #1 section, set the add-on GUID, version range (0 to * to cover all versions) OS and Severity.
- The OS can be set to any of these.
- 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.
To limit a block to a specific application versions, the detail can be added with a Severity set to 0, or an invalid GUID, 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:
<emItem blockID="i20" id="{AB2CE124-6272-4b12-94A9-7303C7397BD1}">
<versionRange minVersion="0.1" maxVersion="5.2.0.7164" severity="1">
</versionRange>
</emItem>
Soft block with target application:
<emItem blockID="i23" id="firefox@bandoo.com">
<versionRange minVersion="5.0" maxVersion="5.0" severity="1">
<targetApplication id="{ec8030f7-c20a-464f-9b0e-13a3a9e97384}">
<versionRange minVersion="3.7a1pre" maxVersion="*" />
</targetApplication>
</versionRange>
</emItem>
Hard block:
<emItem blockID="i73" id="a1g0a9g219d@a1.com"> <versionRange minVersion="0" maxVersion="*" severity="3"> </versionRange> </emItem>
Plugin blocks
- Go to the blocklist detail page.
- 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 0 for update prompt blocks, 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.
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>