Re: [Open Issue] Privacy concern with Navigation Timing

On Thu, Oct 21, 2010 at 7:46 AM, Sigbjørn Vik <sigbjorn@opera.com> wrote:

> Hi
>
> I had a look through the spec on
> http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.htmlwith 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.


   Could you please elaborate here?

thanks,
Zhiheng


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