Re: [w3c/ServiceWorker] Export Soft Update algorithm for use by other specifications (PR #1847)

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1847)

I have two main concerns regarding exporting the `Soft Update` algorithm directly:

1. **DoS and Lifecycle Thrashing:** Exposing this allows arbitrary triggers that could lead to excessive resource usage for both the browser and the site (essentially a form of DoS or lifecycle thrashing).
2. **Privacy / Security:** We need to prevent arbitrary sites or contexts from triggering an update if they somehow obtain a registration that doesn't belong to their partition.

Because external callers like FedCM genuinely need to fetch the latest script, relying on `updateViaCache` is not a viable workaround here. 

Therefore, I suggest we introduce and export a **wrapper algorithm** (e.g., `Request Soft Update`) instead of directly exporting the raw `Soft Update`.

This wrapper algorithm could do the following:
- Require the calling `environment` (or storage key) as an argument to strictly enforce a storage key match against the registration.
- Explicitly state that the browser *may* ignore or throttle the update request. This gives User Agents the authority to prevent excessive resource consumption and mitigate DoS attacks.

What do you think?


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

Message ID: <w3c/ServiceWorker/pull/1847/c5566177084@github.com>