Return-Path: X-Original-To: http-state@ietfa.amsl.com Delivered-To: http-state@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EEE1A8915 for ; Sun, 24 May 2015 18:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.301 X-Spam-Level: * X-Spam-Status: No, score=1.301 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yUmjY22ES7M for ; Sun, 24 May 2015 18:42:27 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49F8D1A88A4 for ; Sun, 24 May 2015 18:42:27 -0700 (PDT) Received: by igbsb11 with SMTP id sb11so24552493igb.0 for ; Sun, 24 May 2015 18:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=EREfKgQ7K9Oz0zlxNJWoREVzTQgSUBDUwWB+Efzgsfo=; b=R2rL2+6Nt8B2du8bMv0MPPDSZWXDqdbffCZPAA+rzjxGNoGJKTM+lwvdG3hSpp9b6v tSODtENsZw85YLyw8NFV+AdvQMSLMUBcuDqxnxx0hf8aPcPF1tJTR89RjznVNVo2rrge K5FJJdr0Eq9i1WKfPceu/gkxCL7fsPqoCMa/hWs24gkO3LtCuEbW+i6OzPH5pujb0cAv aqAiYvwTX0dSdJh32FicaBvXebLXH7VD4It9mzdvjpQTXVXO2Wfjf/wlhM4b49z5oAiM FVtcU78/fYAQyQhpJ2NnhSyhN492dr37AiVIXde+zzzX9J1jSC2vO2bUYFhrFBx/u0QO uxww== MIME-Version: 1.0 X-Received: by 10.43.152.204 with SMTP id kx12mr21286043icc.51.1432518146545; Sun, 24 May 2015 18:42:26 -0700 (PDT) Received: by 10.64.98.33 with HTTP; Sun, 24 May 2015 18:42:26 -0700 (PDT) Date: Sun, 24 May 2015 20:42:26 -0500 Message-ID: From: Zhong Yu To: http-state Content-Type: multipart/alternative; boundary=001a11c2ce72425fb10516de1fea Archived-At: Subject: [http-state] Browser Behaviors on Cookie Domain and Public Suffix X-BeenThere: http-state@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discuss HTTP State Management Mechanism List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 01:42:29 -0000 --001a11c2ce72425fb10516de1fea Content-Type: text/plain; charset=UTF-8 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, is a public suffix, but < amazonaws.com> is not. # Firefox/Chrome: can set a cookie for ; the cookie is applicable to , , etc, but not to and its child domains. # Safari: nobody can set a cookie for ; the domain is probably treated as a public suffix. # IE: IE apparently doesn't recognize as a public suffix; it's treated as a normal domain. IE doesn't even recognize Microsoft's own public suffixes like . 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 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 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 - 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 is a public suffix, but is not ( the public cannot directly register names under ). Semantically we would expect that the wildcard rule is equivalent to the expansion of all child domains - , .... And we would expect that a browser handles / the same way it handles /. Unfortunately that's not the case. # Firefox/Chrome/Safari: both and are treated as public suffixes; nobody can set a cookie for # IE: IE apparently misunderstands wildcard rules; is treated as public suffix, but is treated as not - can set a cookie for that's applicable to ------------ 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 on Safari - can set a cookie domain that's applicable to Note that and 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 sets a cookie with domain , the cookie is accepted with domain erased; the cookie is applicable to only , 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 --001a11c2ce72425fb10516de1fea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is a survey of how browsers handle cookie domain= s with regard to public suffixs.

5 major browsers are tes= ted: 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 men= tioned again.

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

First, some references:=

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

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

=C2=A0=C2=A0=C2=A0 The list of public suffixes: https://publicsuf= fix.org/list/public_suffix_list.dat

------------
<= br>
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: &= lt;s1.amazonaws.com> can set a c= ookie for <amazonaws.com>; the c= ookie is applicable to <amazonaws.com>, <s2.amazonaws.com>, e= tc, but not to <compute.amazona= ws.com> and its child domains.

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

# IE: IE apparently doesn't recognize <compute.amazonaws.com> as a public suffix; it&#= 39;s treated as a normal domain. IE doesn't even recognize Microsoft= 9;s own public suffixes like <azure= websites.net>. I'm unable to find domains to conduct this partic= ular teston IE.

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

One one ha= nd, Firefox/Chrome conforms to rfc6265#5.3 by accepting cookie domain <<= a href=3D"http://amazonaws.com">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:
=C2=A0 - only a few comp= anies could benefit from it;
=C2=A0 - they probably do not need to shar= e client state among sites like <s1/= s2.amazonaws.com>
=C2=A0 - if they do need to share client state= , they have enough resources to accomplish it through other methods
=C2=A0 - they cannot reliably share client state through cookie doma= in anyway, because of Safari.
=C2=A0 - Firefox/Chrome fails t= o 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 nam= es under <nom.br> ).

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

# Firefox/Chrome/Safari: both &= lt;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 fo= llowing TLDs are tested:

=C2=A0=C2=A0=C2=A0 com=C2=A0 job= s=C2=A0 bd=C2=A0 il
=C2=A0=C2=A0=C2=A0 test=C2=A0=C2=A0 examp= le=C2=A0=C2=A0 invalid=C2=A0=C2=A0 local=C2=A0=C2=A0 localhost=C2=A0=C2=A0 = arpa
=C2=A0=C2=A0=C2=A0 faketld

= The only exception is <localhost> on Safari - <s1.localhost> ca= n set a cookie domain <localhost> that's applicable to <s2.loc= alhost>

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

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

Anothe= r detail in rfc6265#5.3 - if both cookie domain and request host are the sa= me public suffix, accept the cookie, but ignore the cookie domain.

F= irefox 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 ot= her sites. "foo" could be "test/faketld/com/uk/co.uk/foo.nom.br/compute.amazo= naws.com" etc.

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

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

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

Zhong Yu=
bayou.io
--001a11c2ce72425fb10516de1fea--