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

This issue is on the upcoming ServiceWorkers F2F agenda for discussion in October, although I can't promise any resolution.

Note that my previous comments still stand about the security model of the web and in particular, the [Clear-Site-Data](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data) header since implemented by Chrome and Firefox has a "[kill switch](https://w3c.github.io/webappsec-clear-site-data/#example-killswitch)" which will wipe out all storage for an origin including ServiceWorkers.  That's an intentional feature that a SW would never be able to inhibit even if normal updates could be blocked or delayed.

There is a new experimental option that seems better suited to your use-case.  There's a **very** experimental Mozilla project https://github.com/mozilla/libdweb that enables WebExtensions to implement custom protocols like IPFS (see the [blog post](https://hacks.mozilla.org/2018/08/dweb-building-cooperation-and-trust-into-the-web-with-ipfs/)).


In regards to your proposal, I understand the core of your suggestion to be that a banner would be presented if the potentially-malicious SW blocks an update and that the potentially-malicious SW is able to provide some of the text to be displayed in the banner.  The user would then reach a decision informed by searching the web and asking other people on social media what they should do.

The issue with prompting the user in cases like this is that the user is frequently unable to make an informed decision about what is going on.  Especially if the attacker can supply scary text like "There is a virus in the update, don't update or your computer will be permanently damaged!" or text that leverages update fatigue like "The update will take 10 minutes to install, are you sure you want to update?" or unique strings that the attacker can use to game any search the user would make so that the guidance they find on the internet is from the attacker.  This isn't really solving the problem, it's making the problem the user's problem.

-- 
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-424197220