Re: Proposal: Cookie Priorities

Thanks for the conversation, folks. A few replies inline:

On Mon, Mar 7, 2016 at 9:12 AM, Daniel Stenberg <daniel@haxx.se> wrote:

> On Thu, 3 Mar 2016, Mike West wrote:
>
> https://tools.ietf.org/html/draft-west-cookie-priority-00. Apologies for
>> the years of delay. :/
>>
>
> Count me as another skeptic.
>
> Since implementing support different cookie priority levels requires
> changing the server ends, wouldn't it be better to ask server admins to
> instead stop polluting the same domain with excessive amounts of cookies? I
> presume the primary cookie limit you're talking about number of cookies per
> domain. Alternatively, advocate for a higher limit (even though RFC6265
> only suggests certain limits, browsers are free to user higher)?
>

Chrome and Firefox both set limit at ~150 cookies per domain. Chrome has a
different eviction mechanism than Firefox, allowing a domain to flex up to
180 cookies before purging it back down to 150. My (vague) understanding is
that we arrived at that mechanism for performance reasons: purging just one
cookie lead to some level of churn for users who hovered around the limit.

Raising the limit is certainly possible, but also has performance impacts
and storage limitations. We'd need to measure those carefully before
bumping the limit, as determining which cookies to send ends up being on
the critical path for every request.


> What happens to cookies that are actually called 'Priority' ? It seems
> like a very standard name for a cookie and to me it seems like there's room
> for confusion for services that already use Priority set to Low/High etc. I
> don't see any mentioning of how to handle this.
>

Like cookies named "HttpOnly" or "MaxAge", this is handled by step 1 of
https://tools.ietf.org/html/rfc6265#section-5.2, which splits the cookie
string on the first ';' into the name/value pair, and the set of attributes.


> This mechanism adds more complexity to an already complicated and messed
> up concept.
>

It also solves a real problem that really exists, at least in the complex
ecosystems of corporate intranets. Both Mark and Martin seem to have
confirmed that the anecdata I provide isn't limited to Google.

I'm also a bit sad to hear that Chrome+Google already implement this, as it
> feels like a certain degree of the old web war tactics all over again. It
> won't really matter what we say in this work group, as Google services will
> work less good without this feature and Chrome already works like this, so
> in order to keep users happy, user agents are strong-armed into following...


On this point, I can only apologize. We didn't follow through on our
commitment to discuss shipping this feature openly, we didn't report our
experimental results, and we didn't get buy-in from other browser vendors.
You're correct that this is bad behavior. If it turns out that Chrome is
the only vendor that's going to implement this, then I'll do my best to get
it removed.

All that said, I think the Chrome team has gotten significantly better at
this since 2013. We have a clear launch process
<http://www.chromium.org/blink#launch-process> for web-facing features, and
if we were launching cookie priorities _today_, the conversation would have
gone differently.

On Mon, Mar 7, 2016 at 4:29 AM, Matthew Kerwin <matthew@kerwin.net.au>
 wrote:

> Regarding "Priority=High": Currently cookies are often used on the
> critical path, and these existing cookies don't have a "Priority"
> attribute. We can't define a new spec that retroactively mandates that
> implementers have to add the attribute, so I imagine we would probably want
> to define it so that "no Priority" is as high as "High Priority." (Unless
> we're proposing to define a new supe..uh..'more important' cookie.) So all
> the existing dead wood remains, and the path of least resistance for
> implementers who want to comply with the spec is: don't do anything. Thus
> it's not a valuable addition.
>

The spec defines a missing `priority` attribute as setting "medium"
priority, which allows an origin to just set priority on those cookies
which are particularly important, or particularly discardable. For
instance. Google sets `priority=high` on authentication cookies, and
`priority=low` on cookies which only contain information that could be
derived (at expense) from the user session data.

Also, just so it's clear: the `priority` attribute is only considered in
the context of a single domain. We don't discard `example.com`'s "low"
priority cookies in order to keep `google.com`'s "high" priority cookies.
We only consider priority when determining which of a particular domain's
to evict, once we know that we need to evict a few. It is quite limited in
scope, and does not override any of the other mechanisms which might cause
a cookie to be removed. In particular, `priority=high` does not change
cookie expiration. I don't think it's fair at all to allude to it as a
supercookie.

Regarding "Priority=Low": this allows/encourages people to add even more
> cookies, because "they're low priority, so they're less harmful." Telling
> people to add a bunch of fluffy cookies because 'they can be pruned if
> there are too many' doesn't seem like an improvement to me. Better advice
> would be: don't send so much cruft in cookies.
>

Given that `priority` only comes into play when cookies are evicted for
exceeding a domain's limit, it doesn't appear that developers have needed
much encouragement. :)

In the particular set of cases I'm concerned with, the problem isn't a
single developer or even a single application stuffinh a user's cookie jar
with 150+ cookies, but a collusion of multiple applications on a single
registrable domain. For each individual application, cookies might be
totally legitimate and not at all crufty; that doesn't change the overall
impact on the domain.

On Fri, Mar 4, 2016 at 1:53 AM, Martin Thomson <martin.thomson@gmail.com>
 wrote:

> I have a small suggestion:
>

> if (request.url.scheme == 'http') {
>   cookie.priority = 'floor';
> }
>

Note that the eviction changes in
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-00 would still
be effective; I'm working through how those changes impact Google at the
moment, and hope to have a more concrete proposal of what an eviction
algorithm that takes care of both of these proposals might look like. The
initial pass that we planned to start shipping in Chrome 50 caused some
disruption that I'm still working through.

Related story, I believe that some of those people run servers that
> forcibly evict all cookies other than those on a small whitelist to
> prevent this sort of craziness.  That turns out to have beneficial
> properties.


Indeed, Google has put a ton of effort into understanding all the cookies
that are set by Google services, and my understanding is that we do
actively cull cookies coming into/set by our frontend servers. The intranet
(`*.corp.google.com`) is less centralized, and less controllable; I'm told
that the sign-out rates we see internally are orders of magnitude higher
than we see externally, for this reason.

-mike