Cookie removal algorithm

[martinthomson]

This foremost relates to the arbitrary limits that cookie stores place on cookies, both globally and per-domain.

RFC 6265 says the following:

At any time, the user agent MAY "remove excess cookies" from the
cookie store if the number of cookies sharing a domain field exceeds
some implementation-defined upper bound (such as 50 cookies).

At any time, the user agent MAY "remove excess cookies" from the
cookie store if the cookie store exceeds some predetermined upper
bound (such as 3000 cookies).

When the user agent removes excess cookies from the cookie store, the
user agent MUST evict cookies in the following priority order:

1. Expired cookies.

2. Cookies that share a domain field with more than a predetermined
   number of other cookies.

3. All cookies.

If two cookies have the same removal priority, the user agent MUST
evict the cookie with the earliest last-access date first.

We did some investigation into this and discovered some problems with this process as implemented. Browsers tend to remove a fixed number of cookies once they hit storage limits. From what I can tell, browsers sort by last-access, but remove up to a fixed number of cookies.

This is bad for the integrity of storage. Retaining some, but not all cookies is a great recipe for getting incomplete state. That can be a security exposure. That was part of what made some of the attacks in this paper possible and motivated the the leave-secure-cookies-alone fix.

When we looked at this we first concluded on the following algorithm:

1. If cookies exceed the limit, remove all cookies for other domains (for foo.example.com, remove (!foo).example.com cookies, but not example.com cookies).
2. If cookies still exceed the limit, remove all cookies for other paths (for foo.example.com/foo, remove foo.example.com/(!foo)).
3. If cookies still exceed the limit, remove all related cookies (for foo.example.com, remove anything ending in example.com).

On review, I think that we can continue to use last-access date to drive this, with a much smaller change. I'm proposing two small changes:

• Require that last-access is set to the same value for every accessed cookie when constructing the Cookie header field (the text currently says the "current date and time".

• Require that when an unexpired cookie is removed, require that all cookies that share a domain and have the same (or older) last-access date also be removed.

This ensures that if a site receives incomplete cookie state, then it is at least an incomplete state that might reasonably have been created by an adjacent site. For example, say that foo.example.com installs and depends on cookies at example.com, then if bar.example.com triggers deletion, then it will remove only foo.example.com cookies. It can't be perfect because there is a risk that example.com cookies are actually specific to foo.example.com and have an interdependency on foo.example.com cookies, but that's a risk we're already exposed to.

This can result in the same results as the algorithm I described above, but it also might allow for more granular removal. For instance, if 1.example.com through 9.example.com are visited in that order and 9.example.com causes cookies to exceed the limit, then cookies will be removed for 1.example.com first The algorithm above would cause cookies for 1 through 8 to be removed at once, which is more severe than we need.

As the people driving this no longer work for Mozilla, I thought that I would record our conclusions. I don't know if we have the resources to continue to investigate implementation, but I'm happy to create a PR for the relevant section if the WG thinks that this is a reasonable change.

I understand that @mikewest still prefers cookie priorities, but no one at Mozilla has any interest in that solution and it didn't seem to get any traction when we discussed it before.

[mikewest]

Sorry I didn't see this when you first filed it.

I understand that @mikewest still prefers cookie priorities, but no one at Mozilla has
any interest in that solution and it didn't seem to get any traction when we discussed
it before.

I'd rephrase this a bit. :) The relevant claim here is less that I prefer Priority (though I do), and more that Chrome has been shipping the Priority attribute for years and I have personal knowledge of Google's internal dependency on the attribute for the corporate intranet. I have anecdotal stories of similar dependency in other companies, but nothing I can point to public statements to justify.

I recognize that other vendors are unlikely to ship the attribute. I'm very open to reviewing the results of y'all's experimentation to see if the results in other browsers show that we're making the wrong choice in Chrome, but my (biased) opinion at the moment is that Priority solves this problem in a way that puts developers more directly in control of the eviction process, and that that control is concretely valuable in scenarios that run up against the vendor-specified limits on a regular basis.

[johnwilander]

I'm circulating this with some coworkers at Apple to gather input.

[mnot]

This seems like it's out of scope for 6265bis; it wasn't in the list of proposals we accepted, and isn't a low-level interop / clarification issue. I'd suggest we punt this until a future revision.