Open Bug 691973 Opened 10 years ago Updated 2 days ago
Expired Cookies Not Removed by Cookie Manager
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110923 SeaMonkey/2.4 I visited several wiki.mozilla.org pages. Later, I noticed that a cookie from that domain was still present although it had expired about 50 minutes earlier. I terminated SeaMonkey and then relaunched it. The cookie was still present. Expired cookies should be deleted or at least marked so as (1) not be displayed by the Cookie Manager and (2) -- much more important -- not sent to the indicated server if the page is again requested. The attachment shows the current date and time (4 Oct 2011 4:18:52 PM) in the Date and Time Properties window over the Cookie Manager display from the Data Manager window. At the bottom of the Data Manager window, the cookie expiration is given (same date, 3:29:04 PM).
The bug shows platform as x86 Windows XP, but it exists on my x86 Fedora system as well.
I just now reviewed the cookies in one of my profiles. There were several still present with expiration dates and times a few hours earlier, a few days earlier, and several months earlier. Lacking any workaround (other than reviewing each cookie and manually deleting the expired cookies), I have changed the priority to Major. In light of comment #1, I have changed the OS to All.
Severity: normal → major
OS: Windows XP → All
Bug 576347 proposes to delete expired cookies once a day when Firefox is idle.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 576347
Windows 7 (x64) Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 SeaMonkey/2.22 Bug #576347 is marked "Mac OS X", appears to be an RFE (despite being marked "Normal"), is not assigned, and appears not to have any action for implementation. This bug, however, has been seen with Windows XP and Windows 7 and is a true discrepancy. One of my profiles currently has 76 persistent cookies with 10 of them expired. At least one of the expired 3 months ago. The most recent expiration was about a week ago. With all the effort being put into adding security features to Mozilla-based applications, I would think this bug would have significant priority for a correction.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
just discovered this issue in my ff box. i consider #576347 a supplementary solutions for performance and/or profile maintenance. here are my ideas. baseline (site-based check): whenever a site is visited, ALL cookies under the site should be checked for expiry. expired cookies may have impact (passing wrong security or session or other info) to the application. at start or end of session (session-based check): clean up expired cookies as if they are (expired) session cookies implement #576347 (periodic check): periodic clean up for use case in which ff is rarely restart (mainly laptop users that only hibernate) frequency should be configurable via about:config
Re comment #5: Yes, this would be an acceptable solution.
The reasons for re-opening this bug no longer apply. The duplicate is marked for all platforms although it still doesn't look like getting fixed or even worked on any time soon. Comment 5 is not a likely solution. Cookies are already identified as expired when a site is visited so that they are not passed to the web server, but in most cases they are already in the database. In the middle of loading a web page is not the best time to be deleting entries from the database, which is presumably why we have this bug. Similarly, startup and shutdown are time-critical and we can't be adding IO at those times. Session cookies are slightly different because they aren't in the database. The only action needed to purge them is to not ever write them into the database. Bug 576347 suggests periodic cleanup of the database during idle. My addon currently does this and it is a very quick process with no impact that I can see. My addon doesn't do database vacuuming, I thought that was a concept that was dropped in favour of pre-allocation?
Re last paragraph of comment #7: What add-on?
(In reply to Ian Nartowicz from comment #7) > Comment 5 is not a likely solution. Cookies are already identified as > expired when a site is visited so that they are not passed to the web > server, but in most cases they are already in the database. In the middle > of loading a web page is not the best time to be deleting entries from the > database, which is presumably why we have this bug. > > Similarly, startup and shutdown are time-critical and we can't be adding IO > at those times. Session cookies are slightly different because they aren't > in the database. The only action needed to purge them is to not ever write > them into the database. > So what you mean is there is never a good time (except the idle timeout) to clean the ever growing cookie database unless we only allow session cookies. Even if these cookies are never sent, there is still risk to privacy / information leaks via cookie history which cannot be ignored. I'm a bit confused here. On one hand the clean up can be done very quick (with an addon), but on the other hand it will have significant impact to page load/startup/shutdown. It seems to me the primary concern lies with the database operations. I am naive enough to think this bug means something like "delete * from cookie where expiry_time <= now". Other database maintenance tasks (allocation, vacuumuing, defrag, etc) are not point of interest as far as I'm concerned. The proposal on site-based check is intended to limit the extend of individual clean-up (and off-load the clean-up at shutdown). I agree that it may not be a good idea if it is not time-effective. But at the minimum, I think shutdown clean up is important, esp for this privacy related container. Good applications perform clean up at exit and performance may not be a good reason for the trade off. I think there are much more concern on the cookie privacy compared to process shutdown time. See also cookie tagging. One of the goal is to faciliate logout clean-up. <https://wiki.mozilla.org/Privacy/Features/Cookie_tagging> Perhaps we can have the shutdown cleanup in place first, and ride on this feature for performance improvement in longer run. PS: currently, I'm performing some manual clean-up with Cookie Time <https://addons.mozilla.org/en-US/firefox/addon/cookie-time/>
Half a second (usually less, but occasionally more) once a day when someone is not using their computer is fast and negligible. The same amount of work during startup or shutdown is not acceptable.
I have three browser profiles. One of them is needed for banking and investment transactions because the Web sites involved require preferences to be set differently from how I normally browse. Among the different settings is to allow ALL cookies. Earlier today, I examined the cookies in that profile and found several that were not relevant to the purpose of the profile and should be deleted. To do that, I had to wade through several expired cookies that also had to be deleted. The time I spent at this task was significantly greater than any performance hit that might occur if expired cookies were purged at startup or shutdown. When I spent several minutes manually removing expired cookies, quibbling about a few seconds of delay in a startup or shutdown is no justification for not fixing this bug.
Get a grip.
Firefox 30 stable. Expired cookies are present in the list, while the "remove after expiration" option is activated. It's a serious problem and should be fixed ASAP.
Well it's certainly *a* problem. The only real question is when and how those cookies should be purged from the database. Input would be more useful than just re-stating the bug. Perhaps a patch is what is really need to focus minds.
I suggest at least to mark it as a security hole and as a regression. Then provide a workaroud for end users (some SQLite tool or something). Bug 576347 is not a dupe, it suggests one way to resolve this bug. So it should be added to Dependency list.
It seems to me that any performance hit caused by purging expired cookies and vacuuming the database on start-up -- with a database that is NOT pre-allocated to a fixed (and sometimes excessively large) size -- would be mitigated by the reduced database when querying for required cookies and when inserting new cookies. I have already observed delays in completing the launch of SeaMonkey for two of my profiles that have many bookmarks in places.sqlite and almost immediate completion for a profile that has very few bookmarks. Thus, the size of a database does create a performance hit. Where that size involves obsolete entries, reducing the size by eliminating those entries surely must improve performance.
Duplicate of this bug: 1340793
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.