W3C home > Mailing lists > Public > public-web-perf@w3.org > October 2010

Re: [Open Issue] Privacy concern with Navigation Timing

From: Tony Gentilcore <tonyg@google.com>
Date: Mon, 25 Oct 2010 11:18:26 -0700
Message-ID: <AANLkTinR_DFr0cLvEputkxD1pcxbj-ZFCK7QhS0nUax9@mail.gmail.com>
To: Anderson Quach <aquach@microsoft.com>
Cc: "public-web-perf@w3.org" <public-web-perf@w3.org>
The Chrome security and privacy teams have reviewed the Navigation Timing
API and have suggested three changes.

1. To the interface: redirectCount should only be exposed for same-origin
redirection chains.

2. To the spec: It is important that the specification explicitly detail the
privacy concerns associated with each attribute and the existing mechanisms
through which that information is exposed. This will avoid a future security
researcher "discovering" concerns which were considered in the initial
design.

3. To the Chrome implementation: Add a command line flag for the very
privacy conscious to disable this interface (just like we do for <a ping>).
While we don't believe these are new privacy issues, it allows users to make
that decision for themselves if they feel strongly otherwise.

With these exceptions, the consensus is that the interface makes some timing
based privacy holes more explicit. However, all of the information is
available through other means. It is unfortunate that this further
solidifies the timing based privacy holes, but because it is highly unlikely
that anything can be done to mitigate the existing holes, it isn't worth
holding back this feature.

navigationStart
redirectStart
redirectEnd
These fields expose cross-origin timing. As described by
http://www2007.org/papers/paper555.pdf, timing heuristics may be used to
determine whether a user has visited another site, is logged in to another
site, and other details such as the number of items in a user's shopping
cart. Cross-origin timing heuristics can be gathered in a number of ways
without this API, most notably by creating a cross-origin iframe or image
and timing to the resource's onerror or onload event. eg.
<body><script>
var img = new Image();
var start = new Date();
img.onerror = function() { alert(new Date() - start) };
img.src = 'http://www.example.com/'
document.body.appendChild(img);
</script>

unloadEventStart
unloadEventEnd
Unload event time can be measured by loading the target page in an iframe
then navigating to a trivial page in the iframe's onload event and tracking
the time until the new page's onload. eg.
<iframe src="http://www.example.com/" onload="var start=new
Date();this.onload=function(){alert(new Date() -
start)};this.src='about:blank'"></iframe>

redirectCount
No concern now that it is guarded by same-origin check.

-Tony

On Fri, Oct 15, 2010 at 1:38 PM, 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
>
Received on Monday, 25 October 2010 18:19:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 21 December 2010 18:13:55 GMT