RE: [ResourceTiming] startTime definition

With Navigation Timing, data on whether an extra redirection occurred could give information away on whether a user was logged into the referring site, as some sites will redirect a visitor differently depending on whether the user was logged in/have a cookie or not. That discussion is captured here: http://lists.w3.org/Archives/Public/public-web-perf/2011Apr/0014.html.

However, with most resources that previous concern doesn't exist. With Resource Timing, I think it's more about being conservative and not sharing timing information of cross-origin pages unless they opt into providing that information.



I think setting all attributes to zero in this case will be overkill. Seems like that leaves us with setting startTime, for all redirections, to be the time immediately before the user agent starts to queue the fetch that initiates the redirect process for the resource. This definition won't breakdown the redirection time and someone inspecting that value won't be able to differentiate whether the delay was caused by queuing the resource for fetching or the redirection.



Considering the current spec definition doesn't take the time of queuing into account for the redirection case, how does the following proposed update for the startTime definition sound?


"The startTime attribute must return a DOMHighResTimeStamp<http://www.w3.org/TR/hr-time/#domhighrestimestamp> with the time immediately before the user agent starts to queue the resource for fetching<http://www.w3.org/TR/html5/fetching-resources.html#fetch>. If there are HTTP redirects or equivalent<http://www.w3.org/TR/html5/fetching-resources.html#concept-http-equivalent-codes> when fetching the resource, this attribute must return a DOMHighResTimeStamp<http://www.w3.org/TR/hr-time/#domhighrestimestamp> with the time immediately before the user agent starts to queue the fetch<http://www.w3.org/TR/html5/fetching-resources.html#fetch> that initiates the redirect process for the resource."


Thanks,
Jatinder