In my opinion, the largest problem in bug 53354 is that the user has no (comfortable) option to exclude certain sites from this rule. Almost all cookies out there are either for the session only (technical, helping the site implementation) or tracking the user (IMO privacy-violating). For these, the session cookies setting is very useful. But there is a very small fraction of cookies that actually serve the user when persisted. For example the bugzilla cookies or a stored login. In the latter case, the autofill goes a long way and is often the preferred solution. But for some sites, I prefer to be recognized from the beginning instead of having to log in (even if that is only one click and pageload), even if that means to loose my ability to (easily) browse the site anonymously. The easiest UI implementation might be to couple this to the "allow cookies from this site" UI/prefs. Another UI, the IMO prefered one but much more time consuming one, would be to create/use a "trust level" UI, where a user can collect a set of pref settings to a preset and then assign a preset to sites. The user could then disable session cookies as part of this preset. I haven't looked into the cookies manager backend implementation yet. Implementation hints, as detailed as possible, are greatly appreciated.

This is similar to bug 74257 ("improvements for cookie mamager and cookie boxes") and bug 75915 ("Cannot block all cookies EXCEPT for those sites specifically allowed access to place cookies.") Also, because the session-cookie preference only applies to new cookies, there is sort of a workaround--you can turn off the session- cookie preference, visit the site you want to be able to set cookies, and then turn session cookies back on.

I suggest the following UI in the Cookies pref panel: [x] Downgrade cookies instead of rejecting them When this box is checked, any cookie that would normally be rejected is instead downgraded to session-only. That is, no cookie is ever rejected entirely, but non-approved cookies expire at end-of-session. Note that session cookies are always accepted unmodified under this setting. My rationale for this suggestion: * It matches the language/behavior of the P3P settings. Currently the P3P code can selectively downgrade cookie lifetimes, but outside P3P, downgrading is an all-or-none choice. * Lightweight UI. Many proposed cookie management changes (see bug 53354) require added UI in the accept/reject dialog, or several lines of new preferences. This proposal would add a single, easy-to-explain checkbox in the pref panel. * When used in combination with the per-site "warn me" setting, we get the following behavior: Session cookies are always accepted, with no user intervention needed. Sites approved by the user can set cookies with normal lifetimes. Cookies from non-approved sites are set, but forced to expire at end-of-session. This last setting is the behavior that I would most like to see, and I think this is the best way to implement it even though it is not the most general cookie-management solution.

Matt's suggestion in comment 2 fits well with what I suggested in bug 67580, "[RFE] cookie-managing ui with fewer dialogs". In fact, it's the same as bug 67580 except that bug 67580 also asks for an icon in the status bar that shows the current cookie status (no cookie or session cookie, downgraded cookie, accepted cookie) and allows the user to quickly change the status of the cookie.

See also bug 145690, same bug for images.

Another solution to this same problem would be to allow the user to select a cookie in the cookie manager and hit a "make permanent" button. Basically, I'm tired of logging into bugzilla and slashdot, but I don't want random sites to feed me long-term cookies and I don't want to be plagued with "do you want to accept the cookie" dialogs.

*** Bug 175363 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of 75915 ***