This is a straw-man client implementation plan that covers the main Client Requirements. The rough set of bugs needed to implement this are called out.

Known-good sets

To reduce the number of possible configurations thus simplifying QA and dependency issues the client implementation uses the concept of a "known-good set" of system add-ons. This is a list of add-on IDs and versions to run for a particular application.

Every application package and update will be distributed with a known-good set of system add-ons for that application. Periodically the application will attempt to discover a new known-good set to be installed and used.

The application will only run with a known-good set of system add-ons enabled or it will not enable any system add-ons and run standalone though since the application ships with a known-good set we should generally never be in this state.

The only exception is in the case where a developer has installed a version of a system add-on in the profile for testing, in this case it essentially overrides the known-good version for that add-on.

Running system add-ons

System add-ons will be installed in the user's profile. This assures that client code can install and update add-ons without needing special privileges and that there can only be one client application accessing the add-ons at a time.

They will be installed in a directory used as a regular add-on install location with a lower priority than the profile install location. This allows developers to test out new versions of system add-ons by installing them using the regular add-ons manager.

Unlike existing add-on install locations system add-ons will be installed in a filename based on both ID and version, <id>_<version>.xpi. This allows multiple versions of the same add-on to be installed at the same time so if a user is running a developer edition and release version they can rely on different known-good sets.

• Bug: Cache the known-good set of add-ons on a per-install basis
• Bug: Create a features install location with a lower priority to the profile location which lists the current known-good set of add-ons
• Bug: Hide system add-ons in the features location from the add-ons manager UI

If a user uninstalls an old build they will be left with a now useless set of system add-ons. Periodically we should check <profile>/features for unused add-ons. We can update a manifest with the last-used time of the current add-ons and remove ones that haven't been used in a while.

• Bug: Shortly after startup write the current time to the system add-on install location and purge older locations

Discovering system add-ons

By default the add-ons manager will attempt to update system add-ons automatically, this must be disabled so a slightly different mechanism for finding updates can be used.

• Bug: Disable automated updates for the system add-ons location

During runtime the client will periodically make a HTTPS request to a specific URL including data on the application channel, version and OS The manifest returned lists the specific system add-ons that should be used with that application.

An example response:

<updates><addons>
  <addon id="loop@mozilla.org" URL="https://addons.mozilla.org/addons/loop.xpi" version="12"/>
  <addon id="pdfjs@mozilla.org" URL="https://cdn.addons.mozilla.org/addons/pdfjs.xpi" version="1.4"/>
</addons></updates>

If the server returns with an error or malformed XML or the response doesn't include an <addons> section then the result is ignored and the current set of system add-ons is kept. If the <addons> tag is present but empty then it means no system add-ons should be enabled.

Any add-on versions that are not already available locally are downloaded.

• Bug: Download and install new system add-ons

Once all the add-on versions listed in the manifest are available locally and are verified to be usable with the current application they are copied to a new directory inside <profile>/features and the known-good set is updated with the new set. Any enabled system add-ons not in the set are disabled, any system add-ons in the set not enabled are enabled.

• Bug: Replace the current set of system add-ons with the new known-good set

Securing system add-ons

System add-ons will need to be signed in a way that differentiates them from regular add-ons. This means either using a custom signing certificate or using the AMO signing service. AMO currently has two signing servers set up two sign preliminarily reviewed add-ons and fully reviewed add-ons. Clients can distinguish between the two based on a special string added to the Organizational Unit (OU) of the signing certificate for each add-on. Adding a third signing server that adds a new string to the OU is straightforward but AMO would need some updates to know to pass certain add-ons to that server.

• Bug: Add-ons manager signature checks should enforce special rules for add-ons installed in the system add-ons location

Bootstrapping

In order to give a good experience to users using a new profile or updating after not having used the client in a while the application should ship with a known-good set of system add-ons for that build. This means including the add-ons in installers, packages, dmgs and the update mars for the application.

• Bug: Include system add-ons in application packages and updates

On the startup of a new version of an application the client will replace its known-good set with the new set included in the application.

• Bug: On startup with a new application version switch to the shipped known-good set"

Add-on Dependencies

Add-on dependencies should be managed at the server side. The client will ensure that only a known-good set of system add-ons runs.