- From: James <notifications@github.com>
- Date: Wed, 04 Oct 2023 13:39:42 -0700
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/1680/1747606040@github.com>
> 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