Re: [Open Issue] Privacy concern with Navigation Timing

On Tue, Oct 26, 2010 at 5:05 PM, Anderson Quach <aquach@microsoft.com>wrote:

> 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.
>
I don't suspect this matters, but I'm curious whether they deemed that these
attributes expose a novel privacy exploit or if it is undesirable to
solidify existing ones.

In any case, I guess that makes fetchStart the new earliest time that apps
can reliably measure from, and these 5 additional details will just be
available on same domain navigations.

If that's the case, should we reconsider any names? I suspect these would be
the new most common metrics:

var timing = window.performance.timing;
var myPageLoadTime = timing.loadEventEnd - timing.fetchStart;
if (timing.navigationStart) {
  var myUserPerceivedLoadTime = timing.loadEventEnd -
timing.navigationStart;
}


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