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
| (4 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 116: | Line 120: | ||
== 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 | |||