- From: Yoshisato Yanagisawa <notifications@github.com>
- Date: Sun, 18 Jan 2026 19:13:18 -0800
- To: w3c/ServiceWorker <ServiceWorker@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/ServiceWorker/issues/822/3766206024@github.com>
yoshisatoyanagisawa left a comment (w3c/ServiceWorker#822) Let me summarize the discussion until here, regarding the proposal to allow Service Workers to opt out of server-forced updates. The core of GitHub Issue #822 is a request to provide applications with a mechanism to prevent mandatory update checks, which currently occur at least every 24 hours. Proponents of this change argue that for security-sensitive applications, such as those handling private keys or end-to-end encryption (E2EE), the ability for a server to unilaterally push new code represents a significant attack surface. By controlling the update lifecycle, an application could verify the integrity and authenticity of new versions—for example, by checking for a cryptographic signature from the author—before allowing an update to proceed. However, browser vendors have expressed serious concerns that allowing a Service Worker to defeat its own upgrades could be "an attacker's dream". If a malicious script were to gain control, it could use this feature to permanently persist on a user's device by blocking any subsequent legitimate fixes. In light of these risks, the discussion has evolved toward more comprehensive solutions like Subresource Integrity (SRI) and Source Code Transparency (SCT). These efforts should be now being consolidated into the WAICT (Web Application Integrity, Consistency and Transparency) framework. Given the existing arguments, solving this through the WAICT framework appears to be the most rational path forward, as it addresses both integrity and transparency in a unified manner. However, since WAICT is still in its early "Work in Progress" and standardization alignment phase, it seems premature to conclude on a specific implementation for Issue #822 at this stage. It would be more prudent to wait for the WAICT framework to mature and provide a standardized foundation for these high-trust requirements. What do you think? -- Reply to this email directly or view it on GitHub: https://github.com/w3c/ServiceWorker/issues/822#issuecomment-3766206024 You are receiving this because you are subscribed to this thread. Message ID: <w3c/ServiceWorker/issues/822/3766206024@github.com>
Received on Monday, 19 January 2026 03:13:22 UTC