Preventing server-forced updates

I'd like to propose a change to the ServiceWorker spec that allows for applications which cannot be forced by the server to install updates.

Background

Native applications have a significant security advantage over web applications: they control their own update lifecycles. New code is not loaded by default, so if there is no auto-update functionality built in, new versions are only adopted at the user's will. By contrast, web applications load new, untrusted code from a server each time the user navigates to them. This increases the attack surface for malicious code to be deployed by whoever has control of the server (hackers, political actors, rogue service administrators, etc.).

The Application Cache API allowed this feature; servers could set the AppCache manifest max-age very far in the future which would prevent the browser from contacting the server. However, servers configured to cache aggressively would cache these manifests and brick apps accidentally, leaving developers unable to deploy fixes to their apps. Since this problem was common, the ServiceWorker spec is defined to limit max-age to 24 hours, after which an update is ensured to happen.

Use Cases

Server-forced updates need to be prevented in the following cases:

• Handling private keys or other sensitive data
• Apps that rely on anonymity or encryption, such as TOR or secure messaging
• ServiceWorkers which verify integrity and authenticity of updates loaded from an untrusted CDN

For an example of code that uses this ability of the Application Cache API, see hyperboot (written by @substack, the author of browserify).

Solutions

In the ServiceWorker spec, preventing forced updates must only happen when explicitly requested, so as not to cause the accidental bricking tragedies seen with AppCache.

Possible methods for adopting this feature:

• Removing the 24-hour cap for the proposed Service-Worker-Max-Age header (#721). Servers likely won't set this header by default.
• An additional Service-Worker-No-Forced-Updates header, that should only be used to specifically opt in to this feature, which will remove the 24-hour cap.

These changes still allow for applications to trigger their own updates by unregistering their ServiceWorker and registering the new version. It may also be beneficial to add a method which triggers a reload of the registered ServiceWorker and does the standard byte-for-byte comparison to see if there is an update.

Thank You

Thanks for considering this proposal. I believe this small change would make ServiceWorkers much more powerful, and bring the web a huge step closer to parity with native applications.

Start by reading the ServiceWorker spec's update-checking rules and the related proposal in issue #721. Compare the two suggested header approaches and the existing unregister-and-register behavior described here. Done means the spec defines an explicit, non-accidental way for applications to prevent server-forced updates while retaining a way to trigger updates themselves.