#958: Timing Info for ServiceWorker static routing API
Discussions
2024-06-17
Dan: explainer missing a security & privacy section...
Martin: cache is a shared resource... It's worth nudging...
<blockquote>Hi @quasi-mod - thanks for sending us this. One thing that came up immediately in our initial discussion was the lack of a security & privacy discussion in the explainer (info on writing explainers). It seems that since this is dealing with timing, there might be some additional security issues that need to be explored or discussed beyond what was done already for Static Routing API. This is probably fine, but anything that touches timing carries some risk, particularly when it touches on resources that might be shared, like caches.
We're continuing to discuss and will provide additional feedback.
</blockquote>Martin: this looks totally fine other than that... as Yves pointed out it's probably partitioned...
2024-07-29
Dan: should we abstain on this one?
Martin: I think saying "pass" would be a reasonable thing... the explainer is pretty good as far as i can see.
Thanks for raising this issue. We discussed this proposal in a breakout session and decided that we would decline to review in this case. This work looks broadly reasonable, but the best course of action we can recommend is to continue to work on having the Web Performance Working Group take up this work.
OpenedMay 28, 2024
こんにちは TAG-さん!
I'm requesting a TAG review of Timing Info for ServiceWorker static routing API.
Service Worker provides timing information to mark certain points in time. This is exposed and used by the navigation timing API as well as the resource timing API. It currently records two times:
However, it currently does not have any fields related to the ServiceWorker Static Routing API. Developers would benefit from having fields that provide information such as:
This information will allow developers to measure the latency incurred by the API such as router evaluation time or time required to conduct cache lookup, or determine if the matched source is the final source used (can find out if the matched source failed to get the resource or not, and which source was used as the alternative).
Explainer: url
User research: It is a well-studied phenomenon that faster sites are better for users, and timing info APIs are used for measurement to evaluate their sites, but we have not conducted any user studies specifically on this feature. We often get some feedback from partners about logging and debugging difficulties of the API.
Security and Privacy self-review²: No change from original static routing API proposal (link)
GitHub repo: url
Primary contacts (and their relationship to the specification):
Organization/project driving the design: Google Chrome
External status/issue trackers for this feature:
ChromeStatus
Mozilla Standards Position
WebKit Standards Position
Further details:
You should also know that...
[please tell us anything you think is relevant to this review]