RE: [NavigationTiming] navigationStart in Cross-origin redirects

> A determined one can already estimate navigationStart with other technique right now so we are not leaking additional
> info by exposing it. In fact, if we hide navigationStart in the cross-origin case, it is a good indication that there is a redirect
> involve even if we zero out redirectStart/End/Count.

As you suggest, in the case of constructing an IFRAME on a page and navigating to it, you can estimate navigationStart.  However, there's also the case that you've been navigated *to* from another referrer.

For example, let's say a user is on a search engine, they find your site as the first search result, and they navigate to your site.  If the user is logged in to the search engine, the search engine 302 redirects through themself (to help you keep track of your search history) then to your site.

If we exposed navigationStart in this case, along with the HTTP Referrer, the destination page can tell that the user was logged into the search engine. This is a concocted example, but I think it captures one scenario that we are protecting against.

I think Jonas brought this up initially at the first F2F last year -- Jonas, do you have other thoughts?

- Nic

From: Zhiheng Wang [mailto:zhihengw@google.com] 
Sent: Tuesday, April 05, 2011 11:02 AM
To: Nic Jansma
Cc: Tony Gentilcore; Sigbjørn Vik; public-web-perf
Subject: Re: [NavigationTiming] navigationStart in Cross-origin redirects


On Tue, Apr 5, 2011 at 10:33 AM, Nic Jansma <Nic.Jansma@microsoft.com> wrote:
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).

   A determined one can already estimate navigationStart with other technique right now so we are not leaking additional
info by exposing it. In fact, if we hide navigationStart in the cross-origin case, it is a good indication that there is a redirect
involve even if we zero out redirectStart/End/Count. 

 

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?

   yes, once we come to the conclusion of this question. :-)

thanks,
Zhiheng

 

- 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 18:19:14 UTC