Bug 61138 - Support Resource Timing API
: Support Resource Timing API
Status: ASSIGNED
: WebKit
Platform
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
: http://w3c-test.org/webperf/specs/Res...
:
: 61152 84883 84885 84886 85026
: 91412 96107
  Show dependency treegraph
 
Reported: 2011-05-19 12:44 PST by
Modified: 2013-07-28 21:07 PST (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2011-05-19 12:44:23 PST
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 From 2011-05-19 17:36:23 PST -------
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 From 2011-05-19 17:43:36 PST -------
(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 From 2011-05-19 18:02:33 PST -------
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 From 2011-05-19 18:20:38 PST -------
(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 From 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 From 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 From 2012-03-16 13:28:22 PST -------
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 From 2012-03-21 15:05:33 PST -------
I think it's just a matter of someone (probably me) implementing it. I'll try to get to it "soon."
------- Comment #9 From 2012-03-22 07:04:58 PST -------
Thanks James. I'll stay tuned to this and bug 61152.
------- Comment #10 From 2012-04-24 11:33:50 PST -------
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 From 2012-04-24 11:42:12 PST -------
(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 From 2012-06-01 07:51:02 PST -------
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.