Re: [NavigationTiming] navigationStart in Cross-origin redirects

On Tue, Apr 5, 2011 at 12:36 PM, Nic Jansma <Nic.Jansma@microsoft.com>wrote:

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

   what I meant here is pointing the source to the first search result link
(or whichever link that would end up within my domain).


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

   There is difference between exposing navigationTiming and redirect
timing. navigationStart doesn't
directly tell if there is redirect involved or not. (From that perspective,
it's better to make navigationStart always
available.) One can always guess but, imo, the information is obfuscated
enough in most case.


>
> (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).
>

    Yeah, I really don't like going fore-and-back on previous decision
either... :-( But missing a big piece of the goal of this
work is a let-down and we should address it while we still can.

thanks,
Zhiheng



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