Specific details on Firefox' changes:
* Max cookies doubled from 1000 to 2000
* Max age of 30 days added
* Cookies are purged when cookies >= 1.1 * max cookies and (now - oldest cookie) >= 
1.1 * max age
* When purging, all expired cookies are removed, then as many cookies over the age 
limit as are needed to reach the cookie count limit

Here "age" refers to the last accessed time of a cookie.

Note that this means we could have an arbitrarily large number of cookies if they are 
all "young".

The biggest concerns here are startup time and memory usage.  There's some commentary 
on these in the associated Firefox bug, where dwitte estimates that for 10k cookies 
the theoretical max cookie DB size is 50 MB but the practical size is more like 2 MB.  
Since in this patch we start looking to purge when we hit 1/5th of that, I think 
we're OK on memory.  Startup time is harder for me to estimate, but if we're 
preloading the cookie DB, then I suspect the fixed overhead of seeking to and opening 
the cookie DB is going to dominate the time to read an additional < 1 MB from it.

In summary, IMO the win from not "losing" cookies and from matching Firefox seems 
worth the price here.  I'm going to try to implement this.

FWIW, my current profile's cookie store is 333 KB on disk.  I believe I'm near the max 
cookie limit at all times, so that's probably a reasonable value for most users' cookie 
DB size.  Figure we'll slightly more than double that, so say 750 KB.

More notes:

* I don't think this has actually landed upstream; all they've done at the moment is 
raise their limit from 1000 to 3000 temporarily.
* Malicious sites can't spam document.cookie=i; because we still have a per-host limit 
that purges the oldest cookies from that host (as now).

Not blocking the next release. 

Seems low cost to change the constant for an earlier Mstone if this is causing pain for 
users, but I trust mal.  :)

I talked with peter on IRC.  I don't think DoS is much of an issue.  There are already 
easier ways to DoS us.  Matching Firefox here is likely important for compat.

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

See  issue 7538 . 

If Peter's right, and this is the issue causing widespread frustration, we should fix 
this. Go for it, Peter.

I think we should just double the cookie limits.  I am not worried about the extra
storage or startup overhead.

If we want to try a riskier and more complicated change, maybe we should see how the
doubling goes first.  It would be nice to at least attempt a fix for this problem
without a massive change to the cookie policy logic.

Doubling the cookie limits is fine, but the data I've been informally collecting from 
myself as well as people on the Shack, IRC, and the bug database that have been 
encountering this suggest that it won't help much.

Honestly I think we should just check this in and then I should work on modifying the 
store so that we can apply the host limit to all subdomains of a top-level host.  I 
imagine doing that by having a hash of the TLD + 1 and then having that object be the 
root of a tree (not a binary tree) of subdomains.

Let's at least stopgap-patch to 3000 to match Fx 3.5.  I sent a patch for this.  I'd 
still like to land the larger patch here after Mstone 3 ships if possible but hopefully 
this will help without being too contentious :)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=17501 

------------------------------------------------------------------------
r17501 | pkasting@chromium.org | 2009-06-03 11:20:14 -0700 (Wed, 03 Jun 2009) | 2 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster.cc?r1=17501&r2=17500
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/cookie_monster_unittest.cc?r1=17501&r2=17500

Increase cookie limit to 3000.  This matches Firefox 3.5 and Firefox trunk.BUG=8850
Review URL: http://codereview.chromium.org/118011
------------------------------------------------------------------------

r17501 updated the cookie limit to 3000.  I'd still like to see us do more here but 
nothing else needs to happen for Mstone-3.

 Issue 8414  has been merged into this issue.

The current patch to implement the "max age" behavior is at 
http://codereview.chromium.org/99100 .  This has not been landed because
(a) We've never solved the "host limits should apply to subdomains" issue
(b) The Mozilla folks have not landed their version of this patch either

I'm having major issues with cookies being deleted before they expire.  I'd love to see 
this patch implemented if it'll help fix that issue.

(No comment was entered for this change.)

I'm using Chromium build 4.0.223.11 on Linux and I've noticed that most of my cookies 
expire on session end, while the same cookies remain open when using Firefox 3.X. This 
is annoying because I have to login in every forum or page (except for GMail and 
Google Reader) every time that I close the browser.
I've tried to clear the cookies and also to delete the .chromium directory but when I 
login to any of these pages, the behavior is the same and I have to re-login every 
time that I close chromium.

@20: Not related to this issue, please file a different bug

This policy change has now landed on the Gecko trunk.  We should dust off this patch 
and look into restructuring to enable more accurate max cookie limits as noted above.

Replacing labels:
   Area-BrowserBackend by Area-Internals