Re: [w3c/ServiceWorker] Add race-network-and-cache source to static routing api. (PR #1764)

yoshisatoyanagisawa left a comment (w3c/ServiceWorker#1764)

Let me answer one by one.

I think the Resource Timing API should also be updated to help web developers to use the API properly.

> How is a web application knowledgeable enough to properly choose cache vs. race-cache-and-network?

If [the elapsed time](https://github.com/WICG/service-worker-static-routing-api/blob/main/resource-timing-api.md#cache-rule-specified) between `cacheLookupStart` and `responseStart` is large, the cache storage access can be slow.  The `race-network-and-cache` can be chosen for the case.

> A UA can implement race-network-and-cache by using the existing cache route implementation. This approach might actually be useful in some conditions (metered connection e.g.). AFAIUI, the web application will have no way of identifying the UA did an actual race or not.

I think this can be guessed from the resource timing API.  Especially seeing the [workerFinalRouterSource](https://www.w3.org/TR/resource-timing/#dom-performanceresourcetiming-workerfinalroutersource) ratio.

> A UA can already start the network load without waiting for the cache. This is a partial race (it cannot use the network response before knowing whether there is a cache entry), but can it solve the perf issue? Should we consider allowing the cache route to be fully raceable with network by default?

Since [ServiceWorkerAutoPreload](https://github.com/WICG/service-worker-auto-preload) has been around for a while, there may not actually be much resistance to racing, but I think the current cache behavior will leave web developers with an explicit choice to prioritize the cache. i.e. no network access if the cache is available.

> Are there privacy concerns? For instance, can a web application infer, from the selected route, new information (slow hard drive vs. networking)? Does this reveal new HW/config information? Could this be used by two pages running on the device as a side-information channel (one using intensively hard drive for instance, and the other one checking whether network or cache is used)?

I think this is the equivalent attack surface with the fetch handler.  The service worker static routing API is offloading of the traditional fetch handler.  We keep this offloading principle as much as possible.  With the race-network-and-cache, the web application can guess the user's device situation like disk access performance and network access performance.  However, the same thing can be done with the fetch handler.

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

Message ID: <w3c/ServiceWorker/pull/1764/c3858628372@github.com>