Firefox3.6/Plugin Update Awareness Security Review

Overview

Automatically detect when an installed plugin is concidered out of date, and alert the user - directing them to the Plugin Check page on mozilla.com.

Background links

• Project wiki page
• bug 514327

Security and Privacy

• Is this feature a security feature? If it is, what security issues is it intended to resolve?

Yes - Outdated plugins are often vulnerable and unstable. They are also very common, as users had to manually check each plugin version and find the newest version to install.

• What potential security issues in your feature have you already considered and addressed?

To show the notification bar, the browser (chrome) listens for certain events coming from content - potentially allowing content to generate an event that would trigger a chrome notification bar. Events that are not trusted events are ignored.

• Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?

No.

• Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.

This uses (and integrated into) the architecture provided by the Blocklist functionality - any weakness in the blocklist code may be present in this feature.

• How are transitions in/out of Private Browsing mode handled?

Private Browsing mode is not relevant to this feature.

Exported APIs

• Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)

Adds function: nsIPluginHost.getPluginTagForInstance() - only available to C++ XPCOM Adds constant: nsIBlocklistService.STATE_OUTDATED

• Does it interoperate with a web service? How will it do so?

Yes - it uses the data from the blocklist.xml file, generated by the Plugin-finder service on addons.mozilla.com

• Explain the significant file formats, names, syntax, and semantics.

No schema change to blocklist.xml. A '0' value of the severity attribute is now interpreted as marking the plugin as outdated.

• Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?

Yes - comments in the .idl files.

• Does it change any existing interfaces?

Yes - nsIPluginHost and nsIBlocklistService.

Module interactions

• What other modules are used (REQUIRES in the makefile, interfaces)?

No additional interactions that weren't already in the existing blocklist functionality.

Data

• What data is read or parsed by this feature?

The severity attribute in blocklist.xml - all other parsing and reading comes from the blocklist functionality.

• What is the output of this feature?

No output.

• What storage formats are used?

blocklist.xml (stored in the profile directory) was handled already by the existing blocklist code.

Reliability

• What failure modes or decision points are presented to the user?

When an outdated plugin is loaded in content, the user is warned and given the choice of visiting the Plugin Check page, or ignoring the warning.

• Can its files be corrupted by failures? Does it clean up any locks/files after crashes?

N/A

Configuration

• Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?

The URL of the Plugin Check page is stored in the pref plugins.update.url. A pending warning on restart is stored in the pref plugins.update.notifyUser and set/reset automatically. Neither pref has a UI.

• Are there build options for developers? [#ifdefs, ac_add_options, etc.]

No.

• What ranges for the tunable are appropriate? How are they determined?

N/A

• What are its on-going maintenance requirements (e.g. Web links, perishable data files)?

N/A

Relationships to other projects

• Are there related projects in the community?

No.