Closed
Bug 53354
Opened 24 years ago
Closed 21 years ago
Pref to limit maximum cookie lifetime
Categories
(Core :: Networking: Cookies, enhancement, P3)
Core
Networking: Cookies
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: burnus, Assigned: dwitte)
References
Details
(Keywords: helpwanted)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
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.
Comment 1•24 years ago
|
||
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
Reporter | ||
Comment 2•24 years ago
|
||
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
Updated•24 years ago
|
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
Updated•24 years ago
|
Summary: [RFE]UI missing for the support of reduced livetime cookies → [z]UI missing for the support of reduced livetime cookies
Comment 3•24 years ago
|
||
See bug 23508 for other suggestions of additions to the cookie confirmation
dialog.
Ccing mpt, who drew the ascii thing on the other bug.
Updated•24 years ago
|
Summary: [z]UI missing for the support of reduced livetime cookies → UI missing for the support of reduced livetime cookies
Whiteboard: [z]
Comment 4•24 years ago
|
||
Netscape nav triage team: based on Steve Morse's pre-triage recommendation, this
is not a beta stopper.
Keywords: nsbeta1-
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?
Comment 7•24 years ago
|
||
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.
Comment 8•24 years ago
|
||
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
Comment 10•24 years ago
|
||
"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.
Comment 11•24 years ago
|
||
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?
Comment 12•24 years ago
|
||
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.
Comment 14•24 years ago
|
||
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 ... ) |
|...
Comment 15•24 years ago
|
||
*** Bug 64336 has been marked as a duplicate of this bug. ***
Updated•24 years ago
|
Summary: UI missing for the support of reduced livetime cookies → UI missing for the support of reduced lifetime cookies
Comment 16•24 years ago
|
||
*** Bug 69861 has been marked as a duplicate of this bug. ***
Comment 17•24 years ago
|
||
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.
Comment 18•24 years ago
|
||
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.
Comment 19•24 years ago
|
||
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
Comment 20•24 years ago
|
||
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.
Comment 21•23 years ago
|
||
"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).
Comment 22•23 years ago
|
||
wouldn't be somethine like "keep cookie for only this session" better than "let
cookie expire after x days"??
Comment 23•23 years ago
|
||
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
Comment 24•23 years ago
|
||
*** Bug 81226 has been marked as a duplicate of this bug. ***
Comment 25•23 years ago
|
||
> 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
Target Milestone: Future → mozilla0.9.2
Comment 26•23 years ago
|
||
Comment 27•23 years ago
|
||
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"
Comment 28•23 years ago
|
||
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.
Comment 29•23 years ago
|
||
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.
Comment 30•23 years ago
|
||
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.]
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
What about the case where the cookie is set using javascript and immediately
tested for using javascript.
Comment 34•23 years ago
|
||
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.
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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".
Comment 37•23 years ago
|
||
sounds nice :-)
Comment 38•23 years ago
|
||
See bug 67580 for more discussion about making the cookie ui less modal.
Comment 39•23 years ago
|
||
*** Bug 83602 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 40•23 years ago
|
||
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.
Comment 41•23 years ago
|
||
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
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → ---
Comment 42•23 years ago
|
||
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
Comment 43•23 years ago
|
||
> 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.
Comment 44•23 years ago
|
||
Gerv, for the twisty you are supposed to use doron's upcoming widget
<expander/>. Please don't duplicate effort and reinvent it.
CC doron
Comment 45•23 years ago
|
||
> 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
Comment 46•23 years ago
|
||
> 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.
Comment 47•23 years ago
|
||
Comment 48•23 years ago
|
||
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.
Comment 49•23 years ago
|
||
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).
Comment 51•23 years ago
|
||
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
Comment 52•23 years ago
|
||
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.
Comment 53•23 years ago
|
||
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?
Comment 54•23 years ago
|
||
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.
Comment 56•23 years ago
|
||
> (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
Comment 57•23 years ago
|
||
> 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.
Comment 59•23 years ago
|
||
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?
Comment 61•23 years ago
|
||
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?
Comment 63•23 years ago
|
||
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.
Comment 65•23 years ago
|
||
Henri & Gervase, see bug 67580 for my suggestion about temporarily enabled
cookie management.
Comment 66•23 years ago
|
||
> 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.
Comment 67•23 years ago
|
||
There's some discussion on cookie UI in bug 75915. Don't let them go anywhere
without this bug.
Comment 68•23 years ago
|
||
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.
Comment 69•23 years ago
|
||
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
Comment 70•23 years ago
|
||
No :-)
Gerv
Comment 71•23 years ago
|
||
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
Comment 72•23 years ago
|
||
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
Comment 73•23 years ago
|
||
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.
Comment 74•23 years ago
|
||
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?
Comment 75•23 years ago
|
||
> 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.
Comment 76•23 years ago
|
||
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.
Comment 77•23 years ago
|
||
> 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
Comment 78•23 years ago
|
||
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.
Comment 79•22 years ago
|
||
Sorry to disappoint, but I'm not going to get to this.
Gerv
Assignee: gerv → nobody
Comment 80•22 years ago
|
||
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
Comment 81•22 years ago
|
||
*** Bug 117146 has been marked as a duplicate of this bug. ***
Comment 82•22 years ago
|
||
*** Bug 172324 has been marked as a duplicate of this bug. ***
Comment 83•22 years ago
|
||
*** Bug 194689 has been marked as a duplicate of this bug. ***
Comment 84•22 years ago
|
||
*** Bug 195379 has been marked as a duplicate of this bug. ***
Comment 85•22 years ago
|
||
*** Bug 196316 has been marked as a duplicate of this bug. ***
Comment 86•22 years ago
|
||
*** Bug 198930 has been marked as a duplicate of this bug. ***
Comment 87•22 years ago
|
||
*** Bug 198930 has been marked as a duplicate of this bug. ***
Comment 88•22 years ago
|
||
*** Bug 199332 has been marked as a duplicate of this bug. ***
Comment 89•22 years ago
|
||
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.
Comment 90•22 years ago
|
||
*** Bug 200494 has been marked as a duplicate of this bug. ***
Comment 91•22 years ago
|
||
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.
Assignee | ||
Comment 92•22 years ago
|
||
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
Comment 93•21 years ago
|
||
*** Bug 205216 has been marked as a duplicate of this bug. ***
Comment 94•21 years ago
|
||
*** Bug 205793 has been marked as a duplicate of this bug. ***
Comment 95•21 years ago
|
||
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.
Comment 96•21 years ago
|
||
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
Comment 97•21 years ago
|
||
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.
Comment 98•21 years ago
|
||
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.
Description
•