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 Tuesday, 19 October 2010 12:00:03 UTC