Bug 61138 - Support Resource Timing API
: Support Resource Timing API
Status: ASSIGNED
Product: WebKit
Classification: Unclassified
Component: Platform
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To: James Simonsen
http://w3c-test.org/webperf/specs/Res...
:
Depends on: 84883 61152 84885 84886 85026
Blocks: 96107 91412
  Show dependency treegraph
 
Reported: 2011-05-19 12:44 PDT by James Simonsen
Modified: 2013-07-28 21:07 PDT (History)
11 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.