RE: [Open Issue] Privacy concern with Navigation Timing

Hi Sigbjørn,

Thanks for your insight into the matter. In fact, we would love for you to join our weekly call tomorrow 10/20/2010  9:00PST the W3C Web Performance Working Group Meeting. 

The call-in information is as follows:
+1.617.761.6200, +33.4.26.46.79.03 and +44.203.318.0479.
Passcode 97373 (WPERF)
IRC channel #webperf on irc.w3.org:6665   http://irc.w3.org/

It may be interesting to consider the sameDomainDirectCount in all cases or even remove the redirectCount attribute given the variety of attacks that can be construed with exploiting a redirection service and observing redirectCount. 

In recent discussions, Jonas brought up this example: A constructs a page that redirects with B back to A. If B redirects through C the user is logged on to site B and if it does not then they are quickly shuttled to A.

For example, A can just learned something new with redirectCount.
i. A->B->C->A  e.g. user is logged on B
ii. A->B->A e.g. user is not logged on B

Thanks,
Anderson Quach
IE Program Manager

-----Original Message-----
From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Sigbjørn Vik
Sent: Tuesday, October 19, 2010 5:00 AM
To: public-web-perf@w3.org
Subject: Re: [Open Issue] Privacy concern with Navigation Timing

I am quite uncertain about giving Web pages access to third party timing information. Even indirect timing information can reveal various things about the other site. Redirects and (un)load times typically reveal logged-in status, which is useful for phishers.

A lot of sites do redirects to set and check cookies, and forwarding based on the authentication level. There have been security bugs where being able to count the number of redirects of a third party site causes an attacker to be able to tell which sites a user is logged into, and thus to better personalize a spoof or phishing attempt. The Timing interfaces can only be seen from the domain a redirect chain ends up, so abuse is limited, but considering that many Web sites in the wild have redirectors
(http://domain/redirectTo.php?url=http://ad.otherdomain/9xt.html) that allow arbitrary end URLs, this might be possible to abuse. Send an iframe to such a redirector, ending back up at the original domain, and count the number of redirects. Rinse and repeat for a number of domains, and the attacker will have a list of Web sites to which the user is currently logged in. So redirectCount should probably behave as sameDomainRedirectCount instead.

Even navigationStart or redirectStart can reveal some of these issues, at a slightly more fine grained level than the time when the .src of the iframe is set in JavaScript. These aren't really critical though, but would still be nice to limit to same domain as well, along with all other JavaScript information.

Getting the full time an unload takes also allows one to check if a user is logged in. Stuff facebook into an iframe, and then time how long it takes to unload. If it is fast, the user saw the front page, if it was slow, the user was logged in. If an attacker has intimate knowledge of a browser (and e.g. knows that unloadEventStart always starts 5ms after response), just knowing unloadEventEnd suffices.

JavaScript has a general same domain policy, and undermining that policy little by little probably does no good in the long run. I'd rather see Timing specifications stick to the same-domain policy. If we want off-domain information to be available, it should be perfectly possible to spec out how it can be made available to development tools on the local computer.

There are real usecases for knowing how long the redirects took, for instance when clicking on ads which go through several layers of redirectors before ending up on the advertised page. However, for cooperating Web sites, passing information along, e.g. in the query field, is fully doable, so I am not certain that usecase is one we should aim to cater for. Usecases for domain.com redirecting to www.domain.com might be worthwhile though, so maybe we could allow such things. E.g. if the site succeeds in setting document.domain to domain.com, then it gets access to all timing information for all domain.com subresources. Such a solution could also be reused in development tools, by allowing them to set document.domain to '*'.

Notes on the graph:
unLoadEventStart in the graph has a capital "L", it should be lowercase.
There might be a gap between responseEnd and the document loading phase  
(for instance if the browser is prioritizing streaming a resource and CPU  
cannot handle any more at the moment). Maybe the graph should show such a  
gap?

On Fri, 15 Oct 2010 22:38:32 +0200, Anderson Quach <aquach@microsoft.com>  
wrote:

> [Addendum] The phase associated with unloadEventStart and unloadEventEnd  
> is onUnload, not onLoad. Thanks Tony for catching that typo.
>
> From: public-web-perf-request@w3.org  
> [mailto:public-web-perf-request@w3.org] On Behalf Of Anderson Quach
> Sent: Friday, October 15, 2010 11:47 AM
> To: public-web-perf@w3.org
> Subject: [Open Issue] Privacy concern with Navigation Timing
>
> Hi All,
>
> We're calling for input on a matter of privacy concerns with Navigation  
> Timing. The follow attributes are being vetted to understand the threat  
> with exposing Navigation Timing [1] attributes that can reveal to an  
> attacking site what an end-user is doing in a particular session.
>
> (Please see the attached png for a visual representation of the timeline)
>
> navigationStart
> The issue with this timing marker is that it reveals the absolute start  
> point of the navigation, which may include the timing phase associated  
> with redirection and the time spent in the unload event.
>
> redirectStart
> redirectEnd
> After committing the navigation, the previous page (a.com) may perform  
> redirections when navigating to the target/current page (b.com). Thus,  
> b.com has access to specific timing information that is associated with  
> redirections of a.com.
>
> redirectCount
> This attribute is related to redirectStart and redirectEnd, revealing  
> the number of redirects while navigating from a.com to b.com. Thus, the  
> target/current page (b.com) has access to the number of redirections  
> associated with previous page (a.com).
>
> unloadEventStart
> unloadEventEnd
> After committing the navigation, the previous page (a.com) may have an  
> unload event handler while navigating to the target/current page  
> (b.com). Thus, b.com has access to how long a.com's unload handler took  
> to execute.
>
> [1]  
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html
>
> Thanks,
> Anderson Quach
> IE Program Manager


-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Wednesday, 20 October 2010 01:22:10 UTC