67580 - [RFE] cookie-managing ui with fewer dialogs

Status: VERIFIED DUPLICATE of bug 75915

(Core :: Networking: Cookies, enhancement)

Description

[Jesse Ruderman]

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?

Comment 1

[Stephen P. Morse]

.

Comment 2

[Matthew T (active 1999-2002)]

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

Comment 3

[Jesse Ruderman]

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.

Comment 4

[Matthew Tuck [:CodeMachine]]

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.

Comment 5

[timeless]

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.

Comment 6

[risto.kankkunen]

[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]

Comment 7

[Jesse Ruderman]

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.

Comment 8

[Diego Biurrun]

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.

Comment 9

[risto.kankkunen]

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?

Comment 10

[Gervase Markham [:gerv]]

> 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

Comment 11

[Diego Biurrun]

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

Comment 12

[risto.kankkunen]

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

Comment 13

[risto.kankkunen]

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.

Comment 14

[S Spigarelli]

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.

Comment 15

[Stephen P. Morse]

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.

Comment 16

[Jesse Ruderman]

Continued in bug 174556...

Comment 17

[Jesse Ruderman]

Reopening to mark as a dup of bug 75915.

Comment 18

[Jesse Ruderman]

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

Comment 19

[benc]

V/dupe.