W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Revising RFC6265 ("Cookies")

From: Mike West <mkwst@google.com>
Date: Fri, 27 Nov 2015 15:07:30 +0100
Message-ID: <CAKXHy=dd4_OypN=V_h=BNR5tdLZsZsJ5weLGtc_Dznn7ODmLBQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>, Mark Nottingham <mnot@mnot.net>
Cc: "Hodges, Jeff" <jeff.hodges@paypal.com>, HTTP Working Group <ietf-http-wg@w3.org>
I'm glad to see that folks are generally supportive!

On Fri, Nov 13, 2015 at 9:42 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:

> On 13 November 2015 at 12:29, Hodges, Jeff <jeff.hodges@paypal.com> wrote:
> > Also, this means the "intent to implement" includes both user agents and
> > server-sides.
>
> Generally, yes.  But we're tentatively planning to ship
> leave-secure-cookies-alone unilaterally based on what we are seeing in
> terms of usage.  That is, given the Zheng paper, the breakage is a
> small enough amount that we're willing to make that call.  I'm not
> sure that's true of all browsers, and nothing is final until the code
> has shipped.  I was hoping that we could have that conversation for
> each of these changes.
>
> For most of the other pieces, some indication of server support would
> make a big difference.  If no server is going to use a feature, even
> in principle, that would make us much less favourably inclined toward
> doing the work.
>

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/2PK3q_VE1rg
outlines Chrome's current plans on these drafts. We have implementations of
leave-secure-cookies-alone and cookie-prefixes done behind a flag. As
Martin suggested, Chrome is also leaning towards shipping
leave-secure-cookies-alone unilaterally; metrics from Chrome and Firefox
show something on the order of 0.02% of cookie set operations would be
effected, and the advantages seem at this point to greatly outweigh any
transitory breakage we would induce. We're poking at developers now to get
a feel for the impact, and we'll decide whether or not to ship the changes
based on that feedback.

first-party-cookies are 90% implemented behind a flag (we have some work to
do to catch up with the latest drafts), and folks like GitHub have been
experimenting with the server-side implementation for several months now.

Assuming cookie-prefixes ships, I don't think it's worth pursuing
origin-cookies, as the `$Host-` prefix does practically everything we'd
need. I've let that draft expire, but I'm happy to pick it up again if
folks disagree about it's cost/benefit ratio.

That said, feedback on those first three drafts in particular would be
greatly appreciated. I'd like to get them cleaned up to the point at which
this group would be comfortable issuing a call for adoption, as Mark
discussed earlier in the thread.

-mike
Received on Friday, 27 November 2015 14:08:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC