Presently you have to do accept cookie -> yes and later you need to use the cookies manager to remove a cookie. This is a rather lengthy task if you need a cookie only temporarily (e.g. to navigate at a site). Therefore you should add a possibility to the cookie accept dialog to store the cookie only for this session.

This is already done although there is no visible UI for it so it can't be discovered. *** This bug has been marked as a duplicate of 8530 ***

Reopen: The bug 8530 is closed since the interal stuff functions, but the UI is missing. Change the summery to refect this. Since there is a UI freeze this is probably future if accepted.

See bug 23508 for other suggestions of additions to the cookie confirmation dialog. Ccing mpt, who drew the ascii thing on the other bug.

Netscape nav triage team: based on Steve Morse's pre-triage recommendation, this is not a beta stopper.

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

I consider that a pretty advanced option as most end users do not even understand how cookies work ( and do not care) Please describe in a few words the requirements needed for this UI. Even though it's not a beta requirement, it would good to state this here. I am imagining that this would be integrated into the dialog that pops up when the user is in the mode "Warn me before storing a cookie". Right now it looks like this: Confirm The site 'blah.com' wants permission to set cookie. Do you want to allow it? [ ] remember decision [ Yes ] [ No ] The modified dialog would look like this: Confirm The site 'blah.com' wants permission to set cookie. Do you want to allow it? [ ] remember decision [ ] remove after session [ Yes ] [ No ] I am not sure this is optimal yet, as this new checkbox would not have any meaning when no is clicked. So an alternative could look like this: Confirm The site 'blah.com' wants permission to set cookie. Do you want to allow it? [ ] remember decision [ Yes ] [Session only] [ No ] In which case remember decision would be meaningless in combination with Session only. What do people think?

I prefer the second box, but I feel that remmeer decision is useful. Some sites (anythign based on Cold Fusion, Microsoft's site, etc) require cookies to work. It would be nice to be able to remember the decision so I don't always have to say "Store the cookie for this session" if I go to certain sites regularly, but don't want to be tracked.

german: Like Marcus says, "Remember Decision" _does_ (or should) apply to "this session only". mpt: you're the expert, what do you say? Nominating for mozilla1.2. Not a 1.0 blocker, but would be nice to have.

Steve Morse, it escapes me whether or not "Remember..." currently applies to just the session or is stored permanently. Can you clarify

"Remember this decision" is permanent -- it is not just for the current session. I've been silent here waiting to see how the discussion would play out. But I do have strong feelings about "contaminating" the cookie warning box. Right now it's very simple, and all I did to it for implementing cookie management was to add the "do you want to remember" checkbox. If you do want to add more fields to the cookie warning box, then I would like to see that under control of a pref and that pref be off by default.

Steve I am with you on simplifying and not contaminating a simple dialog box. The reason I was suggesting putting into the dialog is that I feel users may want to set this on a case by case basis, ie. they just want to get into this one site, but generally want to get rid of the cookies when they are done. Furthermore, only folks who actually make the effort to go to the prefs and know about cookies and set the prefs to ask them everytime will see this dialog. Thus I think the audience that sees this dialogs is bit more savvy then the average user. Steve can you describe what you had in mind in terms of a pref?

All I had in mind was simply another pref asking if you want the extra choice in the cookie-warning dialog. The best solution for the problem presented here is anonymous mode. It was imlemented in gromit but never ported over into seamonkey when the gromit codebase was abandoned. There were commands for entering and exiting anonymous mode. When in that mode, the list of saved cookies is put aside and a new temporary list started. When you leave the mode the original cookie list is restored. The temporary cookies are never written to the disk and so are not permanent. Furthermore, to make the mode really anonymous, the referer field is not filled in on the first http request after entering the mode and the first one after leaving the mode.

.

I'm finding it quite difficult to design a decent UI for accepting or rejecting cookies, because cookies are effectively an opt-out thing where ideally they should be opt-in. Here's what I have at the moment: +------------------------------------------------------------+ | Privacy Warning :::::::::::::::::::::::::::::::::::::::::::| +------------------------------------------------------------+ | . Do you want to accept a cookie from (( Accept )) | | /!\ mania.xyz.foo.bar? ( Reject ) | | """ | | (A cookie is a small file which can be ( _Always ) | | used to track which pages you visit, or ( _Never ) | | to personalize pages for your use. Some | | Web sites may not work without cookies.) ( Sto_p ) | | | | [/] Ask me whenever a cookie is sent | | | | > About this cookie [?] | +------------------------------------------------------------+ This would be the default view. Click the twisty, and you get this: +------------------------------------------------------------+ | Privacy Warning :::::::::::::::::::::::::::::::::::::::::::| +------------------------------------------------------------+ | . Do you want to accept a cookie from (( Accept )) | | /!\ mania.xyz.foo.bar? ( Reject ) | | """ | | (A cookie is a small file which can be ( _Always ) | | used to track which pages you visit, or ( _Never ) | | to personalize pages for your use. Some | | Web sites may not work without cookies.) ( Sto_p ) | | | | [/] Ask me whenever a cookie is sent | | | | V About this cookie [?] | <-- help button | | | Remove: [when I exit Mozilla :^] | <-- popup menu | Name: :ASPSESSIONID : | | Contents: :GH347U-18FDHASAUPP : | | URL: :http://mania.xyz.foo.bar/ker: | | Domain: :xyz.foo.bar : | | Secure: :No : | +------------------------------------------------------------+ (Twisty state would be persisted from cookie to cookie and from session to session, so advanced users would only ever have to click the twisty once.) So the UI for this bug would only be shown at the same time as the UI for bug 23508 (avoiding flummoxing ordinary users). The default value for the popup menu would be the value suggested by the cookie (e.g. `31 December 2004'), unless the default value specified in cookie prefs for this type of cookie was more restrictive than that. The cookie prefs themselves would look like this: | Category: Privacy & Security ::::::::::::::::::::::::: | | +-------------------+ | | |=General===========| +-For any _cookie [from the same server :^]+ | | |=Display===========| | If session-only: [allow the cookie :^] | | | | Languages | | If persistent: [ask me :^] | | | | Fonts | +------------------------------------------+ | | | Colors & Effects | ( _Manage Cookies ... ) | |...

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

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

Another approach is to have a pref as to whether to accept cookies that expire end-of-sesion. The problem isn't so much which site wants to set a cookie, it's whether they're persistent and what they do. Look at the shareware product Cookie Pal for an idea as to prefs.

One more idea for the far future: Cookies worth avoiding aren't always site-dependent. For example, a user may want to block WEBTRENDS_ID from *any* site. IF a more elaborate screen is to be available for cookie filters, screening by name as well as site would be a useful (and, to my knowledge, unique) option.

Here's a fairly simple UI that could be used for this feature. Add the following two options to Prefs -> Advanced -> Cookies: 1) Maximum cookie lifetime: [_] days 2) If a site tries to set a cookie that exceeds the maximum lifetime, handle the cookie normally discard the cookie accept the cookie and shorten the cookie's lifetime ask me If you don't have a UI for the prompt, you can leave out the fourth option until you do. The two prefs set are network.cookie.lifetimeLimit and network.cookie.lifetimeOption. See: http://lxr.mozilla.org/seamonkey/source/extensions/cookie/nsCookies.cpp

An even better, and easier to understand wording is "Make my cookies expire after [ ] days" That way you can skip all the additional text. And thus make the dialog easier to understand and faster to read.

"Make my cookies expire after [ ] days" without the second menu doesn't cover the other choices for the network.cookie.lifetimeOption variable (Normal, Discard, Ask).

wouldn't be somethine like "keep cookie for only this session" better than "let cookie expire after x days"??

I have implementation notes for this and bug 23508; I may get to it soon, or in a while. If someone else wants them, let me know. Gerv

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

> wouldn't be somethine like "keep cookie for only this session" better than "let > cookie expire after x days"?? Yes, I agree. If I set the expire to 9 days and revisit the site after 7 days, the site can, I think, refresh the cookie, thus keep tracking me. This might not be obvious to the user. I think, the by far most common case is that the user just does not want to be tracked. If we use the "x days" way, we have to explain what the special value "0" means. So, the most common case is complicated. I implemented a simple checkbox, above "Warn me...", called "Session cookies" with tooltip "Forget cookies at shutdown. Applies to new cookies only.". Will attach patch. Steve Morse, can you review, please? This whole discussion about the warn dialog is actually offtopic to this bug, because this bug is about creating UI for the existing backend pref, which currently is global only. I.e. you cannot say "Let this cookie expire at the end of session, but keep that cookie as long as it wants.". (You can only do the following trick: Disable the Session cookies, visit the site whose cookie should persist, after that reenable Session cookies.) Nevertheless, the warn-dialog discussion is of course valueable and should be copied to a new bug. Many thanks to Greg Noel <GregNoel@san.rr.com> and <msuencks@marcant.de> for creating the backend pref! (If only they added them to all.js, I would have notice much earlier. I added them now.)

I'm afraid I can't approve of this patch. I just applied it to see how it would look. Then I played the part of a user, and I was very confused. Here are the problems that I saw: 1. You added a checkbox for "session cookie" just above the "warn me" checkbox. But as a user with no further details, I have absolutely no idea what this means and what will happen if I check it. It wasn't until after I read the patch that I even realized that there was a tooltip associated with this checkbox (none of the other items in the panel have tooltips so why would I have expected this one to have one). The wording on the tooltip, "Forget cookies at shutdown, applies to new cookies only" helped a little but still left me confused. Is it shutdown of the browser or of the computer? A better idea is to get rid of the tooltip and have the wording on the checkbox read "Discard new cookies at end of browser session". 2. This bug report is about the UI for reduced lifetime cookies. That feature allows you to put an upper limit on the lifetime of cookies that you are accepting. One possible value for that lifetime is 0, which reduces to a session cookie. Yet the patch presented here does not support the reduced-lifetime cookies. Instead it supports only the single case of a lifetime of 0. I would much prefer to see the UI based along the lines of the mozilla.org@pidgin.org 2001-04-28 09:53 comment above. If you feel that it's not obvious that a value of 0 would imply a session cookie, you can add that in parenthesis, i.e., Maximum cookie lifetime: [_] days (lifetime of 0 means delete cookie at end of current browser session) Or if you apply the comment from Håkan Waara 2001-04-28 11:26, you would have "Make my cookies expire after [ ] days" (0 days means cookie will expire at end of current browser session) One problem with both of the above two proposals is that they don't distinguish between existing cookies and new cookies (a user might mistakenly think that lifetimes of all existing cookies will be truncated as well). So I would modify the wording slightly to read Maximum lifetime for new cookies: [_] days or "Make new cookies expire after [ ] days"

morse, re 1.: > none of the other items in the panel have tooltips This could change. I prefer brief labels with more explanation availbale on request, so I using our UI doesn't feel like reading books (with the associated time consumption). But you could be right. "Session" is not directly understandable for users, so if you try to make the label explaining, we should say "Discard new cookies at shutdown". Yes, I user might not know, if Mozilla or the computer is meant. BUt I have no better idea: - "Browser" is wrong. Say, a user wants to delete the cookies and happens to have Mailnews open . He closes all browser windows and opens a new browser window via Tasks|Navigator. The cookies are not deleted - we mislead the user. - "Mozilla" is tricky because of branding. Yes, we can use placeholders, but they are a headache (IIRC). > 2. This bug report is about the UI for reduced lifetime cookies. *My* bug was about session cookies and got duped against this one. I want session cookies. As I outlined, I expect session cookies to be the by far most common usage of this feature. People bother most about being tracked, not having old cookies around. As you surely know, special case values are considered dangerous programming. We shouldn't expose even *users* to such confusing and doubtable concepts. Also, it would in any case complicate the the UI. Particularily, it would complicate the most common case. I don't intend to submit a patch that implements the "expire after max x days" UI, because I'm not convinced that this is the right way to go. I could imagine that we ship with a reasonable default value, e.g. expire after 6 months. I don't think that many users would want to change that.

I think the current cookie dialog is very confusing. There are basically two questions "Do you want to allow it?" and the checkbox "remember this decision". I need to constantly pause to think which question I am replying with the Yes/No button (usually I want to remember the decision (which almost makes me hit the Yes button) while usually I don't want to allow the cookie). I think the basic problem here is that you are replying with the buttons to a sentence not close to the buttons and the generic buttons can be used to answer any question. For the current functionality, I think Lynx-like buttons "Yes", "No", "Always" and "Never" would be much clearer. Or radio buttons for them and a Finish/Done/Apply/whatever button. For the additional features of this bug, this might not be the best approach, but I'd like to see this double question issue avoided one way or the other.

One way to avoid the annoyance of cookie confirms while still giving the possibility to accept or reject them is to have some kind of a non-modal UI instead of a modal dialog. E.g. you could have the cookie information appear (as a list) in the side bar with the options to accept and accept always (maybe accept never, too). If the user doesn't do anything before moving to another page, the cookie isn't accepted. This way you can surf uninterrupted and only save the cookies you deem interesting. [I know this is perhaps a bit off-topic, depending on how much the current UI is changed to support the reduced lifetime cookies. Please point me to a more relevant bug if one exists.]

Non-modality isn't going to work here. Often the site sets the cookie and then checks to see if the cookie gets sent back before it actually serves up the final page. Under your suggestion the site will see that the cookie is not being sent back and will probably deliver a page saying that cookies aren't being accepted. That doesn't make for a very good user experience because the user never said not to accept cookies -- he merely didn't get a chance to say anything.

Could you elaborate? Are you thinking of a case where the server sends the cookie along with a redirect? The browser can easily detect this (and any similar situation) and wait for the cookie confirmation before proceeding. In this case the method degenerates to a modal like functionality, but dictated by the server not by the browser. The point here is that since the cookies and the content are piggybacked, there is no reason for the browser not to let the user see the content before answering some questions about cookies.

What about the case where the cookie is set using javascript and immediately tested for using javascript.

risto.kankkunen@lingsoft.fi - about the cookie dialog box being confusing because there are two questions please see: bug 66207 - Move elements of accept cookie dialog.

Steve Morse, I suggest the following in the long term: [x] Limit maximal lifetime of cookies to (o) session ( ) [___] days maybe add: [ ] Discard cookies which request a longer lifetime but I don't suggest that, since I don't think, many users will want that and it is still available via prefs.js. What I implement is, technically, the checkbox "Restrict maximal lifetime of cookies to". So, why not see my implementation as partial implementation of this bug? If you want, we could reopen bug 81226 and check my patch in under this bug. If you force me, to, I might actually implement my "suggestion" above, but in my opinion, the largest problem here is bug 82734 and we should concentrate on that.

I like your latest suggestion -- i.e., using [x] Limit maximal lifetime of cookies to (o) session ( ) [___] days and not giving any UI support for the ability to discard cookies whose lifetimes exceed the limit. One suggestion: have the first choice above read "current session" instead of just "session".

sounds nice :-)

See bug 67580 for more discussion about making the cookie ui less modal.

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

State update: > What I implement is, technically, the checkbox "Restrict maximal lifetime of > cookies to". So, why not see my implementation as partial implementation of > this bug? If you want, we could reopen bug 81226 and check my patch in under > this bug. I spoke with morse per mail, and he objected that solution. I started with the implementation of the rest, because I though, it would be easy. It wasn't, it took longer than I thought, and when I finished coding and tested and it didn't work right away, I stopped working on it. If anybody wants to debug my code, feel free to ask me for it. I'm not sure, how much work I will invest in this anymore.

Doesn't look like this is getting fixed before the freeze tomorrow night. Pushing out a milestone. Please correct if I'm mistaken.

OK, I have this (as in, mpt's spec in this bug) nearly working, and am laying out the XUL for the dialog. Any XUL or CSS wizards around to help me polish it? I'm taking the bug off ben, as he seems to have stopped working on it. Ben - please let me know if this is a problem. Questions (for mpt and others): What icon am I supposed to be using for the twisty which opens the Extended part? Can we have some more accesskeys please? Is there a guide somewhere to "useful CSS classes in Mozilla" or something like that? I have no idea how to style my dialog correctly. How does one convert a char* into a PRUnichar *? Gerv

> OK, I have this (as in, mpt's spec in this bug) nearly working I'm a bit irritated. I had what morse and I agreed on nearly working, only debugging was left. Don't you want to at least see my code? (Maybe you don't like it, but it might be helpful.) > I'm taking the bug off ben, as he seems to have stopped working on it. Ben - > please let me know if this is a problem. No, glad you work on it. > What icon am I supposed to be using for the twisty which opens the Extended > part? Are you adding to the "Accept cookie xyz?" popup dialog? Didn't morse say that he didn't want this dialog to be extended? Did you extend the backend? When I worked on it, the backend was not capable to limit the lifetime of cookieis for selected domains, just all or none.

Gerv, for the twisty you are supposed to use doron's upcoming widget <expander/>. Please don't duplicate effort and reinvent it. CC doron

> I'm a bit irritated. I had what morse and I agreed on nearly working, only > debugging was left. Don't you want to at least see my code? (Maybe you don't > like it, but it might be helpful.) I'd like to see it; the reason I haven't referenced it is that I started my implementation back in March. I probably should have mentioned this fact at the time. :-) > What icon am I supposed to be using for the twisty which opens the Extended > part? > Are you adding to the "Accept cookie xyz?" popup dialog? > Didn't morse say that he didn't want this dialog to be extended? I wrote a new Accept Cookies dialog which conforms with mpt's spec. As I read this bug, morse hasn't objected to that If this is the wrong bug for implementing that spec in, please let me know. > Did you extend the backend? When I worked on it, the backend was not capable > to limit the lifetime of cookieis for selected domains, just all or none. Haven't quite got that far yet. Gerv

> I'd like to see it Will attach. Warning: It might be in a poor state. Let me know, if you need help understanding it. > As I read this bug, morse hasn't objected to that See Comments From morse@netscape.com 2000-12-29 11:23 > > When I worked on it, the backend was not capable > > to limit the lifetime of cookieis for selected domains, just all or none. > Haven't quite got that far yet. I would suggest you do that first. It would be really cool, if you do, but it might be hard. You might end up having wasted the time to implement the UI.

Gervase said: I wrote a new Accept Cookies dialog which conforms with mpt's spec. As I read this bug, morse hasn't objected to that. But I did object. See my comment above where I said I've been silent here waiting to see how the discussion would play out. But I do have strong feelings about "contaminating" the cookie warning box. Right now it's very simple, and all I did to it for implementing cookie management was to add the "do you want to remember" checkbox. Ben Bucksch wrote I'm a bit irritated. I had what morse and I agreed on nearly working, only debugging was left. Ben is correct that I had agreed with his last suggestion except for a minor modification which I described. My comment was: I like your latest suggestion -- i.e., using ... I agree with Ben that the correct approach is modification of the pref panel and not the cookie warning box.

morse: in order to expose our rich cookie functionality in a usable way, users will need to make some decisions at the time they are given a cookie. mpt's UI suggestion, with most of the complex UI hidden, seems to be like a good compromise. Remember, novice users will be using the default setting of "Accept all cookies", which 99% of the web uses, and will never be bothered by this. If people turn on the ability to vet their cookies, we should give them decent UI to all the features Mozilla has to offer. Gerv

Me, too that this is a pref panel thing. I'd rather not see a single cookie dialog. If people are bothered with a dialog on each cookie, most people will give in and just accept them all. I'd like to be able to do the following: * Allow a list of servers (one item on the list: Bugzilla) to set persistent cookies. * Reject cookies (without dialog!) from a list of servers.* Accept all other cookies (without dialog!) for a user-settable amount of minutes eg. 120 minutes (or failing that, for the session).

The UI is designed to work towards having to see very few cookie dialogs; but, the fewer controls on the dialog itself, the harder it is to get to that state. For example, you visit www.netscape.com and it wants to set a cookie. Which is easier: clicking "Never" on the cookie dialog and never being bothered again for that site, or clicking "No", and then going into the prefs and adding it to your blacklist? Multiply this by a large number of sites. Let's compare this with image blocking. We have a right-click "block image" item, and don't require people to go into prefs to do that. How do other browsers with decent cookie management do this? Gerv

There's a shareware utility for IE and NN called Cookie Pal that does it very well. The dialog looks about like this: = = The site 'gervase.com' wants to set a cookie. Do you want to allow it? Name: FakeCookie Expires: 14 June 2037 []gervase.com [Yes] [No] [Always] [Never] = = Tick the check box next to the server name, and Always and Never will apply to the whole server; leave it open, and you block just that cookie. Whether to accept all session cookies is a pref in the program. As with any learning program, you see the pop-up less and less over time.

This is mostly cut+paste from bug 67580. What about some kind of traffic light icon in the lower right corner? red - reject all cookies yellow - accept for this session green - store cookies blink - site wants to set a cookie (only necessary if red, maybe yellow) If the icon is or contains a number, it would be possible to also display the number of cookies already set by the site. A click on the icon might display a dialog like that of iCab, as shown in http://bugzilla.mozilla.org/showattachment.cgi?attach_id=34985 where people would see all necessary information and be able to set individual defaults for specific sites. Right-clicking on the icon could display a context menu offering the choice between accept accept for this session always accept from this site reject reject for this session always reject from this site A site that wants to set a cookie might cause the icon to blink, so that the user can decide if he wants to allow cookies for the site. The site that wants to set a cookie or/and its content could be displayed as a tooltip. This should be enabled in the prefs and would allow advanced users a great deal of control over cookies without the need for a modal dialog. What do you think about it?

Cookie decisions need to be made before the site finishes loading, otherwise javascript tests for cookies will not return the correct result. For that reason, the cookie warning dialog has to be modal.

> For example, you visit www.netscape.com and it wants to set a cookie. > Which is easier: clicking "Never" on the cookie dialog and never being > bothered again for that site, or clicking "No", and then going into the > prefs and adding it to your blacklist? No, I don't want to be bothered at all--I don't want to see a dialog that asks me to click "Never". Here's what I want: I install the browser and go through the prefs. (I know the average user doesn't do it that way, but I do.) I open the cookie prefs. I'd like to see a radio button group like this: +-Default cookie action--------------------+ | o Accept & save | | * Accept, but expire at when quitting | | o Accept, but expire after [120] minutes | | o Reject | +------------------------------------------+ I would then select the third option. Then I'd like to see a checkbox like this: [/] Always reject invalid cookies and cookies that don't originate from the same server as the main document. I would leave that box checked. Then I'd like to see a list called "Always accept from these servers". I would add bugzilla.mozilla.org to the list. Then I'd like to see a list called "Always reject from these servers". I would add to the list known advertisement servers and sites that I frequent but that don't do anything useful (from my point of view) with cookies. Then I wouldn't be bothered with cookie dialogs when I browse. > How do other browsers with decent cookie management do this? iCab It has a general setting with these options: Never accept Ask Accept, don't use Always accept Accept, expire at end of session Then it has these checkboxes: Don't accept if from different server than main document Always accept if cookie is only valid until end of this seesion Always reject illegal/invalid cookie Also, there are two lists that let the user override the general setting. The lists are Always accept from... Always reject from... Then it has a list for managing stored cookies. OmniWeb OmniWeb has a default action pop-up with the choices Prompt on each cookie Accept: keep when quitting Accept: discard when quitting Reject Additionally, the setting can be tweaked on a per site basis, but you have to first accept one cookie from each site whose setting you want to tweak.

> (I know the average user doesn't do it that way, but I do.) I'm driving at at making it most easy and usable for the average user who will use this feature at all (and that's important - the vast majority of users won't.) Going into the prefs and remembering the URLs of all the domains you want in your cookie prefs is just not an option for most people. As you say, people don't work that way. Gerv

> average user who will use this feature at all (and that's important - the vast > majority of users won't.) Just a data point: T-Online, with claimed > 7 million users the by far largest ISP in Germany, delivers the browsers with cookies on "Ask".

>Going into the prefs and remembering the URLs of all the domains you >want in your cookie prefs is just not an option for most people. Right, but a one time pref "Accept but discard when quitting" or "Accept but discard after n minutes" is a pref that the average user can use. Using such a pref is easy to use and less annoying than dealing with cookie acceptance dialogs. OTOH, if one uses Bugzilla regularly, it would be noce to be able to override the general pref for bugzilla.mozilla.org.

I'm not going to be able to provide the proof-of-concept patch for a while; but I continue to hold the view that Mozilla has excellent underlying cookie management, and we need an interface which reflects that power, even if part of it is concealed by default (e.g. by a twisty.) I still think a "learning" interface is the way to go. Gerv

By "learning" do you mean an interface that pops up dialogs?

I mean one that you teach what you want as you go along, so it has to ask what you want less and less often. So yes, dialogs. Gerv

I have about 400 cookie sites in Mozilla. The vast majority of those (something like 390 sites) are denied parties. It means that Mozilla has *uselessly* bothered me with a dialog *four hundred* times even though most of the time I just click no. That is really annoying and makes no sense considering that there is a know dialogless solution to this problem. Why should Mozilla keep annoying me with dialogs? Why couldn't the known solution (described in my earlier comments) be implemented?

Surely what you want could be implemented by having an "Add Site", in addition to "Remove Site" option in the Cookie Manager? That's a good idea, but I think that other people would appreciate the learning method. You may wish to invest a lot of time up front; other people may like to make decisions on the fly. Others still might combine the two - add a whole bunch of obvious sites to begin with, and then use the dialog when they visit a whole new site because it's far simpler than opening the Cookie Manager. Gerv

I'm by no means suggesting that the way I'd like it was the only way. I'm just trying to advocate the model where you have lists for allow and deny plus limited life for other, because I believe it is the most convenient model for users who don't like persistent cookies and don't like the cookie dialogs but can tolerate random limited-lifetime cookies.

Henri & Gervase, see bug 67580 for my suggestion about temporarily enabled cookie management.

> Cookie decisions need to be made before the site finishes loading, otherwise > javascript tests for cookies will not return the correct result. For that > reason, the cookie warning dialog has to be modal. It does not have to be a traffic light, but I guess we will have to have some sort of non-modal control over cookies. Suppose I have disallowed cookies per default, except for some selected sites. Now I surf to www.whatever.com and the site does not work properly. There should be some kind of hint that the site tried to set a cookie so that I can realize what is going wrong and decide if I want to add this site to the list of allowed sites, allow session cookies for this site or just curse and go elsewhere. I think a good solution to this problem would be a cookie icon in the status bar that might pop up (in the status bar, not as a dialog window) or change color if a site wants to set a cookie and have a context menu with options for allowing or disallowing cookies from this particular site. A reload would then suffice to make the site work as expected.

There's some discussion on cookie UI in bug 75915. Don't let them go anywhere without this bug.

How about this: The user sets their default preferences: New cookies: Reject All / Reject Third-Party / Accept All / Ask New cookie maximum duration: Unlimited / N Days / Session Send cookies to server: Yes / No Whenever a site tries to set a cookie, regardless of whether it is accepted, the site is added to the Cookie Sites list with Status: Default. The user may go into the Site List and override the Default for any site listed. Most users will never see a popup window in this interface, so full cookie details can be provided in the Ask setting. I have a lot of additional ideas if anyone is interested, and suggestions are welcome.

Has this been resolved by bug 98882? It includes the ability to limit cookies in cookie preferences [ ] Limit maximum lifetime of cookies to o current session o [ 90 ] days

No :-) Gerv

I feel really bad that I still haven't found time for this; I started on it, but got rebuffed by the horrible complexity of the JS backing up the Preferences Panel, for which there is no documentation. Appeals for help to ben and blake were ignored. Also, there's a potential clash with the guy doing previewing of fonts. <sigh> Gerv

OK, that's not going to make much sense, given that I meant to say that in bug 61883. :-) _This_ bug I still want to fix, but it's heading into features territory and we don't have time any more. Gerv

I think Henri has some great ideas as well as others. I am VERY willing to help code since this cookie issue bothers me so much. Here is what I would like to see: 1. A way to add domains to a list from which cookies are always accepted. 2. A preference to either accept all other cookies, deny all other cookies, or alter all other cookies to session cookies. 3. A notification (non-modal) that a site wants to set a cookie. Say for instance that I go to a site that needs to set a cookie but I deny, so they don't operate. I would not want to be prompted (modally) about that cookie, but I wouldn't mind if there was a little cookie icon on the status bar or somewhere that would enable me to then accept either just that cookie, all cookies from the site, or accept just the session if all cookies are currently being denied. These are my preferences, and I would love to help code. I see that this bug is currently assigned to Gervase, but if you need any help, or I have misunderstood bugbase, then someone please let me know.

Steve Spigarelli: What do your comments have to do with the UI support for reduced lifetime cookies? Gervase Markham: Why don't you close this out, since we currently have such support in the cookie pref panel?

> Steve Spigarelli: What do your comments have to do with the UI support > for reduced lifetime cookies? It seemed to be perfectly on topic to me. Limiting the lifetime of cookies from certain domains. There may have been no specific mention of reduced lifetime, but it ties in. > Gervase Markham: Why don't you close this out, since we currently have > such support in the cookie pref panel? The current support isn't nearly as fine-grained as it should be. As of now ALL cookies are limited to a certain amount. There is no ability to make some limited to something, and others limited to something else. (Aside from the broadly sweeping categories in the upper part of the UI.) Given the current UI, how do you implement a scheme whereby, for example, site A cannot store cookies, site B CAN store cookies but only for one session, site C can store cookied but only for 1 week, all originating Web sites can store cookied for one month, site D can store cookies permanently, and all other Web sites ask the user if they want to store a cookie or not and, if so, for how long? Granted this is an extreme example, but still not totally unreasonable for those who do require such advanced control over cookies. The UI simply doesn't exit yet. It's now better than nothing, but it's still not perfect.

I believe that my comments have something to do with the UI for reduced lifetime cookies, because the cookie issue at hand is a lot larger than only limiting certain cookies. I think reduced lifetime is a great feature, but without these other features it doesn't give me enough control over the cookies that people set. I am for a UI that supports these reduced lifetime cookies, but that also allows me to reduce the lifetime of cookies in ways that Mozilla does not provide. If there is a bug that is more appropriate for this discussion, I will search for that also. I assumed with all the discussion on UI that has been discussed here that my comments would be ok. I believe that Jason has summed things up very well.

> Gervase Markham: Why don't you close this out, since we currently have such > support in the cookie pref panel? Our backend supports setting much more fine-grained cookie policy, and I believe that this is something that people want. This bug is about implementing it, although it won't be done before 1.0, because it's a feature. That's not to say our current cookie control support isn't good; it is. Gerv

Steve, you might want to have a look at the dependencies of bug 100573 there are a few other bugs mentioned that cover this topic.

Sorry to disappoint, but I'm not going to get to this. Gerv

Gerv, is the attached patch the latest version of your work on the patch? If you got any further, it might be helpful as a starting point.

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

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

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

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

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

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

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

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

I am still missing a feature in the PREFS dialog to be able to set "ask me" when a cookie is to be set, but at the same time to "accept silently" when the cookie to be set expires by the end of the session. This discussion seems to go in another direction (reducing cookie lifetime and/or asking in the cookie dialog rather than in the prefs), but all bugs that were similiar to my feature request were marked dupes of this or smiliar bugs, so I put my comment here.

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

This enhancement request hasn't gotten much attention, so I hope maybe we can poke it a little and see if it wakes up... Konqueror has an elegant solution to this problem that would be worth emulating: In the application settings there is simply a checkbox labeled something like: X - Automatically accept session cookies Checking the box will override any other settings regarding whether or not the user wants to be prompted for cookies. The user can still get prompted to inpect/accept long term persistent cookies, but not short term cookies. I really want to know when a site is setting a persistent cookie, but I hate the cookie popup when a site is setting a cookie that expires at the end of my session. This solution does not change the existing cookie confirmation popup in any way, but would make the browser much more usable. Give it some thought please.

I think we should look at this when we whack wallet/satchel. assigning to myself so i don't lose track of it, feel free to take it if you want mvl...

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

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

I like the scheme that Steve Spigarelli and others had talked about, where different sites can have different limitations as to how long their cookies will be stored. From my standpoint as a user, I think it would be great to have a setup something like this: [X] Limit maximum lifetime of cookies to: (*) current session ( ) 30 days [X] Don't limit cookies that I have explicitely unblocked What this would accomplish: - Sites that need cookies to work properly will be satisfied, but they can't track me - For sites that I trust and use regularly, I could simply do Tools-->Cookie Manager-->Unblock, and they'll have the right to set a persistent cookie. - I wouldn't have to answer to 3-4 cookie dialogs every time I visit a site, nor would I have to guess whether killing the cookie will kill the site as well.

Henri, your solution is bug 75915, "whitelist for sites allowed to store (permanent) cookies". dlaur123@hotmail.com, your solution (and konq's) is bug 64336, "Mode to 'ask before accepting' only cookies that are longer than a session". german@netscape.com, your solution is bug 107813, "cookie accept dialog needs 'Downgrade' option". Clarifying summary to "Pref to limit maximum cookie lifetime".

I just installed mozilla-win32-1.6b-deAT.zip (after removing 1.5) and want to alter cookie preferences, but after clicking OK and opening preferences again, they are not chainged! Especialy, reject Cookies in Mail is not checkt and lifetime limitation, too.

From what i see, you can already limit the max lifetime of a cookie. So there is nothing left to be done here. There are other bugs for other cookie management details. For example, only prompt for non-session cookies is bug 64336.