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

[Zhong Yu]

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

[Zhong Yu]

Based on the previous observations and reasonings, I'm going to propose an Errata for rfc6265. Since the subject is messy and controversial, I'll wait for some time though. If nobody objects, I'll submit the Errata on Thursday.

I think an errata is needed here because an implementer reading the RFC and publicsuffix.org may have missed the nuances, and accidentally allowed super cookies.

Proposed Errata: (technical)

Section 5.3 says:

   If the user agent is configured to reject "public suffixes" and the domain-attribute is a public suffix:

           If the domain-attribute is identical to the canonicalized request-host:

              Let the domain-attribute be the empty string.

           Otherwise:

              Ignore the cookie entirely and abort these steps.


It should say:

   If the user agent is configured to reject "public suffixes" and the domain-attribute is a TLD, or a public suffix, or any parent domain of a public suffix:

              Ignore the cookie entirely and abort these steps.

Notes:

1. "TLD" is explicitly mentioned, because a TLD may not be a public suffix.

2. "parent of public suffix" is explicitly mentioned, because it may not be a public suffix.

3. The clause to set domain-attribute="" is removed for simplicity and interoperability; only Firefox implements it; and it doesn't seem very useful.

--

Zhong Yu
bayou.io

[Zhong Yu]

I will not file the errata at this time; the situation at publicsuffix.org is quite confusing [1] ; we need more time before things settle down. Implementers depending on rfc6265 and publicsuffix.org need to figure out what to do on their own.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1139842#c69

Zhong Yu

bayou.io