Re: [ResourceTiming] startTime definition

On 5/15/12 2:40 PM, Jatinder Mann wrote:
>> I have to ask: why is the intended behavior different depending on the exact redirects involved,
>> anyway?  It seems really weird that if I fetch A which redirects to B then startTime on the result
>> will depend on the exact redirect chain from A to B...
>>
>> -Boris
>
> We want startTime to be the time of queuing a resource for fetching.

OK.  That part makes sense.

> For privacy reasons, if any of the redirects are not from the same origin and the Timing-Allow-Origin rules are not met, we zero out the redirectStart or redirectEnd times

OK.  That seems completely sensible, since it hides information about 
the redirect.

> In this particular scenario, if the startTime continues to be the time of queuing the fetch of the resource that initiates the redirect process, we in effect will have circumvented the privacy restrictions we placed on redirectStart and redirectEnd times.

Why, exactly?  This is the part I don't get...

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

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

Did I understand the attack scenario correctly?  If not, what problem 
are we trying to solve here?

-Boris

Received on Tuesday, 15 May 2012 18:57:20 UTC