W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2011

Re: [NavigationTiming] navigationStart in Cross-origin redirects

From: Zhiheng Wang <zhihengw@google.com>
Date: Tue, 5 Apr 2011 11:02:01 -0700
Message-ID: <BANLkTint+Sd6USCgxj8GNz-RCi6COJEHiQ@mail.gmail.com>
To: Nic Jansma <Nic.Jansma@microsoft.com>
Cc: Tony Gentilcore <tonyg@google.com>, Sigbjørn Vik <sigbjorn@opera.com>, public-web-perf <public-web-perf@w3.org>
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:02:27 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC