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

MicahZoltu left a comment (w3c/ServiceWorker#822)

Supply chain attacks and server compromises of high usage tools are now happening on a weekly, sometimes daily, basis.  I would like to see this revisited.

I can appreciate the desire to make it so that once an attacker gets onto a machine they aren't impossible to remove.

At the same time, I can also appreciate that trusting the server every time you open the app is a wildly different trust model from trusting the server when you first load the app.

Since these two problems are in direct conflict with each other, and both are legitimate, I also agree that we need a solution that can mitigate them both at the same time in some way.

Proposal:
Allow a registered service worker to *either* follow the current 24-hour update cycle, **OR** choose to prompt a user for every update.  In the latter case, the service worker would still check for updates every 24 hours, but when an update is available the browser would prompt the user and ask them if they would like to update.  Each update would only be prompted for once.

The idea here is that for low security apps, which are likely updating very regularly, the authors would follow the current setup where updates are automatic.  For high security apps the authors could choose to enable update prompting.  Their users would be "nagged" when updates are available, and thus developers of such apps would likely update less frequently and with more intent/fanfare (e.g., associated blog posts, etc.).

In the "prompt for update" regime, the default should probably be to *not* update, though this is certainly up for debate.  For a high security app in today's threat landscape my instinct is that the safe default when a user mindlessly clicks without reading is to not update rather than to update.

A design like this also could allow the browsers themselves to provide security warnings (if desired) when there is a known CVE with a particular version of a service worker deployed on the user's machine.  When they get the update prompt, the browser has the opportunity to warn the user about known CVEs.  The user would still be able to ignore the update, but it may give a path to deal with things like a spreading worm.

----

I believe this would address both the concern about attack service workers being "sticky" and difficult to get rid of, while also allowing for immutable apps that can be used when trust of server is very low and risk of compromise is very high.

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

Message ID: <w3c/ServiceWorker/issues/822/4718221648@github.com>