Firefox3.1/Blocklisting Security Review: Difference between revisions

 
(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): https://bugzilla.mozilla.org/attachment.cgi?id=345404. 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.
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?
* If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
 
* Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?
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
canmove, Confirmed users
1,567

edits