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

From: Zhong Yu <[email-masked]>
Date: Sun, 24 May 2015 20:42:26 -0500

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

---

From: Zhong Yu <[email-masked]>
Date: Sun, 24 May 2015 21:01:37 -0500

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

---

From: Zhong Yu <[email-masked]>
Date: Thu, 28 May 2015 10:10:55 -0500

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

On Sun, May 24, 2015 at 9:01 PM, Zhong Yu <[email-masked]> wrote:

> 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.
>
> 2. "parent of public suffix" is explicitly mentioned, because it may not
> be a public suffix.
>