Extension Blocklisting:User Interface: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(added link to screenshots)
Line 17: Line 17:
# An installed, blocklisted extension is detected after the blocklist is updated
# An installed, blocklisted extension is detected after the blocklist is updated
# An installed, blocklisted plugin is detected after the blocklist is updated
# An installed, blocklisted plugin is detected after the blocklist is updated
[https://bugzilla.mozilla.org/attachment.cgi?id=213956 Screenshot] of the dialogs


=== Case 1: User attempts to install blocklisted extension ===
=== Case 1: User attempts to install blocklisted extension ===

Revision as of 03:01, 7 March 2006

Please comment in the Talk page (use the Discussion tab above)

Scope of this Document

To provide a specification for the various user interface pieces related to the blocklist functions that will ship in Firefox 2.0.

The following issues are not in scope for this page:

  • process for adding/removing an extension from the master blocklist
  • how to ensure that blocklisted extensions don't just release an n+1 that is also vulnerable
  • who maintains the master blocklist, or where it is hosted

UI Design

Blocklisted items can be detected in one of two cases:

  1. User attempts to install an extension that is on the blocklist
  2. User attempts to install a plugin that is on the blocklist
  3. An installed, blocklisted extension is detected after the blocklist is updated
  4. An installed, blocklisted plugin is detected after the blocklist is updated

Screenshot of the dialogs

Case 1: User attempts to install blocklisted extension

This case will be rare, as efforts will be taken to remove offending extensions from the popular extension sites when an exploit is discovered. However, the system should expect that users may still attempt to install extensions that are known to be exploitable.

The taskflow for the user should be:

  1. Extension installation process begins (may require user to add source server to the extension installation whitelist)
  2. Firefox checks the XPI contents against blocklist
  3. If a match to a blocklisted extension is found, the installation process exits and a dialog is shown to the user:
        .----------------------------------------------------.
        |This extension isn't secure                         |
        |====================================================|
        |   .                                                |
        |  /!\   The extension $extNameAndVersion is known   |
        |  ---   to be dangerous, and can't be installed.    |
        |                                                    |   
        |       <More information...>                        |
        |                                                    |   
        |                       [ OK ]                       |
        '----------------------------------------------------'
  • the "More information..." is a web link that would bring users to the mozilla.com blocklist page.

Case 2: User attempts to install blocklisted plugin

This case cannot be reliably detected at install-time, as plugins do not need to be packaged as XPIs.

  • In cases where plugins are packaged as Extension Manager XPIs (e.g. with an install.rdf), the task flow should be as in case 1, although the dialog should refer to "plugin" instead of "extension". This will be determined by the plugin's install.rdf having an em:type value of 16.
  • In cases where plugins are not packaged as XPIs, the blocklisted plugin will be detected in Case 4

Case 3: Blocklisted extension is detected after update

The blocklist will be updated through the Software Update mechanism, likely on a different (more frequent? 12hr offset?) timer from the standard application and extension update mechanism. When an update to the blocklist arrives, all installed extensions (but not plugins, see case 4) should be checked against that list.

The taskflow for the user should be:

  1. Blocklist update occurs (automatically, or is initiated by a "Check for Updates" request from the Help menu or the Options/Preferences panel)
  2. If the updated blocklist matches against an installed extension, then these extensions will be immediately marked as to-be-disabled.
  3. A dialog is shown to inform users:
        .-------------------------------------------------------.
        |Some of your extensions aren't secure                  |
        |=======================================================|
        |   .                                                   |
        |  /!\   A security update to Firefox has indicated     |
        |  ---   that one or more of your extensions are no     |
        |        longer considered safe.                        |   
        |                                                       |   
        |        .---------------------------------------.      |   
        |        |{list of extensions}                   |      |   
        |        |                                       |      |   
        |        |                                       |      |   
        |        .---------------------------------------.      |   
        |                                                       |   
        |        You should restart Firefox so that these       |   
        |        extensions can be disabled.                    |   
        |                                                       |   
        |       <More information...>                           |
        |                                                       |   
        |                       [ Restart Firefox ] [ Later ]   |
        '-------------------------------------------------------'
  • the "More information..." is a web link that would bring users to the mozilla.com blocklist page.
  • "Restart Firefox" will restart the browser
  • "Later" will dismiss the dialog

Case 4: Blocklisted plugin is detected after update

Since many plugins install across all browsers & tools, it's entirely possible that Firefox may have an installed plugin that is blocklisted, but a user never loads that plugin through the browser. In these cases it is not our responsibility to remove the offending plugin. Firefox should only alert the user to a blocklisted plugin when that plugin is loaded. As such, our detection mechanism for plugins should only check when plugins are loaded.

The taskflow for the user should be:

  1. When a plugin is loaded, it is checked against the blocklist
  2. If a match is found, the puzzle piece icon appears in place of the embedded plugin, and the information bar appears:
.----------------------------------------------------------------------------.
| /!\ This page uses an insecure plugin               [More Information] [X] |
'----------------------------------------------------------------------------'
  • the "More Information" button is a web link that would bring users to the mozilla.com blocklist page.
  • the "X" button dismisses the information bar
  • clicking on a puzzle piece would bring users to the mozilla.com blocklist page

Additional extension states in Extension Manager

Two new states will be required for the Extension Manager:

  • &extName will be disabled for your protection when &shortBrandName is restarted
  • &extName has been disabled for your protection

In both cases, the "Enable" function should not be possible for the marked extensions. Users can check for updates or uninstall the extension.

Mozilla.com Blocklist Page

A webpage should exist on http://www.mozilla.com which lists the blocklisted extensions and plugins, the reasons for their entry on the blocklist, and links to known good versions (if they exist) so the user can restore the missing functionality.

Preferences for controlling the blocklist

The common user should not be allowed to override the automatic updating and application of the blocklist, but there are valid use cases for doing so.

The following preferences should be created to govern this behaviour:

  • extensions.blocklist.enable (boolean), toggles blocklist enabled on/off

Other applications or distributions may want to provide their own backlist update url which will be controlled by the following pref:

  • extensions.blocklist.url (string), url to the blocklist file

The interval in which the blocklist runs will be defined by the following pref:

  • extensions.blocklist.interval (integer), the interval in which to download a new blocklist file

These preferences should be documented on developer.mozilla.org and any announcements for developers about the blocklist functionality.