- From: Tony Gentilcore <tonyg@google.com>
- Date: Tue, 5 Apr 2011 09:34:38 -0700
- To: Sigbjørn Vik <sigbjorn@opera.com>
- Cc: public-web-perf <public-web-perf@w3.org>
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 16:35:36 UTC