Closed Bug 174070 Opened 22 years ago Closed 28 days ago

GUI for expire cookies on quit pref (session management)

Categories

(Camino Graveyard :: Preferences, enhancement, P3)

Product:
Camino Graveyard
Component:
Preferences
Platform:
All
macOS
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: sbwoodside, Unassigned)

References

Details

(Keywords: good-first-bug, Whiteboard: see comment 58 for how to implement this)

Attachments

(3 files)

Mockup of Cookie Preferences proposal
14.58 KB, image/png
Details
Safari Cookies: Example/mock up for a future Camino cookies pref pane
60.66 KB, image/jpeg
Details
Safari Cookies: Example for a cookies details page
47.42 KB, image/jpeg
Details 
I believe there's a user_pref to expire all cookies when the app quits. Please
add that to the GUI. Personally, it's the only cookies option I've ever used, as
it seems to that it combines the privacy of dumping the cookies with the
usability of having them around for sites that require them.
Summary: [RFE] GUI for expire cookies on quit pref → GUI for expire cookies on quit pref
You can set Preferences -> Cookies to "Limit maximum lifetime of cookies to:
current session." This will expire all cookies when the application quits.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Not in 2002101804. I have: Disable/Enable All cookies and [] Ask me before storing.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Sorry, I didn't realize this was a chimera bug.
It might be helpful to determine what pref is added to prefs.js when the setting
in comment 1 is triggered in Mozilla, and quote it here.
Adding user_pref("network.cookie.lifetime.enabled", true); to my user.js file
seems to elicit the desired behaviour.
*** Bug 177157 has been marked as a duplicate of this bug. ***
Actually, bug 177157 (which I submitted) had a different but related objective.
My proposal was that when accepting cookies temporarily, to accept all from one
site at once. There are some sites where I am willing to store the cookies
long-term, others where I'm not. The enhancement I suggested would facilitate this.
Greg, the pref is

user_pref("network.cookie.lifetime.enabled", true);

I've tested it for about two weeks, it works as advertised.
I agree.  I think this RFE will cover most of the current problems I have with
the cookie support in Chimera 0.6.  The settings I use in Mozilla (that I'd like
in Chimera as well) are:
- Accept cookies from originating web site only
- Maximum lifetime of cookies: Current session only

Should I open a separate RFE to request the preference to not allow 3rd party
cookies?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is there still interest in this feature? I'd be glad to make a patch for it, but
I know that there's a strong desire to keep the prefs lean and I don't want to
make a patch if there's no chance of it landing.

Can anyone give me some idea of whether or not this change would be approved?
Stuart, Simon Woodside and David Haas where working on Bug 182540. It includes a
major step forward in cookie management but nobody really finished it. And as it
stands Simon and David are way to bussy to finish it. If you felt like updating
it that would be excelent. Let us know.
The more I mess with a new panel for Bug 182540, the less I think this option
should be included. Removing *all* cookies on quit seems like something that is
going to be used by relatively few people, and it's also extremely easy to
simply add it to user.js. The 80/20 rule, combined with the fact that those who
do want it can do it anyway, makes me lean strongly toward leaving this out of
the prefs.

I'd suggest WONTFIX, but putting a note about this in the (currently bare)
customization docs at:
http://www.mozilla.org/projects/camino/docs/profileprefs.html
That way prefs stay slim, but people can still find out about this feature.
I've opened bug 238407 as an RFE for listing this on the website.
Priority: -- → P3
Target Milestone: --- → Camino1.1
Updating summary.
Summary: GUI for expire cookies on quit pref → GUI for expire cookies on quit pref (session management)
*** Bug 306542 has been marked as a duplicate of this bug. ***
Now that this bug also includes making UI to downgrade to session cookies: Is
there any plan or consensus on this? 

On the one hand not having this really simplifies the UI, which is good. On the
other hand, downgrading is a powerful feature that I personally use a lot and
probably other people as well.

Perhaps both can be done: below the checkbox for 'remember this' put a button
called 'more' (remember the state, please) which expands the window to show the
content of the cookie and an option to downgrade to session.

That way it does not immediately present you with the options like Seamonkey
does, but the info on the cookie and advanced options are still available to
those who seek it.
I hope that this bug does now include making UI to downgrade (on a per-cookie
basis) to session cookies.  I see no evidence of this, however, and the bug
dealing with that UI element (Bug 173521) has been wontfix'd by TPTB.  The
points in Stuart Morgan's Additional Comment #12 are well taken, which means
that if all this bug does is provide a GUI option for globally downgrading
cookies to session cookies, then it's rather pointless.  One can hope that more
is now involved.
Having "per-session" UI per cookie is way too complex. It's all or nothing, I think.
(In reply to comment #18)

Well, per site is just fine. I have three situations:
- I trust a site and allow it to set long term cookies (bugzilla)
- I do not trust a site and do not allow it to set cookies (most sites,
particularly anything with "ad" in the URL)
- I do not trust a site but I need cookies and therefore set it to session
lifetime (online stores or something)

I can do the first and the second, but not the third.
+++ What Oscar said.

That choice #3 is absolutely key, for the reason Oscar stated.  Seems painfully
obvious to me, but I guess it's not, especially judging from the history of bug
173521.

Whenever the "allow cookie" sheet appears when I use Firefox, I find myself
wondering what's so complex, user-unfriendly or ugly about it.  User-unfriendly
is when an app gives you a "yes/no" choice and you want "sometimes" or "maybe"
or "it depends - let me decide."

Make it a user pref so that users who want the functionality can see it, and
those who don't, don't.

Fixing this, plus session saving (bug 152147), plus confirm closing multiple
tabs (bug 196359) would make Camino damn near feature perfect in my book.
How about a sub-menu in File or Edit.  We'll call it "Cookies".  Once you activate "session cookies", this sub-menu appears.  This sub-menu will list all the cookies for all open windows/tabs (session, obviously).  Selecting a cookie from the menu would add it to your list (hostperm) and allow access.  Selecting a cookie from the menu with option down would add to the list but deny access (and then you would never see that cookie again, even in session).

This has to be possible.
Well. I would like to see a more advanced way to do some "lifetime management" in cookies, like in some browsers like Mozilla (the suite): Accept cookies for "N" days, with N beeing configurable (excuse my poor English.)

This way, ALL cookies would be automatically cleaned when unused (which means "unwanted"...). For the sites I visit often, new cookies will be set and the information will not be lost. But another site, which wants to store an UID for years, will not see its cookie kept.

The idea is somewhat : "The more I like a website, the more often I visit it, so the shorter its cookies need to be kept".


Maybe if a GUI would be too much for this, a "hidden preference" would be OK ?
(Maybe it already exists, but the page about this [1] is not very helpful...)

[1] http://www.mozilla.org/projects/camino/docs/profileprefs.html


I've already got a patch (which IMO complicates things not at all) for the GUI in the Exceptions list in Preferences (see bug 302865).

I think we can handle the GUI in Preferences very simply too -- just add a checkbox for "Session cookies only" as shown in the mockup in the attachment.

The trickiest part of this bug is going to be how we implement the necessary modifications to the cookie request sheet. My personal preference would be for the addition of a third button titled "Allow for Session" between "Deny" and "Allow". I think that allows all possibilities with a minimum of confusion for users, while making things acceptable to power users.

Simon, Mike, Stuart, etc., what say ye?

cl
Chris, I think that's a reasonable solution. As long as I'm commenting here, I'll mention another slight misbehavior in the cookie-allowing process.

If you select the pref "accept cookies only from sites you visit" AND turn on "ask before accepting each cookie", you will be presented with a sheet for every cookie  encountered when visiting a site, including those set by other sites. For example, if you visit cnn.com, you'll be asked to accept a cookie from cnn and also some advertiser.

Ideally, I think, the "accept cookies only from sites you visit" should work with the "ask" preference, so that you are only presented with a cookie request from the site you are visiting.
(In reply to comment #24)
> Chris, I think that's a reasonable solution. As long as I'm commenting here,
> I'll mention another slight misbehavior in the cookie-allowing process.
> 
> If you select the pref "accept cookies only from sites you visit" AND turn on
> "ask before accepting each cookie", you will be presented with a sheet for
> every cookie  encountered when visiting a site, including those set by other
> sites. For example, if you visit cnn.com, you'll be asked to accept a cookie
> from cnn and also some advertiser.
> 
> Ideally, I think, the "accept cookies only from sites you visit" should work
> with the "ask" preference, so that you are only presented with a cookie request
> from the site you are visiting.

That's actually a totally separate issue, and I couldn't find an open bug on it. I agree that our current behaviour is wrong, and I've filed it as bug 318574.

cl


(In reply to comment #23)

> modifications to the cookie request sheet. My personal preference would be for
> the addition of a third button titled "Allow for Session" between "Deny" and
> "Allow". 

So if you don't have session cookies checked in the prefs (but have "ask" enabled), that button's going to be greyed-out on every request sheet, right?
(In reply to comment #26)
> (In reply to comment #23)
> 
> > modifications to the cookie request sheet. My personal preference would be for
> > the addition of a third button titled "Allow for Session" between "Deny" and
> > "Allow". 
> 
> So if you don't have session cookies checked in the prefs (but have "ask"
> enabled), that button's going to be greyed-out on every request sheet, right?

Two ways to answer that...

1) I don't want ALL cookies to be session cookies. I want to be asked every time to choose (after all, that's why I have "ask" set in the first place).

2) I think that sheet is created in code, so there's nothing that says we have to even *display* that button if the pref for session cookies is unchecked.

I don't think those two ideas are mutually exclusive, but I might be wrong. I do think, as I said before, this is by far the trickiest bit of UI we have to deal with for this bug.

cl
(In reply to comment #27)

> 1) I don't want ALL cookies to be session cookies. I want to be asked every
> time to choose (after all, that's why I have "ask" set in the first place).

1a) But the number of cookies I would allow to persist is very small, such that I wouldn't mind accepting "session" as the default option and choosing "allow" the few times I want to let it persist.

cl
(In reply to comment #23)

> The trickiest part of this bug is going to be how we implement the necessary
> modifications to the cookie request sheet. My personal preference would be for
> the addition of a third button titled "Allow for Session" between "Deny" and
> "Allow". I think that allows all possibilities with a minimum of confusion for
> users, while making things acceptable to power users.

Could we also add a disclosure triangle for those who want to see the details of the cookie whose fate they are deciding?  This would be equivalent to Seamonkey's and FF's Show/Hide Details button, with less UI clutter.
Quite frankly, I do not care that much about the content of a given cookie, as that is usually gibberish anyway (feel free to disagree).

I just want to be able to decide on a site by site basis if I will downgrade to session cookies or not..
(In reply to comment #30)
> Quite frankly, I do not care that much about the content of a given cookie, as
> that is usually gibberish anyway (feel free to disagree).
> 
> I just want to be able to decide on a site by site basis if I will downgrade to
> session cookies or not..

OK, I'll disagree.

FF's Allow Cookie sheet, if you have Show Details turned (via the conveniently-placed button), tells you at a glance:
* The cookie's name
* The content (agreed, usually gibberish, but not always)
* The host
* The path
* Whether it's secure or not (i.e. whether it works only over a secure connection or over any connection), and
* When it is set to expire.

Some of that information is potentially useful in deciding a cookie's fate.

As for a UI element, a disclosure triangle would be all that would be needed.  Clean, not in your face, but available to users who want and use  the functionality.
OK, so everyone seems to like the FF interface, as long as we can exchange the show/hide button for an unfolding triangle.

I would personally settle for the thing without the show details option, but the commentators here seem to want the full monty.

Any chance of this making it in to Camino 1.0? I still do not use it simply for the reason that this functionality is lacking. I was sort of hoping that the fact that the options are already available in FF and the backend is readily available in gecko 1.8 that this wouldn't be too painful to implement.

Thanks in advance,
 Oscar
(In reply to comment #32)
> Any chance of this making it in to Camino 1.0?

No. Which is why it's targeted for 1.1.


In the interest of making some of these relationships a little clearer, this should block bug 302865.

cl
Blocks: 302865
Err, bug 302865 should block this, I mean. Oops.

cl
No longer blocks: 302865
Depends on: 302865
To do this as requested is going to require a Core change. (See bug 249596.) "Ask" and "Session only" are currently mutually exclusive; if you select "session only", you won't have control over whether or not cookies can be set.

If you select "Ask", you can choose each time. I have a patch for the alert sheet to add a "allow for session" option, which I'll be attaching to the one remaining bug we have on this (bug 302865).

We can keep this open for now, but like I said, it's not going to be a viable option until the Core changes are made. As such, this is definitely NOT going to make Camino 1.1, and likely won't make 1.2.

Assigning to myself; at such time as Core fixes this, I'll take it.

cl
Assignee: sfraser_bugs → bugzilla
Depends on: 249596
No longer depends on: 302865
Retargeting to "Future" per my comment 36.

cl
Target Milestone: Camino1.1 → Future
Why not give the user the choice of ask vs. session only? It seems like there is a reasonable number of people who'd want session-only, no ask.
(In reply to comment #38)
> Why not give the user the choice of ask vs. session only? It seems like there
> is a reasonable number of people who'd want session-only, no ask.
> 
This is exactly what I though the whole point of session cookies was.  I don't want to be asked about cookies (it's gets very annoying very fast) and at the same time don't want tons of cookies being saved.  Yet I want to accept all, so websites can function.
(In reply to comment #38)
> Why not give the user the choice of ask vs. session only? It seems like there
> is a reasonable number of people who'd want session-only, no ask.

Because then we have to add an entire UI for the lifetimePolicy pref (documented at http://www.mozilla.org/projects/netlib/cookies/cookie-prefs.html , by the way), which is going to make our privacy prefs pane HUGE.

We already respect the pref. There's just no GUI for it, and I don't see any way to make one that isn't horribly awkward.

cl
(In reply to comment #40)
 
> We already respect the pref. There's just no GUI for it, and I don't see any
> way to make one that isn't horribly awkward.

No, Camino doesn't respect network.cookie.lifetimePolicy. Just checked with the latest nightly. It would be great if it did...
(In reply to comment #41)
> (In reply to comment #40)
> 
> > We already respect the pref. There's just no GUI for it, and I don't see any
> > way to make one that isn't horribly awkward.
> 
> No, Camino doesn't respect network.cookie.lifetimePolicy. Just checked with the
> latest nightly. It would be great if it did...

Just checked with the latest nightly. It most certainly does.

You very likely have some sites whitelisted. Make sure there's nothing in your exceptions list (or that you're ignoring the sites in the exceptions list whose status is "Allow") and try again. Setting lifetimePolicy to 2 deletes all cookies on quit.

cl

(In reply to comment #42)

OK, problem was that it only deletes _new_ cookies and does not touch cookies accepted earlier. Somewhat different from what I expected from the mozilla pref, which reads "Keep cookies until I close...". This led me to expect _all_ cookies to be deleted. Is this a feature or a bug?
Cookie policy is only supposed to apply to the handling of new cookies. Existing cookies and whitelist entries are not affected.
What about a "Lifetime Policy" checkbox to enable and an "Edit" button that opens a sheet/dialog with a 3 item radio button for Ask, Session, and N days? Default the checkbox to off. That keeps the main Preferences UI clutter down, gives power users full access without going to pref.js, and doesn't depends on an update to Core. The Policy dialog could easily just be maintained to mirror the supported settings for network.cookie.lifetimePolicy.
(In reply to comment #45)
> What about a "Lifetime Policy" checkbox to enable and an "Edit" button that
> opens a sheet/dialog with a 3 item radio button for Ask, Session, and N days?
> Default the checkbox to off. That keeps the main Preferences UI clutter down,
> gives power users full access without going to pref.js, and doesn't depends on
> an update to Core. The Policy dialog could easily just be maintained to mirror
> the supported settings for network.cookie.lifetimePolicy.

The problem with this is it still exposes confusing UI to n00bs *and* it doesn't really offer any improvement over what we have right now (other than exposing the "Session" option).

If we're going to expose that option at all (i.e., if we're going to fix this bug), a session option should simply be added to the radio button set that currently controls the lifetimePolicy pref. And therein lies my main logic for WONTFIXing this bug: too many options exposed in too many places, leading to a whole lot of confusion, ESPECIALLY when users try to figure out why they can't set "force session cookies" and "ask each time".

Per that, and per Stuart's comment 12, and per my comment 36, I'm WONTFIXing this bug. At such time as Core makes the necessary changes to support a more logical pref, we can re-think this decision.

I have a feeling that once the other session cookies bugs land, the demand for this will be virtually nil anyway.

Sam, can you make sure we have this adequately documented on cb.o, please?

cl
Status: NEW → RESOLVED
Closed: 22 years ago → 18 years ago
Resolution: --- → WONTFIX
reopening to clarify. This is what we want:

- a single checkbox in prefs that when checked, will set all accepted cookies to expire when the session ends
- if it is not set, add another button named "session only" to the accept cookie dialog to allow a cookie to be set as a session cookie.

however we need to invent new prefs or contort the core apis to get this, this is the UI that we want. We don't care about cookies accepted before they turn on session cookies.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
I made a suggestion in the Core bug mentioned in comment #36 to take Ask out of the lifetimePolicy setting. When you think about it, the lifetime should really only apply to accepted cookies. I think that would help get this implemented in a way that doesn't conflict with the lifetimePolicy settings.
(In reply to comment #48)
> I made a suggestion in the Core bug mentioned in comment #36 to take Ask out of
> the lifetimePolicy setting. When you think about it, the lifetime should really
> only apply to accepted cookies. I think that would help get this implemented in
> a way that doesn't conflict with the lifetimePolicy settings.

Right, but since Core is pretty much not going to fix that, we're going to have to do this on our own. It's doable; I just didn't think we wanted to invent a new pref for it, but if pink says it's OK, I'll fix it.

Right now I'm waiting on the other session cookie stuff to land and then I can get started on this. It should be pretty simple to fix, but I don't want to create multiple interdependencies among three different patches. If all goes well, I should be able to have this patched by next week.

cl
Targeting for 1.1, fixing dependencies. 249596 isn't going to get fixed, and 302865 and 323842 need to land before this can be worked on.

cl
Depends on: 302865, 323842
No longer depends on: 249596
Target Milestone: Future → Camino1.1
I'm not going to be getting to this anytime soon, but someone else should feel free to work on it if desired. I'd be happy to provide sample code, suggestions, etc.

cl
Assignee: bugzilla → nobody
Status: REOPENED → NEW
QA Contact: bugzilla → preferences
Whiteboard: [good first bug]
What this needs now is a 4th radio button "Accept all [new] cookies for this session only" that sets user_pref("network.cookie.lifetimePolicy", 2); and disables the "Ask before" button.

--> pref-master froodian
Assignee: nobody → stridey
Depends on: 344036
It can't be a radio with the behaviors (all sites, visited sites, none) because it's not exclusive with them.  You might want session+all sites, or you might want session+visited.

It can't be a checkbox, because it's exclusive with asking. (Camino could perhaps seriously bend the prefs, but that would be a lot of work for the marginal value mentioned in bug 249596 comment 4--if you are already asking every time, what's the utility in having one less button?)

It could be a radio with ask, but then there has to be a default, and labeling those radios buttons is very unpleasant.

If this were straightforward to fix, I'd have done it two years ago.
No longer depends on: 344036
Assignee: stridey → nobody
*** Bug 359626 has been marked as a duplicate of this bug. ***
Target Milestone: Camino1.1 → Camino1.2
Ideally, IMHO, feature wise, what Firefox 2 stable builds have out currently. 

Accept from sites checkbox w/
A pulldown called Keep until:
      * I close
      * They expire
      * Ask me

and then an exceptions button that shows the exceptions (AND allows you to edit them - including ADD)

Agree with Smokey Ardisson, having a means to set user_pref("network.cookie.lifetimePolicy", 2) is really all I know I'm looking for. (keep persisted cookies but dump all new ones) I keep having to set it back everytime I wish to legitimately add/keep a new cookie to the cookies.txt file.  If this needs to be a different feature request I'd be happy to put it in.
Target Milestone: Camino1.6 → ---
Unless they have fixed it after I initially posted this, Firefox keeps your cookies regardless if you have checked "Keep until I close..." from the cookie's 'accept from sites' pull-down menu ONLY IF you experience a fatal error while still logged in or still using those cookies.  If a fatal error happens while you are using the cookies or still logged into whatever website you are using cookies for then, somebody who accesses your computer can simply "restore last session" and has access to that exact same address and the cookies are remembered, so they don't have to log in again.  This is a serious security feature that I can't believe has been overlooked.  Everyone stresses how Internet Explorer is so unstable and lacks security features, but here's a very important overlooked security flaw for Mozilla...
This is a Camino bug, and thus not the right place to discuss Firefox security.
If we really want comment 47, then we can do that; looking at the code it actually wouldn't be too messy. We'd need to handle the two checkboxes as follows:
- If just one (or neither) is set, set the appropriate lifetimePolicy value.
- If both are set, set lifetimePolicy to ask, and set a Camino-only pref, then in CocoaPromptService check that pref, and if it's set show a two-button dialog with Deny and Allow for Session.
I think that the interface of Safari Cookies (as of version 0.62) is an easy and intuitive way of managing cookies. On the one hand you can use session control cookies for all sites and still allow the long term storage of cookies for some select sites (called Favourites in Safari Cookies).
On the other hand Safari Cookies also cares about Flash cookies, which IMHO is an appropriate measure these days.

More information on Safari Cookies can be found here: http://sweetpproductions.com/safaricookies/

Also I uploaded two screenshots of the Safari Cookies preference panes (main pane and cookie details pane) as an attachment.
The cookies, which should be kept permanently (i.e. until they expire) can be marked as Favourites in the first row of the table
There is no chance we are adding that much UI for session cookies; if someone wants that for Camino they'll need to write a similar third-party add-on.

This bug is purely about implementing comment 47 (via comment 58). The UI is already decided, it's just a case of someone with the time and inclination implementing it.
Hardware: PowerPC → All
Whiteboard: [good first bug] see comment 58 for how to implement this
Keywords: good-first-bug
Whiteboard: [good first bug] see comment 58 for how to implement this → see comment 58 for how to implement this
Status: NEW → RESOLVED
Closed: 18 years ago → 28 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: