Bug 61138 - Support Resource Timing API
Summary: Support Resource Timing API
Status: RESOLVED DUPLICATE of bug 30685
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: James Simonsen
URL: http://w3c-test.org/webperf/specs/Res...
Keywords: InRadar
Depends on: 61152 84883 84885 84886 85026 157133 158617
Blocks: 91412 96107
  Show dependency treegraph
 
Reported: 2011-05-19 12:44 PDT by James Simonsen
Modified: 2017-07-24 13:33 PDT (History)
15 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Simonsen 2011-05-19 12:44:23 PDT
Resource Timing is a follow up to Navigation Timing. Resource Timing exposes detailed timing information to JavaScript for subresource loaded by the page. The goal is to help web site developers collect better information about how well their site works for actual users.

This is a metabug to add support for Resource Timing. Actual tasks required for the implementation should block this bug.
Comment 1 Alexey Proskuryakov 2011-05-19 17:36:23 PDT
Being a new feature, this needs to be discussed on webkit-dev first. I couldn't find any e-mails with "Resource Timing" on the list.

This feature is highly questionable, because it sounds like it would hugely simplify timing attacks of all kinds.
Comment 2 James Simonsen 2011-05-19 17:43:36 PDT
(In reply to comment #1)
> Being a new feature, this needs to be discussed on webkit-dev first. I couldn't find any e-mails with "Resource Timing" on the list.

Sure, I'll send an e-mail.

> This feature is highly questionable, because it sounds like it would hugely simplify timing attacks of all kinds.

There are provisions to protect against this in the spec. Basically, it'll be limited to same-origin unless a CORS-like header explicitly allows the resource to be timed by another origin.
Comment 3 Alexey Proskuryakov 2011-05-19 18:02:33 PDT
There can still be timing attacks against network infrastructure (e.g. locating the user more precisely, or detecting what kind of network equipment they have). I'm curious to what degree those have been discussed during spec development.
Comment 4 James Simonsen 2011-05-19 18:20:38 PDT
(In reply to comment #3)
> There can still be timing attacks against network infrastructure (e.g. locating the user more precisely, or detecting what kind of network equipment they have). I'm curious to what degree those have been discussed during spec development.

That's a good point. This issue should also affect Navigation Timing, which provides detailed timing information for the main document. I know Navigation Timing went through a thorough security review at both Google and Microsoft, but I don't know which issues they considered. I'll try to find someone to ask about this particular point.
Comment 5 James Simonsen 2012-01-30 15:38:29 PST
(Sorry this was dropped for a while.)

The summary of the discussion on the W3C security list is here:

http://lists.w3.org/Archives/Public/public-web-security/2011Oct/0019.html

Separately, Microsoft's and Google's security teams both concluded that there are no new attack vectors. Timing attacks are already doable. The Resource Timing API makes these attacks more explicit, which could be a problem if anyone figures out how to close the other timing holes. But, since there are no plans to fix the existing holes, nobody was really worried about adding Resource Timing.
Comment 6 Tony Gentilcore 2012-01-31 04:33:41 PST
For posterity, here is the link to the webkit-dev thread where the questions were initially raised:
https://lists.webkit.org/pipermail/webkit-dev/2011-May/016803.html

Before landing anything here, we should bring it up on the list again.
Comment 7 Darin Wright 2012-03-16 13:28:22 PDT
Curious if there has been any more forward progress or setbacks in the implementation of Resource Timing? Application monitoring tools (like New Relic), are interested in leveraging the information provided by the interface.

Thanks.
Comment 8 James Simonsen 2012-03-21 15:05:33 PDT
I think it's just a matter of someone (probably me) implementing it. I'll try to get to it "soon."
Comment 9 Darin Wright 2012-03-22 07:04:58 PDT
Thanks James. I'll stay tuned to this and bug 61152.
Comment 10 Darin Wright 2012-04-24 11:33:50 PDT
Hi James - just wondering if resource timing has hit any more road blocks, or if it's just on the back burner. Thanks.
Comment 11 James Simonsen 2012-04-24 11:42:12 PDT
(In reply to comment #10)
> Hi James - just wondering if resource timing has hit any more road blocks, or if it's just on the back burner. Thanks.

Oh, sorry for not updating this. The first patch is up here:

https://bugs.webkit.org/show_bug.cgi?id=80350

I think Tony was going to take a look at it when he got a chance. That adds the Performance Timeline API that Resource Timing depends on.

After that, I'll expose Resource Timing via the API. I already have half of that ready to go, but it still needs a few more days of work.
Comment 12 Darin Wright 2012-06-01 07:51:02 PDT
Hi James - I noticed that on the latest draft/spec (http://www.w3.org/TR/resource-timing/) some of the data types have changed in the PerformanceResourceTiming interface (longs have become DOMHighResTimeStamp's and the initiatorType has changed to a DOMString).

Not sure if this affects the work already completed.
Comment 13 Iraê 2015-08-11 14:44:38 PDT
This bug is quite old, and I would like to update with a slightly new perspective: Now every other browser besides Safari has Resource Timing either implemented on accepted and being worked on. http://caniuse.com/resource-timing Having this come late, even after Internet Explorer is a bit awkward for a browser that used to be in the leading side of new standards.

Here at Yahoo we use many tools to measure performance and many of those tools are more and more compatible with Chrome and Android and a lot are dropping Safari support. I particularly work on a mobile product that 90% of the users are on Mobile Safari on iPhone, and although Navigation Timing was missing, on iOS 9 we do have it, but Resource Timing apparently has no ETA.

We would be very glad to have Resource Timing in Safari and this would allow us to use this information in so many different ways, including performance monitoring with real users and automation tools like WebPageTest.org could be updated to support that.
Comment 14 Iraê 2015-08-11 15:02:06 PDT
Sorry, I was in a hurry and submitted with second paragraph incomplete. I was about to say we had to implement a different way of measuring without resource timing, which is incomplete but works based on some browser events like DOMContentLoaded and others, but the way we validated this data can be somewhat trusted is having this implementation running on Chrome browsers alongside their resource timing API. It's becoming more and more often that we debug sites meant for Sarafi using Chrome instead, and Resource Timing is one of those APIs missing that would be very helpful.
Comment 15 Dean Jackson 2016-03-01 16:24:14 PST
<rdar://problem/21757195>]
Comment 16 Blaze Burg 2017-07-24 13:33:53 PDT
Fixed in the past year, closing.

*** This bug has been marked as a duplicate of bug 30685 ***