Closed Bug 53354 Opened 24 years ago Closed 21 years ago

Pref to limit maximum cookie lifetime

Categories

(Core :: Networking: Cookies, enhancement, P3)

Product:
Core
Component:
Networking: Cookies
Type:
enhancement

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: burnus, Assigned: dwitte)

References

Details

(Keywords: helpwanted)

Attachments

(2 files)

Fix, version 1
7.22 KB, patch
Details | Diff | Splinter Review
Incomplete Fix, version 3. Should have morse' suggestion implemented, but does not run, needs debugging.
8.74 KB, patch
Details | Diff | Splinter Review 
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 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: Support store cookie for this session only → UI missing for the support of reduced livetime cookies
Status: REOPENED → ASSIGNED
Summary: UI missing for the support of reduced livetime cookies → [RFE]UI missing for the support of reduced livetime cookies
Target Milestone: --- → Future
Summary: [RFE]UI missing for the support of reduced livetime cookies → [z]UI missing for the support of reduced livetime cookies
See bug 23508 for other suggestions of additions to the cookie confirmation 
dialog.

Ccing mpt, who drew the ascii thing on the other bug.
Summary: [z]UI missing for the support of reduced livetime cookies → UI missing for the support of reduced livetime cookies
Whiteboard: [z]
Netscape nav triage team: based on Steve Morse's pre-triage recommendation, this 
is not a beta stopper.
Keywords: nsbeta1-
*** 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.
Status: ASSIGNED → NEW
Keywords: mozilla1.2
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.

.
Assignee: morse → nobody
Whiteboard: [z]
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. ***
Summary: UI missing for the support of reduced livetime cookies → UI missing for the support of reduced lifetime cookies
*** 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.)
Assignee: nobody → ben.bucksch
Keywords: mozilla1.2, nsbeta1- → review
Target Milestone: Future → mozilla0.9.2
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. ***
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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.
Keywords: review
Whiteboard: Partially fixed, but rejected
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → ---
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
Assignee: ben.bucksch → gervase.markham
Whiteboard: Partially fixed, but rejected
Target Milestone: --- → mozilla0.9.4
> 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
Target Milestone: mozilla0.9.4 → mozilla0.9.6
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.
Blocks: 100573
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
Target Milestone: mozilla0.9.6 → mozilla0.9.7
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
Target Milestone: mozilla0.9.7 → mozilla1.1
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
Assignee: gerv → nobody
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.
Keywords: helpwanted
Target Milestone: mozilla1.1alpha → Future
*** 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...
Assignee: nobody → dwitte
*** 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".
Summary: UI missing for the support of reduced lifetime cookies → 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.
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: