Firefox/Go Faster/Client Implementation Plan

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.

The specific path to the install location will be <profile>/features/<app path hash>. "app path hash" is a simple hash of the client's install directory. This means that if a user is using two different versions of the client application (say a developer version and a release version) with the same profile they will use two different directories for the system add-ons allowing them to be updated independently and retain the known-good set for each build. The majority of users use a single build and so will have just one directory in use.

The hash can be short to avoid causing path length problems and quick to generate. Collisions aren't a big problem, the client will recover gracefully automatically.

• Bug: Create a features install location with a lower priority to the profile location
• 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 directories. We can write the current time to the current location and for any locations that are older than a certain date delete them.

• 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 of the data the manifest must include:

{
  "<addon-1-ID>": {
    "version": "1.2.0",
    "xpiURL": "http://mozilla.com/foo/bar/addon1.xpi",
    "xpiHash": "sha256:38974658476582645723465802458972345",
  },
  "<addon-2-ID>": {
    "version": "1.0.0",
    "xpiURL": "http://mozilla.com/foo/bar/addon2.xpi",
    "xpiHash": "sha256:45676878579689577567674563576746746",
  }
}

This manifest could be a standalone file or embedded in the existing update.xml file somewhere. The former is a little easier to implement on the client side.

Any add-on versions that are not already available locally are downloaded and checked against the given hash (is this needed given that we're signing the add-ons too?).

• Bug: Download and install new system add-ons

Once all the add-on versions listed in the manifest are available locally this list replaces the current known-good 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 find the add-ons included with the application, copy them to the install location and then use them as the known-good set.

• Bug: On startup with a new application version install all bundled system add-ons into the system add-on install location"

Add-on Dependencies

Declaring dependencies between add-ons isn't supported. Each add-on is downloaded individually and if there are network issues it will be possible for one system add-on to update when another doesn't. For now if add-ons have dependencies they should either be shipped in Firefox so we can use version checks to enforce them or the add-on should programmatically check that the necessary dependencies are installed.