RE: [NavigationTiming] Finalizing NavigationTiming

Regarding 1), Yes, this is what we have discussed in on 10/27/2010. [1]
> The attributes navigationStart, redirectStart, redirectEnd, unloadEventStart, and unloadEventEnd will zero out in cross-origin navigations and non-same redirection chain. The rationale is that this is explicitly providing information about the previous domain previously not easily accessible and will enable site developers to glean information about end-users visiting their site.

2) Yes, navigationStart was discussed on 10/27/2010 [1]
>If the navigationStart and fetchStart are of different origins and there is a redirection chain the following attributes are to be zero: navigationStart, redirectStart, redirectEnd, unloadEventStart, unloadEventEnd and redirectCount.

3) Yes, this was captured in the processing model as far back as 10/24/2010. [2]

[1] http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0068.html
[2] https://dvcs.w3.org/hg/webperf/raw-file/a19a40b067ae/specs/NavigationTiming/Overview.html

Recommended texts for the Privacy and Security sections:
5 Privacy
This section is non-normative.

5.1 Cross-directory accesses

Different pages sharing one host name, for example contents from different authors hosted on sites with user generated content are considered from the same origin because there is no feature to restrict the access by pathname. Navigating between these pages allows a latter page to access timing information of the previous one, such as timing regarding redirection and unload event.

6 Security
This section is non-normative.

6.1 Detecting proxy servers
In case a proxy is deployed between the user agent and the web server, the time interval between the connectStart and the connectEnd attributes indicates the delay between the user agent and the proxy instead of the web server. With that, web server can potentially infer the existence of the proxy. For SOCKS proxy, this time interval includes the proxy authentication time and time the proxy takes to connect to the web server, which obfuscate the proxy detection. In case of an HTTP proxy, the user agent might not have any knowledge about the proxy server at all so it's not always feasible to mitigate this attack.

6.2 Tampering by replacing timing objects
The window.performance object is replaceable to avoid conflicts with existing pages using the same object. By doing that, it is possible for third-party to replace the object and scripts relying on the interface described in this work would break.

6.3 Information disclosure
There is the potential for disclosing an end-user's browsing and activity history by using carefully crafted timing attacks. These attacks have been mitigated by disallowing the timing of the root document in cross-origin accesses.

Best Regards,
Anderson and Nic
Internet Explorer


From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Zhiheng Wang
Sent: Tuesday, February 08, 2011 11:39 PM
To: public-web-perf
Subject: [NavigationTiming] Finalizing NavigationTiming

Hi, folks,

   Great works on the NavigationTiming! Kudos to everyone. It proves that we don't need years to get something standardized. :-)

   There still seems to be a couple details missing from the current draft, which I would like to get clarified before moving to CR.

1. SOP
   The current spec states that
    * redirectStart/End are available only if *all* the redirects are from the same origin.
    * unloadEventStart/End are available if previous document and the current document are from the same origin
   So in the following case:
    <previous page on a.com<http://a.com>> -------click----> <a.com<http://a.com>>  ------redirect----> <b.com<http://b.com>> ------redirect-----> <a.com<http://a.com>>
     redirectStart/End are not available, but unloadEventStart/End are available. Is this what we want? This still fits our security/privacy discussion but I would like to point it out explicitly.

2. We should add that navigationStart will not be available if there is cross-origin redirects. I believe this is our decision but it is missing from the definition. (On the other hand, navigationStart will be always available if there is no redirection.)

3. It should be added that domainLookupStart/End must return the same value as fetchStart in case persistent connection is used.

   If these look fine, I will update the draft shortly.

cheers,
Zhiheng