[w3c/ServiceWorker] ServiceWorker verification (Issue #1720)

Due to the sensitive capabilities (provided by the service worker) like request interception and others. The service worker script should be subjected at least to the same standards as common scripts in regards to security.

please keep in mind that currently:

- there is absolutely no safeguard in place to verify the integrity or ownership of the service worker script.
- it's not uncommon to see service workers hosted in shared domains where the domain administration is not in the control of the web author.
- there is no certainty of when the service worker script could be updated.

Taking into consideration the unnecessary complexity and lack of adoption of previous initiatives like: ["XML Signature Syntax and Processing"](https://www.w3.org/TR/xmldsig-core2/) I believe a simpler approach is needed.

Acknowledging previous valid concerns like: https://github.com/w3c/ServiceWorker/issues/578#issuecomment-66066294 from https://github.com/annevk here is my proposal:

> Allow the web author to reject a service worker update within a reasonable time frame, after which it is forcibly updated. In this manner we have time to properly address the situation and gracefully recover while being in control.

### Implementation:

The "verify" event in ServiceWorkerGlobalScope: which callback is executed after downloading and before installing the new service worker when a new service worker update is detected.
This event permits the author to access the downloaded service worker script using the "event.ServiceWorkerScript" property and define their own verification logic using the event methods: "event.accept()" or "event.reject()". By default if no event callback is defined It is understood that it is always accepted.

Add the option "rejectTimeout" to the ServiceWorkerContainer: register() method.
This option specifies the maximum duration where the rejected verification is respected, default value is 86400.

In the case of a rejected verification: 

- on first rejection: do not install the new version of service worker, keep the current one.
- compute and store "rejected expiration": timestamp of rejection plus "rejectTimeout" option value if not stored already.
- from now on every time a service worker update is triggered and verification rejected again check if the "rejected expiration" has been reached (current time is equal or greater than "rejected expiration"), if it has been reached proceed to update service worker as if the verification had been accepted  

In the case of an accepted verification:

- clear "rejected expiration" if it exists.
- proceed with new service worker installation.

I hope there is at least a conversation about this subject of importance as involves a major security issue.

álvaro

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

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