canmove, Confirmed users
1,567
edits
Firefox3.1/Blocklisting Security Review: Difference between revisions
Firefox3.1/Blocklisting Security Review (view source)
Revision as of 23:36, 8 December 2008
, 8 December 2008→Review comments
(→Data) |
|||
| (7 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
Primarily we have added support for severities to the blocklist. A version of an add-on will be included in the blocklist at a specific severity level. Firefox will behave differently depending on whether this severity is above or below a certain threshold. If the severity is too high then the add-on will be totally blocked in the same way as in previous versions of Firefox. If the severity is lower then the add-on may still be used however the user will be warned that the add-on may cause problems. | Primarily we have added support for severities to the blocklist. A version of an add-on will be included in the blocklist at a specific severity level. Firefox will behave differently depending on whether this severity is above or below a certain threshold. If the severity is too high then the add-on will be totally blocked in the same way as in previous versions of Firefox. If the severity is lower then the add-on may still be used however the user will be warned that the add-on may cause problems. | ||
The second main goal was to improve notification to the user about when plugins are blocklisted. This has been tackled in two ways. Firstly when a new blocklist is downloaded and new add-ons blocked because of it we display a dialog listing all the effected add-ons (previously we only listed extensions) | The second main goal was to improve notification to the user about when plugins are blocklisted. This has been tackled in two ways. Firstly when a new blocklist is downloaded and new add-ons blocked because of it we display a dialog listing all the effected add-ons (previously we only listed extensions). Secondly when the user visits a webpage that attempts to use a blocked plugin we now include an in-page box where the plugin would be. The same is now true for disabled plugins and the user can click the box to get the add-ons manager open in order to manage their plugins. | ||
;Background links | ;Background links | ||
| Line 38: | Line 38: | ||
[http://mxr.mozilla.org/mozilla-central/source/xpcom/system/nsIBlocklistService.idl nsIBlocklistService] | [http://mxr.mozilla.org/mozilla-central/source/xpcom/system/nsIBlocklistService.idl nsIBlocklistService] | ||
https://bugzilla.mozilla.org/attachment.cgi?id=345401 | https://bugzilla.mozilla.org/attachment.cgi?id=345401 | ||
https://bugzilla.mozilla.org/attachment.cgi?id=345404 | https://bugzilla.mozilla.org/attachment.cgi?id=345404 | ||
https://bugzilla.mozilla.org/attachment.cgi?id=345405 | https://bugzilla.mozilla.org/attachment.cgi?id=345405 | ||
https://bugzilla.mozilla.org/attachment.cgi?id=345406 | https://bugzilla.mozilla.org/attachment.cgi?id=345406 | ||
| Line 75: | Line 79: | ||
== Data == | == Data == | ||
* What data is read or parsed by this feature | * What data is read or parsed by this feature | ||
Only the blocklist xml file is parsed. The service relies on the extension manager and plugin host to provide details about the installed add-ons. | |||
* What is the output of this feature | * What is the output of this feature | ||
The service can be queried to see if a particular add-on is blocked and periodically blocks/unblocks add-ons as a new blocklist is downloaded. | |||
* What storage formats are used | * What storage formats are used | ||
The blocklist is held as an xml file in the profile folder. There is also a copy of the blocklist shipped with the application for use when a different version has yet to be downloaded to the profile. | |||
== Reliability == | == Reliability == | ||
* What failure modes or decision points are presented to the user? | * What failure modes or decision points are presented to the user? | ||
Any failure to download or parse the blocklist is hidden from the user. | |||
The only decision point is when a user attempts to install an add-on that is soft blocked, at that point they will be asked if they really want to install it. | |||
* Can its files be corrupted by failures? Does it clean up any locks/files after crashes? | * Can its files be corrupted by failures? Does it clean up any locks/files after crashes? | ||
The service is reliant on AMO providing a correct blocklist XML file. If AMO responds with an error status or with something that isn't XML then the blocklist service will ignore it. If it was possible for AMO to return something that is valid XML but doesn't contain correct blocklist data then the blocklist service would simply act as if nothing were blocked. | |||
== Configuration == | == Configuration == | ||
* Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? | * Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables? | ||
Users can change blocklist settings in about:config. It is possible for them to completely turn off the blocklist there if they choose to do so, it is also possible to adjust the threshold at which a soft block becomes a hard block. | |||
* Are there build options for developers? [#ifdefs, ac_add_options, etc.] | * Are there build options for developers? [#ifdefs, ac_add_options, etc.] | ||
None | |||
* What ranges for the tunable are appropriate? How are they determined? | * What ranges for the tunable are appropriate? How are they determined? | ||
extensions.blocklist.interval determines how often the blocklist is refreshed. It is currently set to one day. {{bug|465570}} has some discussion on changing the default. | |||
extensions.blocklist.level determines the severity that is a hard block. It can be adjusted between 0 and 3 and Firefox 3.1 has it defaulting to 2. | |||
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | * What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | ||
AMO has a database that is changed as new items are blocked and items are unblocked. | |||
== Relationships to other projects == | == Relationships to other projects == | ||
Are there related projects in the community? | * Are there related projects in the community? | ||
As far as I am aware no other application developer maintains their own blocklist so the changes should not impact anyway. However the changes have been made in a backwards compatible fashion. A blocklist of the format that Firefox 3.0 understood will still work and have the same effect in Firefox 3.1. | |||
== Review comments == | == Review comments == | ||
* Need to check that a bad certificate error when retrieving the blocklist is handled correctly | |||
* What do we do if attempts to update the blocklist fail consistently for a long time, the user has no current blocklist | |||
* Change text to point out that only a particular version is blocked, something like "Minefield has determined that the following versions of add-on are known to cause stability or security problem, you might want to check for updates." {{bug|468524}} | |||
* Perhaps the blocklist more information url should be https {{bug|468526}} | |||
* We should be escaping the parameters in the blocklist url {{bug|468527}} | |||
* Perhaps we could speed up blocklist requests in the event of an error | |||
* Should we log blocklist request failures to some console as at least an indication there is a problem | |||
* Check what happens if the plugin regular expression is malformed, try to restrict one typo from breaking the entire blocklist {{bug|468528}} | |||
* Does the update check any If-Modified-Since header | |||
* Should clicking check for updates in the add-ons manager do a blocklist update check as well? This could warn about blocklist update failures more explicitly | |||