Re: [w3c/ServiceWorker] Preventing server-forced updates (#822)

[Sorry for the 1.5 year late reply :) coming here from #1208, which is similar to this issue but instead of preventing the update, the old Service Worker warns the user about the update.]

@asutherland and others have brought up valid concerns about this approach, e.g., what if the user force-refreshes the web app, what if they open it in an incognito window, what about when they open it for the first time, what about on a new device. I agree with all of those, in fact, I [proposed a different solution](https://lists.w3.org/Archives/Public/public-webappsec/2017Apr/0042.html) built on Certificate Transparency a while back that would solve those things, and if browsers implemented that, I would be very happy too :)

However, a solution built on Service Workers has the big advantages that

1. It requires very little extra work on the part of browser developers
2. It potentially requires less work on the part of web app developers, as well. For example, instead of requiring them to sign their code with a public key, a SW solution can just require that updates be pushed to GitHub (or it can require both). A solution in the browser is unlikely to be flexible enough to allow that. And since many open source web apps already do that, it can be relatively more of a "set and forget" solution.

And I think it would solve the biggest part of this problem, especially because any attempt to send the user unsigned code runs the risk of detection by the SW, unless the server can somehow detect that the SW is being bypassed. That might be possible in the case of force-refresh (Cache-Control headers), though. Maybe we can use the SW to always send force-refresh-like Cache-Control headers?

And while some have indeed used browser extension to solve this problem (Signal, blockchain.info and mega.nz come to mind, although the first two of those are Chrome apps, which are getting phased out. I myself [made a Firefox addon](https://addons.mozilla.org/nl/firefox/addon/hcs-checker/)), it would be preferable if all users are protected, and they don't even protect against most of the loopholes ("what if they open it in an incognito window, what about when they open it for the first time, what about on a new device").

-- 
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/822#issuecomment-341866377

Received on Saturday, 4 November 2017 02:43:50 UTC