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

RE: [Open Issue] Privacy concern with Navigation Timing

From: Anderson Quach <aquach@microsoft.com>
Date: Wed, 27 Oct 2010 00:05:19 +0000
To: Tony Gentilcore <tonyg@google.com>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <1E1FF4102DEA7A40AF9CC342044ECE5D2E225B74@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Through our security / privacy review, we focused on two navigation scenarios:


        I.            The navigation started on the same domain as the target page via a redirector service. E.g. A.com --> B.com [3xx] --> B.com [3xx] --> A.com [200]

      II.            The navigation started on a different domain than the target page.  B.com --> A.com

For the purposes of the result, both scenarios I & II are treated as cross-origin timing. Here are the following recommendations as they relate to the topics in this mail.


1.       Agreed, redirect Count should be made available  for the same-origin redirection chains, zero otherwise.



3.       Providing a UI feature to disable the web timing interfaces should be made a non-normative requirements, as each browser is going to be implementing the disable feature in a number of different ways. While the interface is disabled, the recommendation is to return null when accessing window.performance.timing; and window.performance.navigation;



4.       navigationStart, redirectStart, and redirectEnd

unloadEventStart, unloadEventEnd



Our security team has recommended that we zero out navigationStart, redirectStart and redirectEnd along with unloadEventStart and unloadEventEnd in order not to provide additional means for information disclosure attacks in cases of different origins and different origin redirect chains.

Anderson Quach
IE Program Manager

From: Tony Gentilcore [mailto:tonyg@google.com]
Sent: Monday, October 25, 2010 11:18 AM
To: Anderson Quach
Cc: public-web-perf@w3.org
Subject: Re: [Open Issue] Privacy concern with Navigation Timing

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<mailto: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> [mailto: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<mailto: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<http://a.com>) may perform redirections when navigating to the target/current page (b.com<http://b.com>). Thus, b.com<http://b.com> has access to specific timing information that is associated with redirections of a.com<http://a.com>.

redirectCount
This attribute is related to redirectStart and redirectEnd, revealing the number of redirects while navigating from a.com<http://a.com> to b.com<http://b.com>. Thus, the target/current page (b.com<http://b.com>) has access to the number of redirections associated with previous page (a.com<http://a.com>).

unloadEventStart
unloadEventEnd
After committing the navigation, the previous page (a.com<http://a.com>) may have an unload event handler while navigating to the target/current page (b.com<http://b.com>). Thus, b.com<http://b.com> has access to how long a.com<http://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 Wednesday, 27 October 2010 00:06:48 GMT

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