Closed Bug 232744 Opened 20 years ago Closed 16 years ago

Remove pref 'limit cookie lifetime to n days'

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mvl, Unassigned)

References

Details

Attachments

(2 files, 3 obsolete files)

more streamlined interface
3.97 KB, text/plain
Details
with review nits from 64336, and a couple other tweaks
11.22 KB, patch
dwitte
: review+
Details | Diff | Splinter Review 
I suggest to remove the pref to limit the lifetime of cookies to n days. I don't
think it is much used, and it makes an ugly ui.
This doesn't mean to remove the pref to downgrade cookies to session cookies,
which can be more useful.
And if firebird can do without it, why not seamonkey? :)
added bonus, we can kill all of the MOZ_PHOENIX #ifdefs if we do this.  The
mailnews ones should be using #ifdef MOZ_MAIL_NEWS anyway, since if someone
builds navigator only they don't need it
->me, blocks 222561
Assignee: darin → mconnor
Blocks: 222561
just putting this up here, no UI changes in this patch either, I need to respec
that today, and I'll post in the appropriate bug.

I want to get all of this in for 1.7a, get some feedback/whining/death threats
early,	so if we need/want to backtrack, we have lots of time before 1.7 :)
Status: NEW → ASSIGNED
FYI, don't try to build with that patch, I left an extra line in the header file.

The one issue remaining is whether we should have something to migrate the old
prefs.  I could go either way, as long as it doesn't get too ugly, and we commit
to removing that part of the code after 1.7.

Also, assuming someone actually uses this pref, do we migrate them to
session-only or just no longer honour the pref and don't change the expiration?
Why isn't this pref useful ?
FYI: I don't use the cookie manager but I use this pref because many pages set
their cookie expiration time to 4 or more years ..
It's a good way to keep the cookie file clean (nuke old entrys)
"I don't think it is much used, and it makes an ugly ui."

Fix the UI, if you hate it that much, but don't remove it. Btw, WONTFIX is the
only good option to close this bug.
but why keep it at all?  You didn't address that.  Other than purging unused
cookies after a certain amount of time (which is mostly a cosmetic and not a
perf issue at this point), what tangible benefit is served by preserving this pref?
(In reply to comment #5)
> Why isn't this pref useful ?
> FYI: I don't use the cookie manager but I use this pref because many pages set
> their cookie expiration time to 4 or more years ..
> It's a good way to keep the cookie file clean (nuke old entrys)

You can downgrade the cookies to session cookies, so they will be gone after you
close mozilla. If you do want to keep cookies for a site, just whitelist it.

Hmm, this reminds me of this: "All too often, I see someone with the attitude,
"I wrote it this way because that's how I wanted to write it, and I know what
you want/need better than you do ... so you WILL like it.".

I guess you don't need it, that is perfectly clear to me. I guess you can't fix
the UI, without removing 'something' other people need, right? 
If someone can explain me why the pref is needed, and the suggested solution
with downgrade to session and whitelisting won't work, we can give this a second
thought.
I can no longer restart Mozilla after a crash/hang without being forced to login
again, because my cookies are gone. Also, sometimes I simply need to restart
mozilla, to enable/disable add-ons/extensions but this won't allow me to
continue without a forced login. 

Now, I have a lot of co-workers and we will all have the same problem with
mozilla, so please don't remove this pref UI, or don't remove the back-end code.

Also, I will have to clear my cookies after n days by hand, because you removed
a simple but powerful feature.
> You can downgrade the cookies to session cookies, so they will be gone after you
> close mozilla. If you do want to keep cookies for a site, just whitelist it.

A downgrade to Session cookies is bad because you will loose all new cookies
that you want to save, such as google prefs.
Why do you want to remove a working and perfect feature ? 
I can't see a reason for that. Fix the UI if you think that the UI is ugly.
 
"I will have to clear my cookies after n days by hand, because you removed
a simple but powerful feature."

Amen to that!

"And if firebird can do without it, why not seamonkey? :)"

Because the mozila suite != mozilla Firebird?

Also, MSIE has no tab UI and no popup blocker, still it is THE most used
browser. Are you planning to remove these items also? Same bad logic...
no one has given a reason why clearing unused cookies after X days is necessary
or beneficial.  If a cookie is unused for a few days or longer, what detrimental
effect does it have on performance or privacy?

What is the value of X that you guys use?
> I can no longer restart Mozilla after a crash/hang without being forced to login
> again, because my cookies are gone. Also, sometimes I simply need to restart
> mozilla, to enable/disable add-ons/extensions but this won't allow me to
> continue without a forced login. 

If the sites uses seesion cookie for the login, it wont work anyway. If it uses
long living cookies, why not whitelist it? that way, you don't even have to log
in the next day....

> A downgrade to Session cookies is bad because you will loose all new cookies
> that you want to save, such as google prefs.

Not if you whitelist google.com in the cookiemanager.

And removing is not about just the ui. It is about those tiny bits of code that
make the whole thing bloated and difficult to explain. So it is about cleaning
up in general.
> why not whitelist it? 

I use over 300 websites for my work so that's out of the question. The sites
change every week or so, what a waste of time.

> that way, you don't even have to log in the next day....

That would be a real security hazard don't you think?

> What is the value of X that you guys use?

X can be anything because it depends on the work I'm doing.

>Not if you whitelist google.com in the cookiemanager.

What is the total number of cookies that can be stored in mozilla? When does
mozilla start to overwrite your cookies?
(In reply to comment #14)
> no one has given a reason why clearing unused cookies after X days is necessary
> or beneficial.  If a cookie is unused for a few days or longer, what detrimental
> effect does it have on performance or privacy?

You don't give us a reason why do you want to remove a working feature. You
can't assume that this feature isn't much used and I can't see a reason why Do
you want to remove it.




reasons? because we're trying to streamline the interface and the number of
prefs we use to make it work.

Neil, if you're using over 300 sites on a week-in, week-out basis, and those
sites constantly change, you're probably already overwriting the cookies.  mvl
or dwitte can correct me if I'm wrong, but afaik Mozilla currently maxes out
around 300 cookies, after which it starts overwriting the oldest ones.  So with
"over 300 sites" the old cookies would be gone pretty quickly.  Also, if you're
using cookies to maintain a login session, wouldn't that be a security hazard
regardless of how long the cookie is kept for?

Matti: just because a feature works doesn't justify keeping it.  The tendency is
always to just add and never subtract features, which is what creates bloatware.
 Through the last two cycles we've been attempting to simplify and streamline
cookie management, and this pref doesn't fit with the plans we have come up with.
This is Seamonkey and not Firebird and this pref is used from many people. That
Firebird doesn't have a pref for this doesn't mean that this is unused in Seamonkey.

All the ad-cookies are deleted through this pref while the important cookies
from x Forums, google, bugzilla and many other sites are still there (they will
be refreshed with each visit).

A streamlined interface doesn't seem to be enough reason to kill it !
(In reply to comment #18)
> Neil, if you're using over 300 sites on a week-in, week-out basis, and those
> sites constantly change, you're probably already overwriting the cookies.

Exactly, so don't you think that white listing is gonna suck because of this?
Why do you think this was limited to only 300 cookies? Remember, this is just
the minimum number of cookies a browser should store. Ok, this is another well
known bug, but this will hamper white listing.

> Also, if you're using cookies to maintain a login session, wouldn't that be 
> a security hazard regardless of how long the cookie is kept for?

Yes, but that's not how it works and that's not what it is used for.

> just because a feature works doesn't justify keeping it.

Oh, and just because *you* don't need it justifies removing it?
if you're concerned about ad cookies, why accept third party cookies at all? 
99% of those are advertiser cookies.  Also, try turning on cookie prompts for
half an hour, most of the advertisers update/replace the existing cookies on
return visits.  Those that don't (like atwola.com, one of the adservers for
cnn.com) set the expiry for the current session on their own, or for the next
few days.

Also, we never said it was unused.  People use it, but the question is how
useful is it?  Other than Neil's case, which is, in my own opinion, an edge case
in terms of the typical user (keeping in mind the "end user" focus of mozilla.org).
You can't have it both ways.  Either the 300 cookie limit is too low for you,
meaning we should be keeping the oldest cookies for longer, or you need this
pref so you can remove cookies even sooner, in which case the 300 cookie limit
is fine.
> The one issue remaining is whether we should have something to migrate the old
> prefs.

limit to 10 days -> session
This is unacceptable. We already have "limit to xxx days" and "limit to session"
prefs, there has to be a reason that the user chooses the former

limit to 10 days -> persistant
This would be acceptable

I am against this bug. There is already at least 1 reason for keeping the pref.
Another reason would be that people want to keep cookies from sites they visit
often. By limiting cookie lifetime to xxx days, you can have enough confidence
that cookies from sites you only visit once will be removed from your computer.

There are problems with the reason given for this bug. The argument assumes that
there is one way of streamlining the interface, and this is false. Secondly,
whitelist may be unacceptable. A common way to add sites to whitelist is through
confirm dialog which may annoy people. Or you can do this through the cookie
manager, but you must already have a list of cookie sites, and session-only pref
would remove that. Or you can use the Tools | Cookie Manager menu, meaning the
users have to go to a bunch of sites just to do that.
more streamlined, but may be more complicate to users. After some tweaking, I
find that doing the exact opposite of the original request will produce a
smaller UI.
That isn't more streamlined, that's more complicated.  No end user would
understand that.  It also depends on p3p which may or may not get built.

As for migrating the prefs, I would only migrate the current session-only
setting to the new session pref.  Limit to X days would be ignored (and thus
become persistent).

The question is one of tangible vs. perceived benefit.  Does deleting cookies
after 10 days really make a difference in the privacy realm?  If the cookies
aren't used, other than local access to the cookies.txt file possibly showing
some browsing info, there isn't much in the way of privacy intrusion.  This pref
doesn't stop tracking cookies that get updated (a la Doubleclick), which will
stay and stay as long as you keep going to sites they track.

If you don't want ad cookies, use the option for the originating site only (or
use p3p to achieve the same thing).  If you don't want tracking cookies to
persist, blacklist/session whitelist or limit all to session and just whitelist
the sites you want to persist (from Tools->Cookie Manager you can do this quite
easily whether a cookie has been set or not).  Other than a perception of
keeping a "clean" cookies.txt, what TANGIBLE benefit is achieved by this pref
that can't be achieved in another way?
Attached patch a patch that actually builds ;) (obsolete) — — Splinter Review 
so I didn't build before I attached the patch... :)
Attachment #140324 - Attachment is obsolete: true
Attached patch final patch (obsolete) — — Splinter Review 
forgot to update the comment in the header file for
mCookiesLifetimeCurrentSession
Attachment #140496 - Attachment is obsolete: true
Comment on attachment 140496 [details] [diff] [review]
with review nits from 64336, and a couple other tweaks

r=me, with the caveat that we might want to do something to migrate the user's
lifetime pref - something similar to what we did for firebird, perhaps (in the
prefpanel js code).

of course, the user would have to open the cookie prefpanel for it to execute,
so it's of dubious value. ;)

anyway, this backend work looks great!
Attachment #140496 - Attachment is obsolete: false
Attachment #140496 - Flags: review+
Attachment #140497 - Flags: superreview?(darin)
Attachment #140497 - Flags: review?(dwitte)
Attachment #140497 - Flags: review?(dwitte) → review+
Did I say I have over 10.000 co-workers world wide? I'm not alone you know. We
decided to use the mozilla suite, after HJ joined the agency in 2000. We are
forced to use prior mozilla versions after this update... Oh, and there is NO
privacy, at least not for US agency workers :-)
Neil, if you're constantly going over the 300 cookie limit, when do cookies ever
get old enough to hit this pref?  And if its not about privacy, does it make a
difference if the oldest cookies are there and get overwritten vs. getting
removed automatically?  Logically, one would assume that if 300 cookies isn't
enough, removing some proactively would make the situation worse.  Maybe I'm
wrong on that, but if I am I'd like an explanation of what seems to be a
complete contradiction on your part.
"Neil, if you're constantly going over the 300 cookie limit, when do cookies
ever get old enough to hit this pref?"

That's why we use several profiles, up to 25 a day. All because of this stupid
limitation. So no, cookies are not overwritten, well some are, but that's a
totally unrelated issue.

Your other questions are all related to the wrong assumption that we're
overwriting cookies, but we're not. We keep the cookies alive, as long as we
need them. I hope this clears the sky.

 
What I still do not understand: why do you want to delete old cookies?
Almost all cookies are set again on visiting, like ad cookies. So they will
never expire even when you limit the lifetime of it, because you will get a new
cookie before the time is out.
with the unresolved disputes in this bug, i think it would be wrong of me to SR
this patch at the moment.  is there a seamonkey "owner" that can weigh in on
this issue?

frankly, it sounds to me as if we are proposing to remove a feature that some
people use and for which no real substitute exists.  so, i think this needs more
consensus before we go one way or the other.

one of the goals for seamonkey -- as i understand it -- is to maintain UI and
feature compatibility with previous versions of seamonkey.  though seamonkey may
be bloated and may contain features of questionable value, the mozilla roadmap
does describe maintaining seamonkey for customers that depend on its feature set.
The question is what does the pref really do, and not whether people really use 
it.

- Cookies that are updated/replaced by return visits are not expired by this 
pref.  Only unused cookies are expired by this pref.  The tangible benefit is 
only on a local basis, as sites cannot access cookies from other sites, 
therefore the only privacy impact is local.  Any user concerned with privacy 
has local security in place, so this is at best a minor concern.

- Aside from privacy concerns, the other concern is usability.  If the point is 
not one of privacy, the only people who really would be removing cookies are 
developers testing site cookies, in which case a timed expiry really doesn't 
help.  I don't think anyone would advocate clearing Bugzilla cookies as an 
improvement to usability, the concern would be privacy.

Other than privacy concerns, or development (and there's better RFEs for that, 
like Remove All Cookies from Current Site), what other rationale requires that 
we have an option to expire cookies after X days?

The reason I'd like to see this in for alpha is to get some larger-scale 
feedback besides the arguments raised in this bug.  With the addition of 
whitelisting, we've already substantially altered the way cookie preferences 
work, so I don't view removing this preference as making a major change.  If we 
end up backing away from it before the beta, based on feedback, then it was 
worth the effort, at least in my perception.
(In reply to comment #33)
> What I still do not understand: why do you want to delete old cookies?

Because we have to? 

We're not playing but doing real work here. I have a schedule set to monitor 
1811 sites this month, so please keep in mind what a pain it will be to remove
all cookies by hand. Your not supposed to remove a prefectly working feature.

Oh, and I will file a new RFE to reinstate this pref UI for mozilla firebird, or
we will be in big trouble when the mozilla suite will no longer be maintained.
Neil, perhaps by explaining why deleting the cookies is required we might be 
able to better understand why you need this pref.  As it stands, you're giving 
us absolutely zero context as to why the cookies need to be removed 
periodically.  If you could provide a specific scenario in which removing the 
cookies before the return visit makes a difference in your environment, it 
would go a long way towards clearing the air.  Comments like "we're doing real 
work here, not just playing" do absolutely nothing in showing a clear and 
tangible need to preserve this feature.

As for Firebird, the backend isn't there either, and this was removed by 
design.  I highly doubt this would ever be returned to the UI based on my 
working relationship with the project developers.
"perhaps by explaining why deleting the cookies is required we might be 
able to better understand why you need this pref."

Sorry, but I can't give any details about this other than we really really need
it. Please stop asking for an explaination, enough is enough. I'm done with it.
Private needs without public explanation and convincing arguments about why they
should be met in the public open source => private patch, private build.

Cc'ing neil@parkwaycc in case he has some insight.

/be
Ok, say site X stores cookies for a period of Y months/years and we need to
remove it after a given period of time, for whatever reason. How should that be
done after this patch goes in? By hand? For all 300 cookies, on a per profile
basis? That is our problem.
after this patch goes in, doing it by hand would indeed be the only solution if
you don't want to modify the source and maintain a private build.  Again, since
you won't tell us what you're doing, its very difficult to justify maintaining a
feature in the common source, especially if its obviously a specialized usage
scenario that isn't anywhere close to normal usage.

If this whole cookie handling issue is so critical to this project you're on, I
can't imagine that rolling your own build to boost productivity could be a bad
thing, especially since you could just change
http://lxr.mozilla.org/seamonkey/source/netwerk/cookie/src/nsCookieService.cpp#83
while you're at it and stop wasting time with a bunch of profiles.

I'd even write the patch to restore this for private builders (at least for the
backend prefs) if there's a need for it.
For what it is worth, it isn't too hard to write an extension that deletes old 
cookies. Just talk to nsICookieManager, use the enumerator to loop over all 
cookies, and delete the old ones. Or just per site.
This would also work for firebird.
Darin's right, though: the roadmap says SeaMonkey is being sustained, not
playing some hopeless game of catch-up with the new standalone apps.  Comment 0
makes it sound like UI changes that might break long-standing, yet unexpressed,
customer requirements, can be decided by looking at (a) ugly UI and blanching;
(b) Firebird and saying "why not, if Firebird can do it?".

(a) is understandable, but perhaps something can be done to ameliorate the ugly
UI without yanking the SeaMonkey feature.  (b) is not valid, given the roadmap
and the greater need for backward compatibility in SeaMonkey.

If it sounds like I'm talking out of the other side of my mouth now, I am. 
While a private need that can't be explained to the public is not sound reason
for a change, it may be the tip of an iceberg that SeaMonkey should not crash
into, if we can help it.  It's different from the case where someone is
demanding a change for secret reasons.  Here, the change is motivated by valid
concerns about ugly UI, and not-so-valid desire to play catch-up with Firebird
in a way that risks incompatibility.

All things considered, I would like to hear about alternatives to address (a). 
And I'd like a better way to discern the requirements behind the desire to keep
this feature.  It may be that Neil Pryde's use-case is more common for SeaMonkey
users than we think.  Monitoring thousands of sites a month by hand does sound
like a drag if you have to clear out cookies, but would a compromise be to make
this pref UI-less?

/be
When i said "And if firebird can do without it, why not seamonkey?" i meant to
say: "firebird hasn't got this pref, and according to mconner, there haven't
been requests to add it. So, it doesn't sound like it is a popular pref"
So, because i thought this pref was not much used, made an ugly ui, removing it
would clean up the ui and clean up code (less |#ifdef MOZ_PHOENIX| stuff)
grr, i forgot to mention that i didn't say it because i want seamonkey to play
catch up with firebird.
New UI suggestion:
<blurb?>
( ) Accept persistent cookies
( ) Limit cookies to [ ] days
( ) Limit cookies to the current session
( ) Ask me whether to accept a cookie
    [ ] Also ask me for session cookies
Comment on attachment 140497 [details] [diff] [review]
final patch

removing the SR request and  obsoleting, I still want to look at this pref
going forward, but the rewrite in 233339 should take precedence over this
patch.
Attachment #140497 - Attachment is obsolete: true
Attachment #140497 - Flags: superreview?(darin)
Ok, I have another possibly controversial idea:
Instead of removing the limit to n days pref, we could remove make limit to
session only mean limit to 6 hours. The 6 hours would be settable as a hidden
pref. (so you can make it 30 days if you want)
the idea is that a session isn't something a user knows about, especially in
combination with quicklaunch and/or mailnews still runnins. By making it a
couple of hours, cookies can survive installations of extensions or crashes, but
will die the next days. The term session can be replaced by temporary.
The UI gets simplified to, because we remove the input box.
For the users that want to close all the windows to get rid of all the cookies,
there is still the cookie manager with 'remove all'. No need to close mailnews
for them anymore.
Priority: -- → P4
re: what should we do for 1.7a

I'm on the fence about the utility of this feature (partly because I am still
digesting the implications of whitelisting), but a pref UI change that removes
the feature would not cripple users, they could still use about:config.

We probably would want to checkin w/o the changes to the prefs files, just the UI.

Taking out the backend is a more difficult question.



as an elaboration of what mvl is talking about, it would be a hidden pref, i.e. 
network.cookie.sessionLength.  How this would work would be as follows (this 
would only apply to cookies being downgraded to session cookies, either by the 
dialog or by site permissions):

A default value of 0 would result in using the normal definition of a session, 
which is until the program is closed.  However, we would take integer values in 
hours, allowing users to define a session as six hours, or in the case of 
something like "remove after 5 days" 120 hours.  The conversion still goes to 
seconds either way, but this is a little more finely tuned.

This would allow for a longer lifetime for those users who still want this 
functionality, as well as allowing users to use cookie permissions in 
conjunction with limiting lifetime.  Think of it as a backwards compatibility 
option, since this is the only means by which users could replicate the 
behaviour of 1.4 (where lifetime prefs would be honoured by the permissions), 
without upsetting the userbase that is enjoying the benefits of true 
whitelisting in conjunction with limiting other sites to session only.
No longer blocks: 222561
Target Milestone: --- → Future
Not going to be working on any Seamonkey UI bugs for the foreseeable future. 
You can filter on "danlikesgoats" to delete this spam.
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
Priority: P4 → --
Target Milestone: Future → ---
this is now implemented happily in nsCookiePermission.cpp, which embeddors can happily override to do whatever they want, and it's really not having any detrimental impact or bloat. might as well leave it the way it is; future ideas for ui improvement can be filed with the respective client app as new bugs.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
See Also: → 1457170
You need to log in before you can comment on or make changes to this bug.