Re: [Open Issue] Privacy concern with Navigation Timing

Hi

I had a look through the spec on  
http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html  
with security glasses, but couldn't see any real issues other than those  
which have already been raised. There is a potential privacy issue by  
telling a site how the user navigated there (navigation type), but not  
serious, see below.

A couple of other issues where I see some room for confusion though:

"var latency = now - performance.timing.navigationStart;
alert("User-perceived page loading time: " + latency);"
The JS variable measures network latency+document loading time, so it  
should probably be renamed.

"Without otherwise specified"
*Unless* otherwise specified

I see the following note:
"Note: The relaxed same orgin policy doesn't provide sufficient protection  
against unauthorized visits accross documents. In shared hosting, an  
untrusted third party is able to host an HTTP server at the same IP  
address but on a different port."
I must have missed this discussion, this is similar to the mail just sent  
about cookie domains (here called relaxed same origin). I am not quite  
sure I understand what "unauthorized visits accross documents" means?

Navigation types - these seem a bit underspecified. E.g. automatic types  
are missing. What about a JS timeout that redirects a user? A window  
popup? Meta refresh to reload or move elsewhere? I am not sure if these  
and friends should go into type_navigate or type_reserved (or possibly  
even type_reload in the case of a meta refresh to self). What does "the  
reload operation" refer to (we used to have about 5 different reload  
operations in Opera, and still have two exposed in the UI)? Would a better  
name for type_back_forward be type_history_navigation? Note that back and  
forward aren't necessarily well defined either, instant back, conditional  
get, and full get might give three different results. I would consider it  
none of the site's business to know how I got there, if the second time I  
visited it I did it via the same link as the first time, via the forwards  
button, or in a new tab. Sometimes this can be determined through a change  
in the HTTP headers sent, but apart from that, this might be information  
users would like to keep private. Maybe the types should be defined in  
terms of which HTTP headers the browser sent instead? If-modified-since =  
conditional, cache-control:no-cache/maxage=0 = reload, neither = fresh,  
none (e.g. instant back or reload from cache) = the same as last time -  
that way we aren't revealing anything to the server which the server  
doesn't already know, and the types might be more useful for a site  
developer. A back navigation could be either one of the above, depending  
on circumstances, and that doesn't seem very telling for the developer.

That brings up another question, are meta refreshes counted as redirects?  
Only if the timeout is 0? (The spec says HTTP redirect <or equivalent>,  
but the link only defines transport level equivalencies, it doesn't say  
anything about document redirects. Though I would define a meta refresh  
with a 0 timeout as functionally equivalent to a HTTP redirect.) What  
about JS which redirects immediately? To be useful to developers, any kind  
of redirects should be counted (including the page which detects if JS is  
enabled, and redirects elsewhere based on that), but that could be  
troublesome to implement. A clarification in the spec would be good  
though, "redirect" is used multiple places, but not explicitly defined  
anywhere.

"If no domain lookup is required, go to step 11. Otherwise, immediately  
before a user agent starts the domain name lookup, record the time as  
domainLookupStart."
This gets confusing in the case of a half-finished DNS prefetch.

-- 
Sigbjørn Vik
Quality Assurance
Opera Software


On Fri, 15 Oct 2010 20:46:30 +0200, Anderson Quach <aquach@microsoft.com>  
wrote:

> 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 Thursday, 21 October 2010 14:46:55 UTC