Delta Updates vs. Signed Resources (was: New Architecture Proposal)

[Benjamin Francis]

On 11 March 2015 at 14:36, Vivien Nicolas <vnic...@mozilla.com> wrote:

This proposal is about moving to hosted apps with delta updates

In the Gaia meeting last week the topic of delta updates briefly came up in the context of app signing.

The idea of delta updates is very cool, but currently the biggest blocker to implementing most of this new architecture is a new security/permissions model to allow Gaia apps to become hosted web apps and delta updates could make that much more complex.

Paul from the security team mentioned that he doesn't think we're going to be able to open up most of the privileged APIs to hosted web apps without some form of cryptographic signing solution. We don't yet know what that signing system is going to look like but so far there are three proposals:

• Signed hosted packages [1]
• Signed Service Worker cache [2]
• Signed manifests [3] (currently my preference)

In all of these cases, adding support for delta updates potentially adds significant complexity to the signing system because resources are less static and can be dynamically modified inside a cache at runtime. It could be very tricky to not invalidate a signature.

If we were to hash individual resources and enumerate them in a signed manifest as proposed in [3], then at least when the app (via the manifest) is updated potentially only the resources which have changed would need to be re-downloaded into a Service Worker cache. This is much better than having to download a whole new zip file of the entire app.

Would this be a big enough step forward for a first iteration of this architecture, potentially leaving delta updates for a future iteration when we have a basic signing system in place?

Ben

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1036275
2. https://groups.google.com/forum/#!topic/mozilla.dev.webapi/PicfHG9Figk
3. https://groups.google.com/forum/#!msg/mozilla.dev.webapi/pCY77YAg_i4/HxS89bvQ7wsJ