Options for same-origin definition for Navigation Timing

Hi everyone,

We have several options for how we can define same-origin for the purposes of the NavigationTiming interface.  I have listed out 4 of these options, along with their advantages/disadvantages and examples below.

Summary:

*         #2 (document.domain) and #4 (CORS) have implementation complexities (in the user agent), developer/webserver configuration requirements (HTTP headers or JavaScript), and security challenges, and thus we are leaning away from using them for our definition of same-origin.


*         #1 (FQDN) and #3 (private domain) are easy to implement and do not have any developer/server configuration requirements.  #1 is more restrictive than #3.

With this in mind, we would recommend #1 or #3 for NavigationTiming.

Here are the advantages and disadvantages of the 4 options we see:


1.       As specified in the HTML5 Editor's Draft section 5.3 for origin: http://dev.w3.org/html5/spec/origin-0.html#origin

*         Two pages have the same origin if the tuple (scheme, host, port) is the same.

                                                               i.      host, in this definition, is the full host name AKA fully qualified domain name (FQDN)

*         Advantages:

                                                               i.      Simple implementation

                                                             ii.      The same-origin comparison is only needed to be done at the time of navigation and upon redirects

*         Disadvantages:

                                                               i.      Most restrictive: sibling domains and sub-domains cannot share timing data via the NavigationTiming interface (a.com and secure.a.com and www.a.com are all different)

1.       A web-developer can work around this as explained in workaround1

*         How a Web Developer would use this: The developer would not have to do anything to get this behavior, and can work around it for domains they control via cookies in a workaround1

*         Examples:

                                                               i.      a.com -> a.com: same origin

                                                             ii.      a.com -> b.com: different origin

                                                            iii.      www.a.com -> a.com: different origin

                                                           iv.      secure.a.com -> www.a.com: different origin

                                                             v.      secure.a.com -> login.a.com -> (301) secure.a.com: different origin

                                                           vi.      secure.a.com -> secure.a.com -> (301) secure.a.com: same origin



2.       As specified in the HTML5 Editor's Draft section 5.3 for origin: http://dev.w3.org/html5/spec/origin-0.html#origin, and allowing for section 5.3.1 relaxing of the same-origin restriction via setting document.domain

*         Two pages have the same origin if the tuple (scheme, domain, port) are the same.

                                                               i.      domain, in this definition, is the FQDN, but can be relaxed by setting document.domain as in section 5.3.1.

*         Advantages:

                                                               i.      Site owners could relax the security restrictions for their subdomains as they desire via document.domain

*         Disadvantages:

                                                               i.      Complex implementation.  The current page needs to keep track of the previous page's origin and document.domain.  The interface's attributes need to be updated when changing the current page's document.domain to compare to the previous page's origin and document.domain.

                                                             ii.      Cannot be used for server redirections (301, 302), as the HTTP headers cannot set the document.domain.  This would break the case of secure.a.com ->  login.a.com -> (301) www.a.com, even if secure.a.com and www.a.com both set their document.domain to a.com

                                                            iii.      Using the document.domain for the purposes of NavigationTiming affects the effective script origin for a page, which has security consequences not related to NavigationTiming.

*         How a Web Developer would use this: Setting document.domain in the previous/current pages via JavaScript (relatively easy)

*         Examples:

                                                               i.      a.com -> a.com: same origin

                                                             ii.      a.com -> b.com: different origin (and a.com cannot set its document.domain to b.com)

                                                            iii.      secure.a.com -> www.a.com: different origin

                                                           iv.      secure.a.com -> www.a.com (where secure.a.com sets its document.domain to a.com): different origin

                                                             v.      secure.a.com -> a.com (where secure.a.com sets its document.domain to a.com): same origin

                                                           vi.      secure.a.com -> www.a.com (where www.a.com sets its document.domain to a.com): different origin

                                                          vii.      secure.a.com -> www.a.com (where secure.a.com and www.a.com set their document.domain to a.com): same origin

                                                        viii.      secure.a.com -> login.a.com -> (301) www.a.com (where secure.a.com and www.a.com set their document.domain to a.com): different origin



3.       Using private domain as the origin

*         Two pages have the same origin if the tuple (scheme, private domain, port) are the same.

                                                               i.      private domain, in this definition, would be defined from as Eric Lawrence explains here: Understanding Domain Names in Internet Explorer<file:///D:\Documents\Career>

1.       Which is similar to Mozilla Foundation's Public Suffix list http://publicsuffix.org/, + 1 label

*         Advantages:

                                                               i.      Automatically works for all subdomains under the private domain without the page having to allow it via JavaScript or HTTP headers

*         Disadvantages:

                                                               i.      Loosest definition of same-origin.

                                                             ii.      Current public suffix list implementations are either heuristics or based on maintained lists, which cannot be quickly updated, and are not perfect.

                                                            iii.      Would allow different-owner sites of subdomains such as a.blogspot.com to get data about b.blogspot.com, with no way for b.blogspot.com to restrict access.

*         How a Web Developer would use this: The developer would not have to do anything to get this behavior

*         Examples:

                                                               i.      a.com -> a.com: same origin

                                                             ii.      a.com -> b.com: different origin

                                                            iii.      a.fed.us -> b.fed.us: different origin (fed.us is a public suffix)

                                                           iv.      z.a.fed.us -> x.a.fed.us: same origin (fed.us is a public suffix)

                                                             v.      secure.a.com -> a.com: same origin

                                                           vi.      x.y.z.a.b.c.a.com -> a.com: same origin

                                                          vii.      secure.a.com -> www.a.com: same origin

                                                        viii.      secure.a.com -> login.a.com -> (301) www.a.com: same origin



4.       As specified in the HTML5 Editor's Draft section 5.3 for origin: http://dev.w3.org/html5/spec/origin-0.html#origin, relaxed by CORS http://www.w3.org/TR/cors/

*         Two pages have the same origin if the tuple (scheme, host, port) are the same, which can be relaxed via CORS (eg. Access-Control-Allow-Origin)

                                                               i.      host, in this definition, is the full host name AKA fully qualified domain name (FQDN)

*         Advantages:

                                                               i.      Site owners could relax the security restrictions for their subdomains as they desire via CORS

                                                             ii.      Might be able to use it for server redirections (301, 302), as the HTTP headers can set the allowable domains.

*         Disadvantages:

                                                               i.      CORS is in Working Draft (http://www.w3.org/TR/cors/)

                                                             ii.      Not all browsers fully support CORS for all scenarios (http://en.wikipedia.org/wiki/Cross-Origin_Resource_Sharing)

                                                            iii.      CORS was intended for resources from a page, not for page-to-page navigations

1.       Any first page that wanted to allow NavigationTiming info for a destination page would have to allow it via CORS' Access-Control-Allow-Origin: http://destination.com HTTP header when the first page is generated.  The first page would have to know all of its potential exit-pages and specify them or use *.

2.       Using CORS in this way expands the security exposure for root HTML pages more than CORS originally intended

                                                           iv.      A more complex implementation, especially in the cases of redirections (as HTTP headers would have to match for all paths to the page).

*         How a Web Developer would use this: Configuring the web server or content generator to add HTTP headers (relatively complex and not always available)

*         Examples:

                                                               i.      a.com -> a.com: same origin

                                                             ii.      a.com -> b.com (where a.com does not specify Access-Control-Allow-Origin): different origin

                                                            iii.      a.com -> b.com (where a.com specifies Access-Control-Allow-Origin: http://b.com): same origin

                                                           iv.      secure.a.com -> www.a.com: different origin

                                                             v.      secure.a.com -> www.a.com (where secure.a.com specifies Access-Control-Allow-Origin: http://www.a.com): same origin

                                                           vi.      secure.a.com -> www.a.com (where www.a.com specifies Access-Control-Allow-Origin: http://secure.a.com): different origin (destination page cannot specify the header, only the previous page)

                                                          vii.      secure.a.com -> login.a.com -> (301) www.a.com (where secure.a.com specifies Access-Control-Allow-Origin: http://www.a.com and login.a.com does not): different origin

                                                        viii.      secure.a.com -> login.a.com -> (301) www.a.com (where secure.a.com and login.a.com specify Access-Control-Allow-Origin: http://www.a.com): same origin

Workaround1: If we go with #1/#3, sites may still be able to get good (but not perfect) timing data since they control all domains in the navigation path.  For example, they could use cookies to track the navigation start time.

Sorry for the verbosity but I think this level of detail is needed to get a good picture of all the options.

We would love to hear your feedback!

- Nic