Re: [http-state] Ticket 6: host-only cookies

Adam Barth <> Fri, 22 January 2010 17:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C41B3A6AA3 for <>; Fri, 22 Jan 2010 09:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y9t+8YWIdYNe for <>; Fri, 22 Jan 2010 09:49:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6D0E53A68DF for <>; Fri, 22 Jan 2010 09:49:39 -0800 (PST)
Received: by pxi16 with SMTP id 16so1005164pxi.29 for <>; Fri, 22 Jan 2010 09:49:32 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id s19mr2185677wff.312.1264182571881; Fri, 22 Jan 2010 09:49:31 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Adam Barth <>
Date: Fri, 22 Jan 2010 09:49:11 -0800
Message-ID: <>
To: Daniel Stenberg <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state <>
Subject: Re: [http-state] Ticket 6: host-only cookies
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Jan 2010 17:49:40 -0000

On Fri, Jan 22, 2010 at 3:00 AM, Daniel Stenberg <> wrote:
> On Fri, 22 Jan 2010, Adam Barth wrote:
>> 1) Specify host-only cookies to match Firefox, Chrome, Safari, and Opera.
>> This is best for security, and I think there's a good chance that IE will
>> adopt host-only cookies in future, but I don't have any citable evidence for
>> this belief.  (The draft currently matches this proposal.)
> Even though this would be the best security option (and in general I think
> it makes more sense), I don't think we can neglect that one rather widely
> used implementation doesn't do it this way.

We certainly can't neglect that the most widely used implementation
has a different behavior, hence the discussion.

> Sites out there that depend on this bug/feature in IE will break. And we
> know there exist many IE-crafted sites out there (although I guess nobody
> really knows how many of those that might depend on this particular thing).

There are a great many places where Internet Explorer diverges from
Internet and web standards.  When implementing an HTML user agent, for
example, one has to think carefully about whether to implement some
features the IE way or the standard way.  Often these decisions are
not easy and require substantial implementation experience.

In this case, we see that every non-IE user agent has decided to
support host-only cookies.  Given the collective market share of these
user agents, that's strong evidence that the behavior is sufficiently
interoperable with existing servers.  Also, there is a large security
benefit to implementing host-only cookies.  For these reasons, the
benefit of host-only cookies outweigh the potential compatibility

> I'm guessing this is a difference that simply will remain for a good while
> forward. The non-IE browsers won't do it this way due to security and IE
> does it this way by tradition and the good old "we won't change any
> behaviors since then something will break for our users".
> So, I'm afraid I'm leaning towards (3): Allow both behaviors.

I believe that if we take approach (1) that, in the future, IE will
join all the other user agents in supporting host-only cookies.

I understand that it can be challenging to determine when to specify
existing behavior and when it's appropriate write a requirement that
makes IE non-conformant.  In this case, the fact that every other user
agent has the same more secure behavior is strong evidence that we
ought to require that behavior.  At some level, this is a judgment
call that reasonable people can disagree with.