Re: [w3c/ServiceWorker] Support subresource integrity for service workers (Issue #1680)

> Because a service worker has extremely powerful control over an origin, and is remembered for long periods, a compromised service worker file is potentially one of the most disastrous things that could happen to a site.

It's for that very reason that SRI pinning seems like it would only enable such an attack to **persist** after I've got my website back—anything which *protects* a web app against takeover by its future owner also necessarily "protects" a web app against re-takeover by its rightful owner after a compromise.

After all, what's the \*technical\* difference between these?

- A site administrator <em>(secure mail host)</em> who wants his site to robustly continue serious function <em>(cryptographic processing)</em> for many hours in the face of adversarial <em>(government)</em> takeover
- A "site administrator" <em>(adversary)</em> who wants "his" <em>(my)</em> site to robustly continue "serious function" <em>(displaying seriously offensive imagery)</em> for many hours in the face of "adversarial" <em>(legitimate)</em> takeover

-----

> I could envisage someone developing an addon that ships a preloaded list of service worker SRI pins for popular origins providing cryptographic applications.

If you're proposing we use WebExtensions as failsafe-canaries/breakers/SPoF-custodians for high-stakes web applications, aren't there ways to achieve that under the ecosystem as it **currently exists**, without implementing any new browser functionality proposals? \(e.g. [auditing ServiceWorker installations before they occur](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData#:~:text=webRequestFilterResponse.serviceWorkerScript)\)

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

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

Received on Wednesday, 4 October 2023 20:39:47 UTC