[http-state] Browser Behaviors on Cookie Domain and Public Suffix

[Zhong Yu <[e-mail]>]

This is a survey of how browsers handle cookie domains with regard to
public suffixs.

5 major browsers are tested: Chrome/Opera, IE, Firefox, Safari; latest
versions on Windows 7. Note that Opera behaves exactly like Chrome in all
tests, so it won't be mentioned again.

------------

First, some references:

rfc6265#5.3
    If ... the [cookie] domain-attribute is a public suffix ... ignore the
cookie entirely

publicsuffix.org
    A "public suffix" is one under which Internet users can (or
historically could)
    directly register names.

    The list of public suffixes:
https://publicsuffix.org/list/public_suffix_list.dat

------------

>From these specs, there's an obvious complication - what if a public suffix
has a parent that's not a public suffix?

As an example, <compute.amazonaws.com> is a public suffix, but <
amazonaws.com> is not.

# Firefox/Chrome: <s1.amazonaws.com> can set a cookie for <amazonaws.com>;
the cookie is applicable to <amazonaws.com>, <s2.amazonaws.com>, etc, but
not to <compute.amazonaws.com> and its child domains.

# Safari: nobody can set a cookie for <amazonaws.com>; the domain is
probably treated as a public suffix.

# IE: IE apparently doesn't recognize <compute.amazonaws.com> as a public
suffix; it's treated as a normal domain. IE doesn't even recognize
Microsoft's own public suffixes like <azurewebsites.net>. I'm unable to
find domains to conduct this particular teston IE.

------------

One one hand, Firefox/Chrome conforms to rfc6265#5.3 by accepting cookie
domain <amazonaws.com> which is not a public suffix; on the other hand,
Firefox/Chrome must violate rfc6265#5.4 so that the cookie is not delivered
to public suffix <compute.amazonaws.com> and its child domains.

The behavior of Firefox/Chrome is reasonable and defensible, but it's quite
complicated, and the benefit is dubious:
  - only a few companies could benefit from it;
  - they probably do not need to share client state among sites like <s1/
s2.amazonaws.com>
  - if they do need to share client state, they have enough resources to
accomplish it through other methods
  - they cannot reliably share client state through cookie domain anyway,
because of Safari.
  - Firefox/Chrome fails to demonstrate the same behavior when wildcard
rules are involved, see below.

------------
Wildcards

The public suffix list contains wildcard rules like <*.nom.br>. It means
that any <foo.nom.br> is a public suffix, but <nom.br> is not ( the public
cannot directly register names under <nom.br> ).

Semantically we would expect that the wildcard rule is equivalent to the
expansion of all child domains - <a.nom.br>, <aa.nom.br> .... And we would
expect that a browser handles <foo.nom.br>/<nom.br> the same way it handles
<compute.amazonaws.com>/<amazonaws.com>. Unfortunately that's not the case.

# Firefox/Chrome/Safari: both <foo.nom.br> and <nom.br> are treated as
public suffixes; nobody can set a cookie for <nom.br>

# IE: IE apparently misunderstands wildcard rules; <nom.br> is treated as
public suffix, but <foo.nom.br> is treated as not - <s1.foo.nom.br> can set
a cookie for <foo.nom.br> that's applicable to <s2.foo.nom.br>

------------
TLDs

All TLDs are treated by all browsers as public suffixes w.r.t. cookie
domain, with 1 exception. The following TLDs are tested:

    com  jobs  bd  il
    test   example   invalid   local   localhost   arpa
    faketld

The only exception is <localhost> on Safari - <s1.localhost> can set a
cookie domain <localhost> that's applicable to <s2.localhost>

Note that <bd> and <il> are not public suffixes per se - they appear in the
public suffix list only as <*.bd> and <*.il>.

------------

Another detail in rfc6265#5.3 - if both cookie domain and request host are
the same public suffix, accept the cookie, but ignore the cookie domain.

Firefox is the only browser that implements it - if a public suffix site
<foo> sets a cookie with domain <foo>, the cookie is accepted with domain
erased; the cookie is applicable to only <foo>, not to any other sites.
"foo" could be "test/faketld/com/uk/co.uk/foo.nom.br/compute.amazonaws.com"
etc.

On other browsers, such a cookie is simply discarded, if its domain is
considered a public suffix.

The benefit of this feature of rfc/firefox is dubious
  - this feature intends to tolerate a programming mistake that sets a
cookie domain where it shouldn't. we do not need to exercise such tolerance
on public suffix operators.
  - it's unlikely that any operator of a public suffix needs this feature
  - this feature cannot be relied upon anyway, since only Firefox does it.

--------------

Zhong Yu
bayou.io