Timing Info for ServiceWorker static routing API

[quasi-mod]

こんにちは 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:

• Start time
• Fetch event dispatch time

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:

• the matched route (the route that the Static Routing API evaluated)
• the actual source from which the resource was retrieved
• the time it took to match the route
• the time to look up the cache for the cache source

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):

  • Keita Suzuki (@quasi-mod), Google
  • Yoshisato Yanagisawa (@yoshisatoyanagisawa), Google

• Organization/project driving the design: Google Chrome

• External status/issue trackers for this feature:

• ChromeStatus

• Mozilla Standards Position

• WebKit Standards Position

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): Web Incubator Community Group
• The group where standardization of this work is intended to be done ("unknown" if not known): Web Performance Working Group and possibly Service Workers Working Group
• Existing major pieces of multi-stakeholder review or discussion of this design: not available yet
• Major unresolved issues with or opposition to this design: n/a
• This work is being funded by: Google

You should also know that...

[please tell us anything you think is relevant to this review]

[torgo]

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.

[torgo]

Hi @quasi-mod could you please add a security & privacy consideration section, including some info on abuse cases, and also can you add some user needs at the top of the explainer (how does this benefit end users), before discussion of the background ?

[quasi-mod]

Hi @torgo. Thanks for looking into our proposal!
I will add the security & privacy concern in to the explainer, and will let you know as soon as its ready.

[quasi-mod]

Hi, just a FYI, but we have merged the User needs section to the explainer, and are currently working on a security & privacy concern section, which is undergoing a review (Draft PR: WICG/service-worker-static-routing-api#30).

We will notify you once we merge the PR. Thanks!

[martinthomson]

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.