Confirmed users
1,041
edits
Extension Blocklisting:User Interface: Difference between revisions
Extension Blocklisting:User Interface (view source)
Revision as of 20:45, 2 March 2006
, 2 March 2006no edit summary
No edit summary |
|||
| Line 1: | Line 1: | ||
== Scope of this Document == | == Scope of this Document == | ||
To provide a specification for the various user interface pieces related to the | 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: | The following issues are '''not in scope''' for this page: | ||
* process for adding/removing an extension from the master | * process for adding/removing an extension from the master blocklist | ||
* how to ensure that | * how to ensure that blocklisted extensions don't just release an n+1 that is also vulnerable | ||
* who maintains the master | * who maintains the master blocklist, or where it is hosted | ||
| Line 14: | Line 13: | ||
== UI Design == | == UI Design == | ||
Blocklisted items can be detected in one of two cases: | |||
# User attempts to install an extension that is on the | # User attempts to install an extension that is on the blocklist | ||
# User attempts to install a plugin that is on the | # User attempts to install a plugin that is on the blocklist | ||
# An installed, | # An installed, blocklisted extension is detected after the blocklist is updated | ||
# An installed, | # An installed, blocklisted plugin is detected after the blocklist is updated | ||
=== Case 1: User attempts to install | === 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. | 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: | The taskflow for the user should be: | ||
# Extension installation process begins (may require user to add source server to the extension installation whitelist) | # Extension installation process begins (may require user to add source server to the extension installation whitelist) | ||
# Firefox checks the XPI contents against | # Firefox checks the XPI contents against blocklist | ||
# If a match to a | # If a match to a blocklisted extension is found, the installation process exits and a dialog is shown to the user: | ||
<pre> | <pre> | ||
| Line 42: | Line 41: | ||
</pre> | </pre> | ||
* the "More information..." is a web link that would bring users to the mozilla.com | * the "More information..." is a web link that would bring users to the mozilla.com blocklist page. | ||
=== Case 2: User attempts to install | === 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. | 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 <tt>em:type</tt> value of 16. | *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 <tt>em:type</tt> value of 16. | ||
*In cases where plugins are not packaged as XPIs, the | *In cases where plugins are not packaged as XPIs, the blocklisted plugin will be detected in Case 4 | ||
=== Case 3: | === Case 3: Blocklisted extension is detected after update === | ||
The | 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: | The taskflow for the user should be: | ||
# | # Blocklist update occurs (automatically, or is initiated by a "Check for Updates" request from the Help menu or the Options/Preferences panel) | ||
# If the updated | # If the updated blocklist matches against an installed extension, then these extensions will be '''immediately''' marked as to-be-disabled. | ||
# A dialog is shown to inform users: | # A dialog is shown to inform users: | ||
| Line 82: | Line 80: | ||
</pre> | </pre> | ||
* the "More information..." is a web link that would bring users to the mozilla.com | * the "More information..." is a web link that would bring users to the mozilla.com blocklist page. | ||
* "Restart Firefox" will restart the browser | * "Restart Firefox" will restart the browser | ||
* "Later" will dismiss the dialog | * "Later" will dismiss the dialog | ||
=== Case 4: | === 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 | 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: | The taskflow for the user should be: | ||
# When a plugin is loaded, it is checked against the | # When a plugin is loaded, it is checked against the blocklist | ||
# If a match is found, the puzzle piece icon appears in place of the embedded plugin, and the information bar appears: | # If a match is found, the puzzle piece icon appears in place of the embedded plugin, and the information bar appears: | ||
| Line 100: | Line 97: | ||
</pre> | </pre> | ||
* the "More Information" button is a web link that would bring users to the mozilla.com | * 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 | * the "X" button dismisses the information bar | ||
* clicking on a puzzle piece would bring users to the mozilla.com | * clicking on a puzzle piece would bring users to the mozilla.com blocklist page | ||
=== Additional extension states in Extension Manager === | === Additional extension states in Extension Manager === | ||
| Line 111: | Line 108: | ||
In both cases, the "Enable" function should not be possible for the marked extensions. Users can check for updates or uninstall the extension. | 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 | === Mozilla.com Blocklist Page === | ||
A webpage should exist on http://www.mozilla.com which lists the | 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 | === Preferences for controlling the blocklist === | ||
The common user should not be allowed to override the automatic updating and application of the | 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: | The following preferences should be created to govern this behaviour: | ||
* '''extensions. | * '''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: | Other applications or distributions may want to provide their own backlist update url which will be controlled by the following pref: | ||
* '''extensions. | * '''extensions.blocklist.url''' (string), url to the blocklist file | ||
The interval in which the | The interval in which the blocklist runs will be defined by the following pref: | ||
* '''extensions. | * '''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 | These preferences should be documented on developer.mozilla.org and any announcements for developers about the blocklist functionality. | ||