Nutshell review results:
Attended: mossop, robstrong, dveditz, window, jesse, tchung.
Filed bug 406025, bug 406026, bug 406028, bug 406030, bug 406032.
Added comments for the implementation of bug 404024

Status

Feature tracking bug

• bug 257155 - Support shipping of localized user-facing addon text
• bug 391730 - Add-ons Manager Plugins UI for Firefox 3.0
• bug 252830 - Blocked XPI install should have allow once feature
• bug 369075 - Add permanent button for restarting Firefox to Add-ons Mgr
• bug 297903 - Extension updates should link to further information
• bug 384956 - Provide access to extension options from app options
• bug 378216 - Disable insecure extension updates by default
• bug 299716 - Need for em:targetApplication marker for "the toolkit"
• bug 404024 - Add AMO integration pane
• bug 396510 - Remove EM command line global installation capability (e.g. -install-global-extension and -install-global-theme)
• Remove install.js support

Has a design review been completed?

The UX team, Pike and dveditz have reviewed relevant aspects of most of the features though nothing so formal as a design review has occurred. The exception is the AMO integration pane which has only now been scoped.

When do you anticipate the feature landing

The main parts of most of the above have now landed with some final fixes still to be implemented.

The AMO integration pane which we expect to land in time for beta 3.

The removal of EM command line installation should land for beta 3.

The removal of install.js support should land for beta 3.

Overview

Describe the goals and objectives of the feature here. Goals for the new work:

• Simplify the installation and management of all types of add-ons where possible
• Present information about add-ons in an appropriate locale for the user at all times
• Provide the user with more information about updated add-ons
• Protect users from installing updates insecurely
• Give add-on authors additional functionality

Use Cases

Describe the primary use cases for the feature here.

• Installing new add-ons
• Configuring add-ons
• Enabling/Disabling/Uninstalling existing add-ons

Requirements

List functional and non-functional requirements for the feature here, with links back to any relevant product PRD. These requirements should be prioritized.

PRD: http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#Add-ons

Schedule

Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes.

The restart button and l10n work landed for alpha 6, the other parts landed for alpha 8. Specific bugs have the target milestone set appropriately. The AMO integration pane should be completed for beta 3.

UI Design Documentation

use cases and expected user knowledge (terminology, metaphors, etc) design mockups (of whatever fidelity is easiest) links to relevant user data, bugs, reports, examples, etc

• AMO integration pane mockups

Design Impact

Security and Privacy

What security issues do you address in your project?

New work involves ensuring that MITM attacks cannot occur during the add-ons update process, this involves ensuring that updates are either delivered by ssl secured connections or have been signed by a cryptographic key pair, the public part of which is already known to the application.

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

• Discuss about pref changes compromising security.

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

Part of the work involves displaying release notes about add-ons in the primary chrome UI. This content comes from a remote webserver and so must be sanitised to remove any script and styling from it.

The ability to install extensions into the application is itself a potential risk since the extension runs as a privileged component of the application able to perform any operation that the regular application can.

The xpinstall whitelist already exists to stop sites from bothering users with install dialogs except from trusted sites.

The update security restrictions ensure that once an extension is installed it's update cannot be circumvented by a third party.

Exported APIs

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

nsIExtensionManager

nsIBlocklistService

The primary UI is displayed from Tools - Add-ons and provides a UI for managing installed add-ons.

On startup if a new add-on update has been detected we display a UI for installing this update presenting any release notes the add-on author has provided with it.

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

The Add-ons manager retrieves update information about installed and add-ons to be installed from remote servers. This is done using the regular HTTPS protocol retrieving a file in an RDF format as described in the update manifest documentation.

The AMO integration pane uses a webservice at services.mozilla.org. The specification is not yet finalised however it will be retrieve a simple xml format: AMO API.

The add-on update information is retrieved as a regular webpage before being sanitised by the client.

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

Each add-on is delivered as an xpi file which is just a simple zip file. There are a number of files existing for each add-on to enable installation and subsequent updating:

• install.rdf holds per-add-on metadata that describes what version the add-on is, what applications it can be installed into and user-facing information such as a name and description.
• update.rdf is retrieved from the internet to tell the add-ons manager updated information about the current add-on and any updates that are available for it.
• Other files in the add-on are not really used by the add-ons manager however the application makes use of them to run the add-on. The structure of the addon a bundle.

The Add-ons manager maintains 3 state files in the user's profile directory:

• extensions.rdf holds the bulk of information about all installed add-ons, the majortiy of this is copied from the add-on's install.rdf file and state information such as blocklisting, disabling status is held here.
• extensions.ini contains a list of the directories of currently installed and enabled add-ons. This is used by the application, the add-ons manager the current list of add-ons to this but does not read from it.
• extensions.cache contains a list of all the known add-ons together with state information about the last modified time and any operations waiting to be performed. This is used to increase startup performance by allowing the add-ons manager to avoid loading extensions.rdf unless necessary.

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

yes

Does it change any existing interfaces?

There have been incremental updates to the nsIExtensionManager interface as features were developed

Web Compatibility

Does the feature had any impact on Web compatibility?

None

Performance

How will the project contribute (positively or negatively) to "perceived performance"?

There are no changes to perceived performance in Firefox 3

What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?

The goals were to not impact performance.

Will it require large files/databases (for example, browsing history)?

There are no additional files required over those in Firefox 2

Reliability

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

When a user installs an add-on without a secure update path then they are presented with an error dialog informing them of the failure.

Most other failures are hidden from the user, failures during automatic attempts to check for updates are not shown.

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

Yes, the main state file is rdf and this can be corrupted by crashes. The EM attempts to recover from corrupt files when first read.

There are no lock files to be cleaned up.

l10n and a11y

are any strings being changed or added?

There have been minor changes and additions to the strings as features have been implemented. A number of strings have also been removed as they are no longer in use.

are all UI elements available through accessibility technologies?

There are some focus issues with the richlistbox used in the UI.

Installation, Upgrade/Downgrade/Sidegrade, and platform requirements

Does it equally support all Tier-1 platforms?

Yes

Does it have a hardware requirement (or increase minimum requirements)?

No

Does it require changes to the installer?

No

Does it impact updates?

Yes, when performing an update check we have to check whether the installed add-ons are compatible with the updated version of the application. We must now not only check the version of the updated application but also the toolkit version of the updated application.

list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)

Reinstalling the same version should not have any effect. Installing a different version of the application should cause the Add-ons manager to disable any installed add-ons not compatible with the new version and enabled any add-ons that are now compatible.

configuration

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

The only relevant setting in the UI is that of the installation whitelist. All other settings are only visible in about:config and only really useful to developers, particularly extensions.checkUpdateSecurity which can be used to allow installation of add-ons with insecure update paths.

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

No

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

No new tunables have been added since Firefox 2.

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

AMO have to maintain the release notes for add-ons for the new functionality to work.

Relationships to other projects - are there related projects in the community?

Many community projects take the form of add-ons. Also many applications based on Mozilla code use the Add-ons manager so the majority of the new features apply to them.

If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?

Community add-ons require the add-ons manager and the features it provides in order to install into the application. Some add-ons will be restricted from installing with the security changes. The McCoy tool has been developed to allow the authors to get their add-ons compatible with the new requirements.

Are you updating, copying or changing functional areas maintained by other groups? How are you co-ordinating and communicating with them? Do they "approve" of what you propose?

No

Documentation

Do built-in Help pages need modified?

Yes, the additional plugins UI should be documented.

Documentation for developer.mozilla.org?

Yes, most features require developer documentation much of which has already been completed along with an extensive rewrite of the add-ons update documentation.

Other

any other implementation or design related documentation

Discussion & Implications

Caveats / What We've Tried Before

links to previous design documents, discussions, etc.

N/A

References

Development Specification for Add-on Update Security

Development Specification for Localizing Add-on Metadata