Re: [ResourceTiming] startTime definition

On Tue, May 15, 2012 at 11:56 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 5/15/12 2:40 PM, Jatinder Mann wrote:
>
>> For that reason, this text expectedly calls out that for redirects that
>>> are same-origin or have met the Timing-Allow-Origin rules, startTime will
>>> be the time of queuing the fetch of the resource that initiates the
>>> redirect process and when any of the redirects are not same-origin and the
>>> Timing-Allow-Origin rules have not been met, startTime will be the time of
>>> queuing the fetch of the final resource from the redirect process.
>>
>>
> I don't understand why this helps.  Maybe I'm just not understanding the
> attack scenario here?
>
> It seems like the basic setup here is that the page makes a request to URL
> A, which redirects to URL B.  A is not same-origin with the page. We want
> to not expose timing information about A's handling of the request to the
> page?
>
> If startTime is set to the time the fetch of B is queued, then simply
> subtracting from that startTime the time the initial load was handed off to
> the browser will give a pretty good idea of how long A took to handle the
> redirect.
>
> If startTime is set to the time the fetch of A is queued, then you can
> measure the total time taken for the fetches of A and B together, but not
> separately.   This seems to leak less information about A.
>

Yeah, this was my recollection of the intent. startTime should be recorded
when A is queued. That's the equivalent of what someone could do with
JavaScript already.

Of course the really secure thing here seems to be to set startTime to 0,
> just like the redirect* attributes.
>

For the sake of the timeline, we always want to have startTime and duration
populated. These should indicate when the resource was requested and the
response was processed, which is what you would get if you timed it
yourself from JavaScript.

If we're concerned about leaking information, we should zero out the other
values, since those are the new bits of information that users don't have
available now.

James