RE: [NavigationTiming] navigationStart in Cross-origin redirects

The problem with navigationStart is that it is logically equivalent to, if not exactly the same as, redirectStart for redirected navigations.

Since we've decided that redirectStart should be protected by SOP, we should apply the same SOP to navigationStart (in the case of redirected navigations).

Otherwise, if we provided navigationStart in a cross-origin redirected navigation, combined with the not-SOP-protected fetchStart, we've essentially given a backdoor to redirectStart(=navigationStart) and redirectEnd(=fetchStart). 

Note:  Zeroing out navigationStart with cross-origin redirections is not captured in the Processing Model step 16.a.  Zhiheng, would you be able to update the spec?

- Nic

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Tony Gentilcore
Sent: Tuesday, April 05, 2011 9:35 AM
To: Sigbjørn Vik
Cc: public-web-perf
Subject: Re: [NavigationTiming] navigationStart in Cross-origin redirects

On Tue, Apr 5, 2011 at 3:23 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:
> On Mon, 04 Apr 2011 19:37:50 +0200, Zhiheng Wang <zhihengw@google.com>
> wrote:
>
>>   Meanwhile, by timing iframe loading time and other techniques, a 
>> malicious page can already estimate the time it takes to load a page 
>> including HTTP redirects so exposing navigationStart doesn't make it 
>> worse in terms of user privacy
>>
>> [4]<http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0066.html>.
>> So
>> I would propose
>> to lift the SOP constraint on navigationStart in case of redirect.
>>
>>   Thoughts and comments?
>
> I cannot immediately think of any reasons we have to block 
> navigationStart, so should be fine with me.

+1

The initial Chrome implementation didn't block navigationStart for cross origin redirects and the internal security/privacy review was okay with that. I'm interested to hear whether IE and FF are comfortable exposing it in this case.

>
>>   On a related note, I can't think of a real-life example where 
>> domain A redirects to domain B while exposing the redirect time and 
>> count on domain A is harmful, given that only HTTP redirects are considered here.
>> Any one can provide a case for it? We should include it in the spec.
>
> Many sites will redirect a visitor differently depending on the user 
> being logged in/having a cookie or not. There might be one extra 
> redirection step to set a cookie, even before a site redirects a 
> visitor to the final destination. The presence of the extra 
> redirection step will leak information about a user's history. Exact 
> redirect timings will also reveal if any DNS information is cached.
>
> --
> Sigbjørn Vik
> Quality Assurance
> Opera Software
>
>

Received on Tuesday, 5 April 2011 17:33:57 UTC