Several people have told me that they don't use "Warn me before storing a cookie" because it creates a dialog on almost every website they visit. While many dialogs have been eliminated through "remember this decision" (which will hopefully be turned into "accept/reject/always/never" to make keyboard use of the dialog easier and more consistent (bug 53354)), the option still produces a lot of dialogs for normal websurfing. I'd prefer if Mozilla would show an icon indicating "this site has a cookie" in the status bar. Different colors/icons would mean "accepted for interval specified by cookie", "accepted for session", and "won't send back to server and will delete at end of session". I should be able to set default acceptance- levels for same-domain cookies and for other-domain cookies (I'd use "accept for session" and "won't send back" as my defaults). From the icon, I should be able to quickly: - see the site name and cookie name (tooltip) - accept the cookie (click) - reject the cookie (double-click) [or click to toggle accept/reject] - open Cookie Manager and select the cookie (alt-double-click) Things to discuss: - What happens when an image from another domain tries to *read* my cookie for that domain? - Should each cookie be displayed separately, or should all cookies from a site be grouped together? Should this be a pref? - Which dialogs would still be necessary? - Should the old "warn me before setting a cookie" setting still be available? - How should keyboard access to the feature work?

.

I don't think this is possible, because in many cases the content of a Web page depends on which of the cookies sent with that Web page have been accepted. So I don't think you can show the page before the decisions about the cookies have been made. [Reassigning to default component owner -- if you're not going to resolve this bug yourself, or to reassign the bug to someone who will, `.' is not adequate explanation for that decision.]

You're right that this UI wouldn't make much sense if the user's default was "reject cookie" or "store cookie but don't let the site see it". On the other hand, people who want to reject cookies by default and not see a dialog should get some indication that a site is trying to set cookies, so they can set Mozilla to accept cookies from the site and then reload the page.

Also maybe you could accept it and then have the option to blow away all the site's cookies. Maybe this status indicator could also show whether there are any existing cookies even if not just accepted.

how about a sidebar that lists all of the cookies sent w/ the current page? each cookies name, value, expiry and other info could be listen, plus options to edit, block, delete.

[I already wrote something about this into bug 53354] I support the idea of making the cookie UI less modal. It cannot be totally non-modal, but the browser shouldn't needlessly make it completely modal either. Since cookies are transmitted along normal page contents, there should be no reason not to show the content before the accompanying cookie is accepted or rejected. After all, the content ends up displayed identically regardless of what you do with the cookie. The only thing to keep an eye on here are situations where the server could change its behavior based on cookie settings. But the server only gets to know cookie values when the browser sends them to the server, and this happens only when the browser is requesting new content from the server. Furthermore, I think the server cannot make any assumptions about the order of requests for the sub-elements (e.g. pictures) of a document and thus cannot rely on that those would carry back the cookies set by the containing document. So the earliest point the server could change its behavior is when another document is loaded from the same server, either by user action (following a link) or by a redirect request or some other means. And this is how long you can avoid to decide whether to accept a cookie or not. In practice it's better to make the decision before leaving the current page. For the client side, the cookies should be accepted or rejected before any script code tries to access a particular cookie. I haven't checked the Cookie Manager API, but I think something along the following lines could be implemented. A setCookie(...) call would place a cookie into cookie buffer. This buffer should have some kind of an UI for the user to asynchronously view, accept and reject cookies placed into it. An automatically opening side bar is one option. A flushCookies(...) call would accept or deny (based on the user preferences) all _remaining_ cookies in the buffer. This would be called by the browser when it is leaving a page. A confirmCookies(...) call would make the user to accept or deny all the _remaining_ cookies in the buffer. This would be called by the browser before any non-user-initiated page load (e.g. after receiving a redirect with cookies and before loading the new page). A confirmCookie(...) would make to user to accept or deny a particular cookie. This could be called from getCookie(...) to make it block until the queried value has been decided. In practice this would mean that if I have configured Mozilla to ask confirmation to cookies, a side bar would open automatically when I enter a page that sent cookies. I could surf normally without paying any attention to the cookies if I so wish. Depending how I have set my preferences, all the cookies shown in the side bar would be accepted or rejected when I go to another page. Or I could expand details of some particular cookies, reject another, accept yet another shortening the list of unconfirmed cookies in the side bar. Or I could press Accept All or Reject All to clean off all remaining unconfirmed cookies, at which point the side bar would automatically close. If a script tries to use a cookie that is still unconfirmed (i.e. in the side bar), that cookie would be highlighted and I would have to accept or reject it before I could go on. Same for redirect responses except that all the cookies set by that redirect would be highlighted in the side bar. Do you see any major problems with this approach (not including the UI)? The UI can be done in many different ways, this is just one idea. [sorry to be so verbose]

I think it's possible to have a completely non-modal cookies interface if the default action is to "accept for session". Web sites won't be able to tell whether you've accepted the cookie for a year or for the session, so they'll assume you've permanently accepted the cookie. If the user plans to return to the site and wants to be remembered, he/she could then click an icon to change "accept for session" to "accept" for the site, and the browser wouldn't throw away the cookie on exit. The default setting would be to always accept cookies, so that new users don't have to learn when to click "accept" if they don't want to.

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. 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.

Jesse, you're right. However, I might want to not send out any cookie I don't specifically approve of. But even that situation can be improved, or what do you think about this idea: Normally all cookies would be rejected. If you go to a site which want's cookies, you'll end up to a error page telling so. Go back to a login page or what ever (usually there is a link in the error page, or use your Back button). Now select the menu item or button for something like "Accept cookies for this page". This would _temporarily_ turn on cookie management for that single page (and reload the page to get the cookies it sent). You would now be presented with the usual dialogs to accept or reject any particular cookie, either once, for the session all always. After the page has been loaded, the cookies are again disabled completely. This would mean that normally you don't need to do anything. Only when something goes wrong, or you anticipate that you need cookies (e.g. you are in a login page), you would be presented with some questions. How to present the questions is another matter. You could use the current dialogs or something improved (I still believe the scheme I proposed on 2001-06-01 10:15 would work...), it can be decided/worked on separately. Comments?

> Since cookies are transmitted along normal page contents, there should be no > reason not to show the content before the accompanying cookie is accepted or > rejected. After all, the content ends up displayed identically regardless of > what you do with the cookie. This is not true, as JavaScript in the page may check for the presence of the cookie. The cookie interface has to be modal; and this rather disallows the traffic light (which, in any case, would surely be far harder to understand for an average user than the dialog system.) Users who hate the dialogs more than they hate the privacy problem turn them off; those who don't, don't. This isn't to say we shouldn't make the dialog system as smart as possible - see back to bug 53354. Gerv

> cookie. The cookie interface has to be modal; and this rather disallows the > traffic light (which, in any case, would surely be far harder to understand for > an average user than the dialog system.) Average users do not use cookie management. We should never forget that we are targeting power users here. 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.

> This is not true, as JavaScript in the page may check for the presence of the > cookie. The cookie interface has to be modal; Gerv, like you say a script _may_ (or _may not_) check for the presence of a cookie, like I point out in the same comment on 2001-06-01 10:15: > For the client side, the cookies should be accepted or rejected before any > script code tries to access a particular cookie. So any sent cookie will be placed into a holding area with the status unconfirmed. When a script tries to check for a cookie, the script must be stopped until the user has confimed to accept or reject that cookie. Thus _in this case_ the UI would degrade to modal, but dictated by the script, not the browser. So the cookie interface does not have to be modal. About modality, the case is that the browser currently interrupts the user too often and without a good reason. This bug contains a number of separate ideas to decrease modality related to cookie management. Especially I my latest idea on 2001-08-22 23:41 could solve almost all of my cookie problems while being easy to implement as well: we just need an easy/accessible/discoverable way of turning cookie "warnings" on (easy) and have them automatically turn off again when moving to a new page (a bit harder). Then I could have all other cookies rejected as specified by my preferencies.

Jesse, could you clarify your original suggestion? After thinking about this, I think an icon showing the current mode of my cookie policy and allowing me to change it easily by clicking it would help a lot. In your suggestion I understand that this icon would show information about the cookies themselves? How would this work, when the page has a number of cookies? I think a sidebar might be a reasonable place to show this info, like timeless proposes on 2001-02-04 04:01. It wouldn't block viewing the page like a modal or non-modal dialog.

I have been checking out IE 6.0 and am determined that it has one of the best cookie handling features that I have seen. It works basically along the lines of the stop light functionality. It allows a user to reject/accept/confirm all cookies by default. It also allows the entry of sites that bypass this filtering. When a site attempts to set a cookie and it is blocked, there is an icon that is displayed in the status bar that lets the user know that the site has attempted to set a cookie. Then, by clicking on this icon a list of attempted cookies is displayed and the user can then accept/reject this site's cookies. Some have commented that a script will not have access to the cookies information. I think this is great - after reviewing the cookies that are supposed to be set, the page can then either reload accepting these new cookies, and the script will now have access. This gets rid of all useless dialogs, and allows for complete privacy if desired, but also allows for the average user to either use the default accept all cookies. I am willing to help on the coding of this feature. One of the features that I notice IE lacking is the ability to accept only a cookie for the session, or accept only the cookie, and not all cookies from the site.

This bug report doesn't seem to have any focus. If someone has a specific rfe that they are proposing, then please do so in a separate, uncluttered bug report. Many of the things aluded to in this report have now been done in one way or another in the p3p icon that appears in the status bar when the users p3p settings have altered the normal processing of a cookie.

Continued in bug 174556...

Reopening to mark as a dup of bug 75915.

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

V/dupe.