You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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-agevery 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 limitmax-ageto 24 hours, after which an update is ensured to happen.Use Cases
Server-forced updates need to be prevented in the following cases:
For an example of code that uses this ability of the Application Cache API, see
hyperboot(written by @substack, the author ofbrowserify).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:
Service-Worker-Max-Ageheader (IntroduceService-Worker-Max-Ageheader #721). Servers likely won't set this header by default.Service-Worker-No-Forced-Updatesheader, 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.