Re: [NavigationTiming] Finalizing NavigationTiming

    Thanks for the great input, Anderson.

    Discussion in
[1]<http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0068.html>has
left some corner cases unspecified, which I'd like to close in
Question
1).

* "b. If the navigationStart and fetchStart are of the same origin and the
redirect chain is of the same origin or no redirect chain, the site
developer has all the attributes."*

Shouldn't "the redirect chain is of the same origin" imply that
"navigationStart" and "fetchStart" are of the same origin already?
Currently, a redirect chain is defined
as "same origin" iff all the pages within the redirect are from the same
origin. So redirect like PageA---PageB----PageA is cross-origin.

Also another corner case didn't get covered by this description. Even in a
same-origin redirect, unloadEventStart and unloadEventEnd are still
guarded by another principle: if the previous page and the current page are
from different origins, these two variables are not available.
    Otherwise, I've updated the draft according to the rest of the feedback
here.

cheers,
Zhiheng

On Fri, Feb 11, 2011 at 6:18 PM, Anderson Quach <aquach@microsoft.com>wrote:

> 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>* -------click----> *<a.com>* ------redirect---->
> *<b.com>* ------redirect-----> *<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
>