Bug 61138 – Support Resource Timing API

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Platform

[James Simonsen]

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.

[Alexey Proskuryakov]

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.

[James Simonsen]

(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.

[Alexey Proskuryakov]

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.

[James Simonsen]

(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.

[James Simonsen]

(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.

[Tony Gentilcore]

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.

[Darin Wright]

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.

[James Simonsen]

I think it's just a matter of someone (probably me) implementing it. I'll try to get to it "soon."

[Darin Wright]

Thanks James. I'll stay tuned to this and bug 61152.

[Darin Wright]

Hi James - just wondering if resource timing has hit any more road blocks, or if it's just on the back burner. Thanks.

[James Simonsen]

(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.

[Darin Wright]

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.

[Iraê]

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.

[Iraê]

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.

[Dean Jackson]

<rdar://problem/21757195>]

[Blaze Burg]

Fixed in the past year, closing.

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