Closed Bug 149544 Opened 23 years ago Closed 5 years ago

Protect/lock cookies from USER/PROGRAM deletion (i.e. "Remove all cookies")

Categories

(Firefox :: Security, enhancement)

Product:
Firefox
Component:
Security
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: inca0, Unassigned)

References

Details

(Whiteboard: Bug IS NOT about protecting them from expiring or from server deletion)

I'd like to request a feature to lock certain cookies (as opposed to blocking them). This way you can keep useful cookies (with login-information for example). They should be maintained when you select 'remove all cookies'. Also you should be able to prevent certain cookies from being changed this way.
Target Milestone: --- → Future
would imaging keeping cookies beyond when the site sets them to expire breaks standards and would break some sites, however, exempting certain cookies from being expired by policies set by the user could be handy. confirming as an RFE.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Hardware: PC → All
Summary: [RFE] way to lock / secure cookies (prevent cookies from expiring or deleting) → way to lock / secure cookies (prevent cookies from expiring or deleting)
Removing the word "secure" from the summary line because a "secure cookie" is something entirely different -- it's a cookie that get sent back only to an https site.
Summary: way to lock / secure cookies (prevent cookies from expiring or deleting) → way to lock cookies (prevent cookies from expiring or deleting)
*** Bug 165439 has been marked as a duplicate of this bug. ***
Bug 75915 (whitelist for permanent cookies) would accomplish pretty much the same thing as this bug ("locking" cookies against being deleted when you click "Clear Cookies"). I think this should be marked as a dup of bug 75915 or wontfixed in favor of bug 75915.
the whitelisting bug is fixed, but it doesn't prevent clear all from deleting the cookie in question.
If you use a whitelist of sites allowed to store permanent cookies, you rarely have to delete cookies.
*** Bug 232746 has been marked as a duplicate of this bug. ***
dwitte, mvl, any opinion either way? I don't like the idea of not expiring these cookies, this could have bad effects. As for the deletion part, I could see value in not deleting cookies from whilelisted sites, if it was in conjunction with a filter in Cookie Manager to not show these cookies.
QA Contact: tever → cookieqa
IF whitelist a site measn that the cookie will not be deleted when using delete all cookies, it will certainly surprise many users. So don't do that.
mvl, I'm thinking this would be in the same context as a checkbox like "do not show cookies from allowed sites" or whatnot, and just delete the visible cookies. Other than that, which is something I'm toying with, I consider the other alternatives rather iffy (i.e. if the cookie is "locked" do we allow overwriting it and adding the locked attribute?) and probably something that isn't worth trying to fix.
i'd worry about the possibility of breaking sites who expect a certain cookie behavior (think RFC2109 here), and get something entirely different. i don't think we want to go here. (or at least, if we do, we'd want to hide the feature to discourage use by the common user).
The discussions in this bugs an dupes are actually not exactly identical. 1- allow checkbox selection of cookies - sort of already doable w/ control-clicking a selection and then clicking "remove cookie". 2- allow locking of cookies. this prevents the server from changing the cookie, and possibly from not expiring it either.
*** Bug 277025 has been marked as a duplicate of this bug. ***
*** Bug 279305 has been marked as a duplicate of this bug. ***
I was going to file an enhancement request, but found this bug. I just want to make sure this bug is talking about the same thing: What I'd like is the ability to protect cookies I use to login to certain internal sites that wouldn't be cleared when I clear all my cookies, or better yet to set protected paths that all cookies under that domain/path would be protected. I'm NOT talking about protecting cookies from the sites themselves. I got 3rd party extensions for this capability, but they didn't work :-( Reassigning this bug back to default.
Assignee: morse → darin
As Ben mentioned, some bugs that are marked as duplicates of this bug are not dupes depending on what we interpret this bug to be about, and the discussion in this bug has been all over the place because this bug is so general. There are actually 3 seperate enhancement requests: 1) Preventing deletion of cookies when users chooses to clear all cookies. 2) Preventing cookies from being modified by server. 3) Preventing cookies from expiring. One issue per bug. Experience has shown that a bug this general has a discussion that's very hard to follow. Since all the dupes are discussing #1, please move server-side discussions to a seperate issue. Protecting from expiration and server deletion is a heck of a lot more complicated. Bug 165439, bug 277025 and bug 232746 appear to specifically discussing protection from user/program deletion. Bug 165439: It's specifically mentioned that it should be done through the cookie manager, and implicitly a way to come up with a list of some cookies to protect. This is more a front-end bug. Bug 232746: Explicitly mentions an exception list for clearing cookies when you use "Remove All cookies" Bug 277025: Protect some cookies from being deleted when closing Firefox, if you have the option set to clear cookies on program exit. Bug 279305: Discusses protecting certain cookies from being affect when someone chooses to "Remove All cookies" As I see it, there are two criteria to protect cookies: 1) on a domain/ip/path basis (Bug 327487) 2) On a cookie-by-cookie basis in "View Cookie" window or 3rd party Cookie Editor. Option 2 seems a lot less powerful, but when protecting an individual cookie, the user had an option to automatically protect it's associated domain/ip/path, that would become a lot more powerful, and would merge 1 & 2. Filed dependant bug 327487 - "Protect cookies from USER deletion by domain/path" since this bug is not specific on what locking does. No other bugs I found explicitly and clearly mention domain/path as a method for setting up the list.
Blocks: 327487
Summary: way to lock cookies (prevent cookies from expiring or deleting) → Protect/lock cookies when USER/PROGRAM deletes them (i.e. "Remove all cookies")
Whiteboard: Bug IS NOT about protecting them from expiring or from server deletion
Summary: Protect/lock cookies when USER/PROGRAM deletes them (i.e. "Remove all cookies") → Protect/lock cookies from USER/PROGRAM deletion (i.e. "Remove all cookies")
Another thing is the P3P specification describes "Opt-out" cookies, which are a completely useless because they will get cleared with every other cookie. If opt-out cookies could be created by a site, then protected by the user, then they'd become a lot more useful.
Assignee: darin → nobody
Target Milestone: Future → ---
@Brian netdragon Bober: Option 1 in Comment #16 seems to be what most of the dupes are asking for, and what I'm asking for. As I visit 10 or so sites that I'd like to save cookies for (Gmail for instance) but I also must visit hundreds of other sites that I don't want to save cookies for. As it is now I must manually go through the cookie list and delete one by one. This is a ten minute job, and I must do it daily!
Yes this seems like such a simple thing to be added and yes you can find extensions to do it so (which I use) however I recently got an email closing my dupe (above) so I checked andI must say I AM AMAZED TO SEE THIS FEATURE HAS NOT BEEN ADDED IN GOING ON SIX YEARS!!! So many dupes means it is obviously a very desired feature, is there no one here monitoring this, is it just a waste of time to post here? I am asking this question honestly this is a very simple feature that many are asking for that has not been added in six years it seems strange to me. This feature should be a priority just for cutting down on checking the dupes alone, that has to be time consuming. As many times above all most people want is when they go into "Managed Stored Cookies" and click "Remove All Cookies" there is some way to keep a few cookies that have log on or preference information, NO overriding expiration dates, NO preventing cookies from expiring, NO blocking from servers, JUST a way to not remove a few select cookies, very simple to be still bugged here after five years.
It seems multiple things are being discussed here. Since my bug was made a duplicate of this one, I just wish to point out that all I want is a method of not deleting certain cookies when clicking remove all cookies or, if remove all personal information is checked, on closing Firefox. I explicitly don't want cookies to exist beyond there expiration time or to locked from editing by the site it generated. These sort of features are best put in an extension for those who need it. However there are certain sites that use cookies for what they are meant to be used for. It is for these sites that I wish to be able to keep the cookie around. Like for sourceforge.net that allows storing your preferred mirror in a cookie. It would be nice that this specific cookie and not all cookies from that domain/path/ip would survive the remove all cookies process. I imagine that it would be possible in the cookie manager to select a cookie and click on a button named preserve or persist or whatever and then that cookie wouldn't get deleted when the remove all cookies process is invoked. The number of sites that actually use cookies this way are really not that many. But are the ones I use the most. Right now I have to choose between hand deleting all the cookies I don't want or re-enter the information on the site each time I'm there. Either is not desirable. Therefore I have resorted to not removing any of the cookies which off course is helping all those sites that abuse cookies. Please consider this feature.
For what it's worth, I work around this feature pretty simply: I set my browser to accept cookies from sites until I close Firefox. I change this setting to "until they expire" or "ask me" whenever I expect a site to set a cookie I want to keep, and then I set it back. When I close my browser all cookies are automatically deleted - except the ones I want to persist. I can also use the cookie manager to manually delete any cookie that has been persisted, which I do not want persisted. The downside is that some cookies actually last longer (if I keep my browser open for days) than they were intended to, but that's a totally separate bug. Yes, this is a legitimate feature request and not a bad one (although I think its implementation would ideally differ from described for my grandma to understand it best.) But with an easy workaround present, the fact that cookies really aren't the spawn of evil after all, and the relative recentness of "clear private data", it's not surprising this bug hasn't yet been fixed. Hope that helps. Just my opinion. -[Unknown]
Ah yes, the grandma, that's why we have UI guys don't we :). Off course it doesn't have to be implemented as described. It is just to make clear what my feature request is about. Btw, I will try your workaround as this will properly not be in the next release. I just hope I understand it.
Comment #22. I had requested this many years ago too. It IS annoying and time consuming to have to manually go through and delete all of the cookies just to keep a few that I don't want deleted. There's been so many updates to Firefox. We're now up to 2.0.0.11. Like you said, there's been so many dups, that it proves how wildly popular this feature request is. Year after year, it keeps getting requested.
(In reply to comment #26) > There's been so many updates to Firefox. We're now up to 2.0.0.11. Do remember that 2.0.x will always only be security/priority fixes (meaning, e.g. Vista compat.) that literally cannot be done without. We could make it to 2.0.0.111 and it would only mean there have sure been a lot of security fixes. Have you tried my suggestion as a solution? It's really a lot more productive to manually keep the cookies you want than to delete the ones you don't want. You'd be surprised how well it works. -[Unknown]
@ddemon01: Take a look at the CookieCuller extension. It does exactly what you are asking for. Now that I've found this extension I can unsubscribe from this bug. That said, I still believe that this should be in the core of the browser and not in an extension.
(In reply to comment #28) > @ddemon01: > Take a look at the CookieCuller extension. It does exactly what you are asking > for. Now that I've found this extension I can unsubscribe from this bug. > > That said, I still believe that this should be in the core of the browser and > not in an extension. > Yes as in my post above, extension do it and yes I have been using CookieCuller for quite some time now but as you stated making it core functionality would be best, I have used more than enough good extensions that become outdated and unusable simply because core coding has changed. At any rate I know this not a top priority, which I guess is fine, just found it strange to have been around since 2002 with no progress, if an extension can do exactly what is being asked seem as if it would have be simple enough to have made core by now.
The ability to protect certain cookies needs to be incorporated into the browser itself rather than using an extension to try to accomplish the protect feature. I've previously developed two extensions (View Cookies CS and CookieSafe v2.0.7) to try to provide this behavior but there really isn't an efficient way of implementing the protect feature. I've ended up removing the protect feature from the latest version of CookieSafe due to this problem. At the moment the only way to ensure that the cookies are protected regardless of the UI you use to remove them is to monitor cookie deleted notifications with a 'cookie-changed' observer. When a user protects a cookie from within the extension's cookie manager the name and host of the cookie are added to a string preference using delimiters. Anytime the observer detects a deleted cookie it compares the name/host to the protected cookies stored in the string preference. If it's determined to be a protected cookie you would then add it back to the browser. The problem with this tactic is that you are actually allowing the cookie to be removed first and then re-creating it. There are other extensions available that allow you to protect cookies but they only work if you remove cookies from within that extension's UI. For example, if you were to protect a cookie using the extension's cookie manager and then open your browser's cookie manager to try and remove that cookie it would be successfully removed in most cases. My suggestion would be to add a new boolean column named 'protected' to the 'moz_cookies' table in the cookies.sqlite database. You could then add a new method to the nsICookieManager interface named 'protect'. That method should accept 2 arguments. The first being a nsICookie object representing the cookie you want to protect (or unprotect) while the second argument would be a boolean value which will either protect or unprotect that cookie. void protect ( nsICookie cookie, PRBool isProtected ) Before any cookie is allowed to be removed from the browser the corresponding 'protected' property should be queried in the moz_cookies table. If the protected property is false then the cookie is removed, otherwise the attempt to remove the cookie is canceled. This would provide a convenient way for extension developers to add support for protecting/unprotecting cookies in a custom cookie manager UI. And it would also ensure that the cookie is protected regardless of the UI that is used to try and remove it. This method could also be applied to the other feature requests in this thread. For example, you could add another boolean column to the moz_cookies table named 'readOnly'. You could then use that property to control whether the cookie values could be modified. I think the biggest issue facing the implementation of this feature would be to avoid breaking any script that tries to remove a protected cookie. If a cookie was found to be protected or readOnly then you would have to make it appear to the program sending the remove command that it was successfully completed even if the cookie wasn't removed. If an error was thrown during an attempt to remove a protected cookie then it would prevent certain methods like the nsICookieManager.removeAll method from completing successfully. So rather than throw an error I would suggest simply logging a message to the error console stating 'Cookie protected - will not remove' or something to that effect. That way every script would continue to run even after encountering a protected cookie.
That sounds like a concrete implementation. Can we have this implemented now? We love to see this become a real feature.
Since the discussion here has evolved to address only the issue of deleting cookies, I have submitted RFE bug #692315 to address the issue of protecting existing persistent cookies from being altered by servers during subsequent browser sessions.
this might be an addon thing.. but asking front end
Component: Networking: Cookies → Security
Product: Core → Firefox
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.