RE: [NavigationTiming] navigationStart in Cross-origin redirects

> Please correct me if I miss something here. Here are the two scenarios:
>
> 1) not login:  <url on the search engine result page> ===> <my page>
> 2) login:        <url on the search engine result page> ===> <search engine tracking page> ===> <my page>
>
> What I can do is to put an iframe on my page whose src points to <url on the search engine result page> and time its loading time. On
> <my page>, I can get the time when the final page is started and loaded. Comparing these gives me the same info as having
> navigationStart.

In this scenario, you'll just be measuring the load time of <url on the search engine result page>.  The user is not interacting with that page, e.g. clicking the first search result link, which triggers the second and third part of the scenario that has the redirects (<search engine tracking page> ===> <my page>).  Though maybe if the src of the iframe was <search engine tracking page> instead, that would trigger the redirect.  Then the search engine could protect against this by checking the referrer to the tracking page.

Again, my example was concocted (and may have flaws). I want to point out again that if we allow navigationStart we may as well just allow redirectStart and redirectEnd as we're indirectly exposing those times anyways (which we didn't want to do).

(I'm having a hard time arguing *for* zeroing out navigationStart as I agree with the rest of you that it is an inconvenience for developers.  The arguments I am presenting are what I believe we had previously agreed on, not something that I personally feel strongly for).

- Nic

From: Zhiheng Wang [mailto:zhihengw@google.com] 
Sent: Tuesday, April 05, 2011 12:06 PM
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 11:18 AM, Nic Jansma <Nic.Jansma@microsoft.com> wrote:
> 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.

   Please correct me if I miss something here. Here are the two scenarios:

  1) not login:  <url on the search engine result page> ===> <my page>
  2) login:        <url on the search engine result page> ===> <search engine tracking page> ===> <my page>

  What I can do is to put an iframe on my page whose src points to <url on the search engine result page> and time its loading time. On
<my page>, I can get the time when the final page is started and loaded. Comparing these gives me the same info as having
navigationStart.

  In fact, in some other cases, if we zero out navigationStart, <my page> can be sure that the time difference is caused by a redirect
to its referral domain. 

 

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

  In an early conversation among a couple participants, Jonas was generally fine with exposing navigationStart.
I could probably forward the thread here but it is better if Jonas can confirm again.

 
cheers,
Zhiheng


- 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 19:37:15 UTC