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

Thank you for the answer and feeding the search.

My proposal has indeed nothing to do with bypassing clear browser cache functionality.

One of my premise was that in legit case, the banner wouldn't show for long as the server take-over is likely to be fixed within hours or at worth within days.

On the other hand, a malicious SW would continue to pop a warning forever until updated, incentivising user to do something about it. Non technical users are likely to accept the update after a few days and wipe malicious SW just to get rid of the banner. Not saying it's so great, just saying it leverages blind behaviors.

Now there may be a other ways to leverage this difference in update denial timespan, like setting a reasonable time limit to rejection at 24 or 48 hours.

The problem I see in their cases is that domain owners may know users have a malicious SW but remains powerless about it.

---

Another option (if it's acceptable for browsers)  I can see is having the SW rejection option being enabled for a website through a DNS TXT field.

In this scenario, the malicious SW squat attack against a website that hadn't the SW update rejection enabled could work only by taking over the DNS, and only as long as control over DNS remains as legit owner would be able to switch off the rejection option, triggering SW renewal.

The TXT field would be either inexistent (option not enabled) either a number that represent for how much minutes an update rejection remains valid, maybe with a reasonable maximum limit.



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