Firefox/Go Faster/Client Implementation Plan: Difference between revisions

← Older edit

Firefox/Go Faster/Client Implementation Plan (view source)

Revision as of 18:58, 5 October 2015

893 bytes removed , 5 October 2015

m

Typo

Jesse

Confirmed users

729

edits

@@ Line 17: / Line 17: @@
 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.
+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.
-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: 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: 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.
+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'''
@@ Line 36: / Line 35: @@
 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:
+An example response:
-  {
+  <updates><addons>
-    "<addon-1-ID>": {
+    <addon id="loop@mozilla.org" URL="https://addons.mozilla.org/addons/loop.xpi" version="12"/>
-     "version": "1.2.0",
+    <addon id="pdfjs@mozilla.org" URL="https://cdn.addons.mozilla.org/addons/pdfjs.xpi" version="1.4"/>
-     "xpiURL": "http://mozilla.com/foo/bar/addon1.xpi",
+  </addons></updates>
-     "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.
+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 and checked against the given hash (is this needed given that we're signing the add-ons too?).
+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 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.
+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'''
@@ Line 66: / Line 57: @@
 * '''Bug: Add-ons manager signature checks should enforce special rules for add-ons installed in the system add-ons location'''
-The root manifest and update manifests should be protected by https at a minimum (no certificate overrides allowed). As they can only point to signed XPIs there may be no need to do any additional security here but we should consult with the security team.
 =Bootstrapping=
@@ Line 75: / Line 64: @@
 * '''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.
+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 install all bundled system add-ons into the system add-on install location"
+* '''Bug: On startup with a new application version switch to the shipped known-good set"
 =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.
+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.