#317: FetchEvent Worker Timing

Visit on Github.

Opened Oct 30, 2018

こんにちはTAG！

I'm requesting a TAG review of:

Further details (optional):

  • Relevant time constraints or deadlines: I plan to implement in Q4 2018. Ideally I'd like to have an implementation in chrome 72 to run as an origin trial in Q1 2019.

You should also know that...

This is an early review at the intent to implement stage. I intend to write WPT tests and a more formal spec as part of implementation.

This explainer was presented to both the service worker and web performance working groups at TPAC 2018. Feedback was incorporated from the WebPerf WG.

We'd prefer the TAG provide feedback as (please select one):

  • open a single issue in our Github repo for the entire review

Discussions

Comment by @lknik Jan 14, 2019 (See Github)

Hi @wanderview and thanks for the submission. I'm wondering, if you looked at any potential privacy implications, or possibly identified any?

Comment by @wanderview Jan 14, 2019 (See Github)

I did consider privacy concerns, but I don't see any currently.

This proposal is not exposing any new information that is not already available to the site or service worker. Its more of a plumbing change making it easier for the site to collate and report the information it can already measure in the service worker.

I don't think there is any additional privacy exposure from this kind of change, but I'm open to feedback if anyone has a specific use case they are concerned about.

Comment by @torgo Feb 6, 2019 (See Github)

We're very happy to see the detail in the explainer, including the goals, non-goals, scenarios and derived user benefit. @wanderview can you put what you wrote above into the explainer in a privacy & considerations section?

Comment by @slightlyoff Feb 6, 2019 (See Github)

Love, love, love this explainer! So well done.

This solves a real-world problem that I've seen complex sites have and integrates well with the existing logging infrastructure in the platform. Agree with @torgo that what you wrote above regarding exposing new information (or not) would be a great addition to the document itself.

With those nits, consider this a clean bill of health. Excited to see this feature move forward!

Comment by @wanderview Feb 6, 2019 (See Github)

Done. Thanks for the review!

By the way, should a privacy section be added to the tag explainer template here?

https://github.com/w3ctag/w3ctag.github.io/blob/master/explainers.md