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.
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="email@example.com" URL="https://addons.mozilla.org/addons/loop.xpi" version="12"/> <addon id="firstname.lastname@example.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
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 should be managed at the server side. The client will ensure that only a known-good set of system add-ons runs.