Closed Bug 232744 Opened 21 years ago Closed 18 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
Attached patch a patch (includes changes for bug 64336) (obsolete) — — Splinter Review
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.
Attached file more streamlined interface —
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: 18 years ago
Resolution: --- → WONTFIX
See Also: → 1457170
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: