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

I'm interested in this functionality too, to protect disruption of the ServiceWorker within [RecipeRadar](https://www.reciperadar.com/), a web-hosted Progressive Web Application.

I've reviewed and broadly like @twiss's proposal, and I have a competing proposal that is compatible with delivery over both HTTP and HTTPS (my understanding is that SCT requires TLS).

My competing proposal is that site operators should deploy a [W3C-SRI-format compatible](https://www.w3.org/TR/SRI/) value to DNS containing the expected hash of the content body served from the root path of the webserver.  I admit that this single-path limitation is somewhat constraining.

Although I've asked the `dnsext` mailing list whether an additional DNS record type would be suitable for this, I think any kind of standardisation is a long way off, and perhaps unlikely.  However, for the sake of demonstration, I can illustrate a snippet of the current contents of DNS TXT records for `reciperadar.com`, where I've deployed the app's current expected hash:

```
;; ANSWER SECTION:
reciperadar.com. 3600 IN TXT "B=sha512-p69NIfGgc1xBwGBO+91ELEttAujx0vc4iCHJi+GnFLp1fdQGv8YXc1OXxky38vTwqzrG80FYySIvubNOPSGt4A=="
```

(note that when I deploy updated code for RecipeRadar, this entry temporarily contains _two_ hashes -- one for the cached/stale app allowing web browsers using web caches to continue to use the stale app until it expires, and one for the current/fresh app.  the W3C SRI spec foresaw this requirement for subresources hosted by CDNs, and so it does support multiple values at a given hash strength level - see [example 7 here](https://www.w3.org/TR/SRI/#does-response-match-metadatalist))

No web client currently supports this in practice, as far as I'm aware - however the idea would be that if the integrity check for the root resource fails, then we should be careful about trusting or loading any of the referenced subresources (including the ServiceWorker script), even if they contain SRI hashes (in other words: the root resource hash appears faulty, so all bets are off on the subresource hashes).

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

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