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