Re: [w3c/ServiceWorker] _Update algorithm should unregister SW on 404 and 410 errors (#204)

I think it's absolutely desirable to address this.  I worry about the complexity and potential security fallout of putting the developer special-case in the heart of the spec, though.  This seems like a use-case best handled by each browser's devtools.  They can be more proactive with UI and heuristics than would ever make sense in the spec.

For example, an update check might take up to 24 hours to hit the network and trigger a 404/410-based uninstall if updateViaCache="all" (formerly useCache, https://github.com/w3c/ServiceWorker/pull/1107) and Cache-Control says the data is still good.  But devtools can by default show a UI affordance in the URL bar that indicates the page was intercepted by a ServiceWorker against localhost, and for good measure throw up a door-hangar or panel resulting from a proactive update check that notices the SW is gone, etc.

This is also more likely to play well with devtools' affordances like Chrome's "Update on reload" checkbox option under the "Service Workers" page of the "Application" tab.

Having said that, there are header-based mitigations that tools that are running their own webserver on localhost could use to try and proactively mitigate the situation, such as is discussed in https://github.com/facebookincubator/create-react-app/pull/2438.  For example, the [link header](https://w3c.github.io/ServiceWorker/#link-type-serviceworker) could be used to install a "cleanup" service worker when the webserver gets a chance to serve the user a page because the refresh button was hit and bypassed the existing SW.  I think there's also been talk of a header to let an origin request that its persistent storage be blown away?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/204#issuecomment-306956987