User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 In the Privacy preferences, I would like to be able to select the following: - silently accept cookies for the current session only - ask before accepting for all other cookies This gives me a better balance between automatically accepting all cookies (which allows long-term tracking by arbitrary web sites) and being prompted to accept every single cookie (making web browsing cumbersome). I suggest a preferences GUI such as the following. This would still allow all the behaviours which are currently available, as well as supporting the behaviour I am looking for: [x] Enable Cookies For cookies that last only until the end of the session [x] Accept only from the originating web site [x] Ask permission before accepting For cookies that are saved between sessions [x] Accept only from the originating web site [x] Ask permission before accepting Reproducible: Always Steps to Reproduce: 1. 2. 3.
Is there existing functionality for this already in the Cookies component? I'm not aware of any prefs regarding this type of behaviour. Going to confirm this, but don't expect it done until the cookie manager rewrite in bug 187304 is finished. As a note, RFE is deprecated, just use the enhancement severity.
bug 187304 is irrelevant to this bug. this is a UI issue.
64336 is the actual bug for this feature, but leaving this open under Firebird for the UI factor
I would extend the suggestion to the following: [x] Enable Cookies For cookies that last only until the end of the session [x] Accept only from the originating web site [x] Ask permission before accepting For cookies that are saved between sessions [x] Accept only from the originating web site [x] Ask permission before accepting [x] Expire them at the end of the session
This is one of the things I sorely miss from IE6, which - in addition to black/white-listing - allows you to control whether you Accept/Block/Prompt on First/Third party cookies *and* lets you check 'Always allow session cookies'. The 'Advanced' UI in that browser is spot-on in my opinion, even if I'm never quite sure what the standard slider is doing. In ASCII the UI would be: [x] Override automatic cookie handling First-party Cookies: Third-party Cookies: ( ) Accept ( ) Accept ( ) Block (o) Block (o) Prompt ( ) Prompt [x] Always allow session cookies I've spent a while trying to become comfortable with the options FB currently has, but setting 'For the originating site only' and 'Ask before accepting' bothers me on nearly every website, whereas 'For the current session only' means that a lot of things "seem to work" at the time (e.g., setting google preferences, logging in to bugzilla), only to create more hassle after the browser is closed. There's no happy medium. The issue is compounded by FB's apparent lack of privacy notification icon: another plus for IE6 is that it shows an indication in the status bar when a cookie is rejected. The current state of affairs is pretty embaressing, really. Don't we care about privacy as much as Microsoft?
This is a Firebird bug and should not block a seamonkey meta bug.
Regarding comment #3: In my opinion, the whole cookie thing should be considered as a whole including: - the default settings in the Tools/Options - the (optional) confirmation dialogue for accepting or rejecting cookies - a Cookie Manager (including white lists, black lists, etc). - the status bar notification that allows for changing the preferences for this site (white listing/black listing, etc), similar to the Cookie Button extension and possible linking to a Cookie Manager. It is not-the-best-thing-to-do to work on one issue and not consider the impact on the other ones.
trying to make that all work in one bug is impossible. see the "make cookies UI not suck" bug for a tracker for the seamonkey side of things. Firebird is aiming at a less complex interface, so the basic UI will be (as it is now) a subset of the possible combinations. There may be an option in the installer to have advanced preferences (possible as part of the security UI extension, I need to talk to ben about that). [ ] Ask before accepting [ ] but only for persistent cookies (wording here is tough) is probably the most likely here, at least until someone implements a slider in XUL.
FYI, setting network.cookie.alwaysAcceptSessionCookies to true will enable this functionality in current nightlies. I'm not sure if we'll expose support for this, need feedback from ben.
Is this going to be solved before 1.0 or is it deferred to later as part of 'the whole cookie thing' (see comment #7)?
at present, I'm not expecting to see UI for this at any point in Firefox, its pretty much a niche pref. Use the hidden pref via about:config if you really want it.
this is just too obscure, the new cookie prefs UI is very plainly worded, this just doesn't fit there, or anywhere.
The real solution is to make it easy to whitelist sites when "accept for session only" is chosen. Then hopefully we can get rid of the "ask for each cookie" feature.
WONTFIX? It was fixed for Seamonkey (64336), which is the bug I had been following. Why there but not here? The solution there is exactly what I wanted.
Yes, I fixed it for Seamonkey, as you'll notice, but that UI doesn't fit for Firefox. Where seamonkey has an entire pref panel for cookies prefs, we have a small section with a streamlined interface. This is still available via about:config, but UI for it doesn't fit with our UI standards for Firefox.
why wouldnt it fit? an aditional line "allways allow session cookies" wouldnt be more confusing than "for the originating web page only".
adding it there wouldn't really be useful, since this pref is only relevant when cookie prompts are on. Its an option that most users will NOT understand, and is more apt to cause confusion. For users sophisticated enough to know both, they can use about:config. I personally don't think cookie prompts themselves are useful to normal users, and there's been some preliminary discussions on how to get rid of them in favour of a delayed acceptance option (much like the Show Popup option).
sorry for bugspam, long-overdue mass reassign of ancient QA contact bugs, filter on "beltznerLovesGoats" to get rid of this mass change