[slightlyoff/ServiceWorker] Make ServiceWorkers more tailored for "always offline" websites (#907)

I propose to extend ServiceWorker spec in few ways to make them even more useful for websites that are likely to **never** be truly online.

### Why?
Because there is governmental censorship in this world. People are banned from reading what they want, writing what they want, their governments don't like the mere idea of people sharing ideas around and communicating freely, and people can do little to nothing about it. Even worse, when one country starts censoring internet, their neighbors suffer as well, because internet traffic is often routed across country borders, imposing censorship even on those who are not even obliged to comply. This sucks hard and disconnects the world even more.

### How?
Currently, ServiceWorkers do not survive "force refresh" or cache reset per spec, and for usual use cases (caching) this is perfectly okay. It starts to make difference when service worker is using WebRTC to build DHTs and collect information to show without any central server to rely on, and central server is unavailable, and likely will be never available anymore, because it was censored and shut down.

It might make sense to allow workers to ask for "persistent mode". When such service worker registers, it won't just silently go in, like it does now, but will ask user for an explicit consent to be hanging around — something akin to "allow using camera" or "allow storing lots of IndexedDB data". This way persistent service workers would be only unregistereable via `about:serviceworkers` or `chrome://inspect/#service-workers`, and won't disarm when page under their control has been force refreshed, or when user clears their cache — similar to IndexedDB data that is persisted across clearing caches.

However, "persistent mode" alone will only help those lucky ones who have been able to access the website before it was shut down, and those who come later will see nothing. I propose to make it possible to register service worker for **different** domain than it is being accessed from — e.g. making a script `https://foo.org/sw.js` effective for `http://bar.net/`. Of course, this must be accomplished with large warning for user telling the consequences if they will choose to continue — similar to what happens when user asks to install a browser extension.

### Security risks
#### Persistent mode
Persistent service worker alone can confuse user trying to do cache reset, if user is unaware of the fact that website is being served locally. However, user would be confused the same way if conventional website uses IndexedDB or localStorage for rendering some of the content, because cache reset won't delete IndexedDB or localStorage data.

To address awareness concern, it might make sense for browsers to show an icon similar to SSL padlock that will alert user of the website being handled by persistent service worker, and offer the way to unregister the service worker from there.

#### Delegated service workers
Delegated service workers carry a heavy risk of "overwriting" an existing website with malicious intent. It's not secure to rely on offline check, because website might be under DDoS attack or just on maintenance. Neither it is secure to ask the website being "overwritten", because it might be redirected to ISP "Sorry, this content was censored" stub, configured to always say "nope".

At first I thought it would work if delegated service workers were signed with SSL certificate valid for domain requested, but this will only extend the lifetime of "offline website" by the validity period of SSL certificate, as there is generally no way to renew the certificate without an access to domain. So, I am out of ideas at the moment.

-----
So, what do you think of all this?

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/slightlyoff/ServiceWorker/issues/907