Closed Bug 75915 Opened 24 years ago Closed 21 years ago

whitelist for sites allowed to store (permanent) cookies

Categories

(Core :: Networking: Cookies, enhancement, P3)

Product:
Core
Component:
Networking: Cookies
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: alchemist, Assigned: morse)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(3 files)

IE6 dialogs
55.94 KB, image/png
Details
cookie manager menu option
61.01 KB, image/png
Details
cookie manager white/blacklisting
14.63 KB, image/png
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010413 BuildID: 2001041304 The ability to block all cookies except for a selected few (specified by inputting a site such as msn.com) is a very simple cookie management feature that needs to be implemented into Mozilla ASAP. Using MS Internet Explorer, one can configure his/her Internet zone to block cookies, and then placing sites they would like to be able to set cookies on their machine in the Trusted zone. Zones are not needed, but the same logic stilll applies. Also note CookiePal (in the 2nd screenshot on the URL listed above); there is a field to add sites to accept cookies from, and then for unknown servers, all cookies can be rejected. Reproducible: Always Steps to Reproduce: 1. Edit 2. Perferences 3. Advanced -> Cookies Actual Results: The cookie manager only allows you to reject cookies from specific sites, and only after you have received the cookies. Expected Results: The ability to block all cookies except for a selected few (specified by inputting a site such as msn.com) is a very simple cookie management feature that needs to be implemented into Mozilla ASAP.
*** Bug 75916 has been marked as a duplicate of this bug. ***
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
This may be a duplicate of bug 74257.
Instead of manually entering the sites, the "Unblock Cookies from this Site" could add the sites if there was a method for blocking by default.
*** Bug 89753 has been marked as a duplicate of this bug. ***
*** Bug 91784 has been marked as a duplicate of this bug. ***
This could be implemented pre-1.0 by simply allowing sites with explicit permission to set cookies to get/set cookies when "Disable Cookies" is selected. Or add one more selection, "Disable cookies except explicitly allowed ones." Shouldn't be much work. It's the same as Enable with the warning, except don't show the warning, as if the user pressed no, don't accept. No infrastucture changes. Any takers to un-Future? ;)
Blocks: 91783
URL: http://http://www.kburra.com/cpscreen... → http://www.kburra.com/images/cpfilt.gif
OS: Windows NT → All
Hardware: PC → All
Target Milestone: Future → mozilla1.0
Re-targeting... little work for big reward, this is key for 1.0 to make cookie manager useful to many users. Cc'ing mpt for help on the UI for this. Thoughts on switching our current "Cookie sites" dialog to something more along the lines of the UI in the picture (URL)? We have two "Status" that a given site can be, and I don't imagine a third will be added, so we seem to be waste a lot of room with the status column, not to mention it's fairly hard to pick out the "site can set cookies" from all of the "site cannot set cookies" (I have over 500 sites in there). Switching to the two columns, Accept cookies from/Reject cookies from, would seperate the two groups of domains much better, and allow us to show twice as many sites on screen at once. Come to think of it, though, this whole paragraph belongs in a seperate bug. The real issue at hand is the bottom part of the image, what to do for unknown servers. Currently, we have: ( ) Disable cookies ( ) Enable cookies for the originating web site only ( ) Enable all cookies [ ] Warn me before storing a cookie. This layout worked fine for NS4, where there wasn't per-site access control, but it falls short now. My situation: I need (and want) to let 3 sites store cookies on my machine. If not for those three sites, I would disable cookies outright. So as-is, I'm stuck on the middle option above, with the "Warn" box checked. As I mentioned before, I have over 500 sites in my cookperm.txt. This means I've clicked "No" over 500 times. There are a number of differant ways to add the UI for this (and I'm sure mpt can think of some more). We can leave the UI, and have the first option ("Disable cookies") still allow cookies with explicit access to be read and written. We should mention this prominently, though, so users aren't surprised they're still sending cookies to some sites. Or we can add two new options, a soft-disable (still allow accepted cookies to work) and a hand-enable (even blocked sites will be allowed... might be handy to turn on temporarily, to use a site you've blocked without having to unblock, then reblock them.) Wording's a bit rough, but it might go something like: ( ) Disable all cookies ( ) Disable cookies for all sites except those with explicit access ( ) Disable cross-site cookies, and cookies explicitly blocked (X) Enable cookies for all sites except those explicitly blocked ( ) Enable all cookies [ ] Warn me before accepting new cookies. Or, one last idea, something more radically differant: ( ) Disable cookies completly (X) Enable cookies +--------------------------(greyed out if cookies are disabled above)-----+ | | | ( ) Accept all cookies | | (X) Accept cookies except those that I've blocked | | ( ) Only accept cookies from the originating web site | | ( ) Only accept cookies I've explicitly allowed | | | | [ ] Warn me before accepting new cookies | | | +-------------------------------------------------------------------------+
Keywords: helpwanted
Target Milestone: mozilla1.0 → Future
milestone is for assignee. If you want this done sooner than the current assignee and you aren't willing to volunteer to do it yourself, please find someone to volunteer. ... But first we need a ui proposal which enough people like so the poor volunteer doesn't get lots of complaints after spending lots of time implementing something which would be unacceptable to whomever matters. Category | Accept | Prompt | Drop | Log -----------+--------+--------+------+----- Default | | o | | Cross site | | | o | x -----------+--------+--------+------+-----*The stuff below here is really Accept | o | | | only useful if you can have an Prompt | | o | | arbitrary number of categories Block | | | o | Clicking a category title could check all of the cells in the collumn. Accept/Prompt/Drop are mutually exclusive, Log is a bonus which should not appear in a distribution (and might not ever be implemented) but wouldn't it be cool if you could manage your lists by dragging sites from one to another: Accept | Prompt | Drop --------------------+--------------------+------------------------ >foo <| bar | baz py-ben | py-yeh | c-yeh eh-ya | glory | __________________ | __________________ | _______________________ (you could of course drop a bookmark, link, or url-proxy). if you allow for an arbitrary number of lists, the 2d view becomes unmanagable. If bookmarks ever supports aliases (4xp) we could simply make special folders and give them permisions. This would probably be the elegant solution, since you could have permissions for bookmarks or folders and an easy way to manage them.
There are a few workarounds: - You can open cookies.txt, delete unwanted cookies, save and then mark thr file read-only. Check, if the file is still read-only after you wuitted Mozilla the next time, I heard that Windows versions do odd things. However, this workaround worked fine for me with 4.x Linux. - You can clear the cookies with the Mozilla UI, then vistied the whitelist sites, then enable forced session cookies (bug 81226). This will not block normal cookies, but delete them at shutdown, making them harmless (unless I'm missing something).
In general: ( ) accept cookies ( ) decline cookies (*) ask me Then the list of cookies, and servers you have accepted/declined cookies from, can be shown in a single `Exceptions:' table. Path Name State ------------------------------------------------- ads.web.aol.com all cookies decline bugzilla.mozilla.org all cookies accept bugzilla.mozilla.org Bugzilla_login mpt@mozi... This would make our cookie UI considerably nicer, since you wouldn't have to constantly switch between the two tabs.
Re: timeless's UI, I think that's just too complicated. While 'log' is a feature the junkbuster proxy had, and I'm the one that opened the "add all useful features from JB to mozilla" tracking bug, that particular feature just isn't useful even to privacy freaks like me when it comes down to it. As far as arbitrary number of catagories...we only have three actions we can do, so I don't see what that buys us, other then making it overly complicated to develop for developers, and overly compliated to use for users. Re: mpt's UI, nice attempt, but the pref dialog just isn't big enough to do it that way =(. You still need to show all the cookie info somewhere... date, expires, etc... But merging the two tabs under "View Stored Cookies" would be a good idea, I think. Since I shot down both of yours, I'll take a stab at my own. Until then, I'm going to attach a screenshot of the IE6 cookie dialogs, which have some nice features (and some dumb ones). Things to note: I don't see much point in being able to block first party cookies, and accept third party ones. Always allow session cookies check box. I think there's a bug on adding this. The privacy slide is kind of stupid and the text is confusing to most users, but it makes use of P3P in an attempt to give more flexibility. (Though I don't support the implementation of P3P in Mozilla). The Edit under Web Sites lets you manually add sites that you allow/block from. There's a bug on this for us, too.
Attached image IE6 dialogs —
we'll definitely do manual adding, and i could imagine the right dialog from your picture as a tab in a cookie dialog, but otherwise i don't like the ie interface, it's scattered, messy and has that whacky security slider.
Another thing that would be VERY useful in this context: In the Cookie or Image dialog that appears when you have 'warn me' selected should also allow for a 'domain' option. A perfect example: I go to slashdot.org with 'warn' set, and either 'all' or 'all from host' selected. I immediately get a question from images.slashdot.org, images2.slashdot.org etc. asking if they're OK too. I'd like to see this in the cookie/image dialog: [ ] Accept/Reject from Domain [...textfield.with.hostname...] This should be a check button, and the textfield should be greyed out until the check button is checked, and then people can have 'slashdot.org' there and all the servers in that domain will be OK (or rejected) depending on the Yes/No answer you give in the dialog. This is short, simple, evident, and quite effective.
Hi, If an UI can't be worked out, as an interim measure how about allowing the ACL to be checked even if "never accept cookies" is selected, so that it just becomes the last-resort action in the ACL. My idea of a swanky UI: Default cookie action is to: ( ) Accept ( ) Block [ ] Use per-site cookie management [ ] Prompt before accepting cookie (where ( ) == radio, [ ] == checkbox) I think that's clear enough, and the details can be explained in context-sensitive help :-) Of lesser concern is that cookies don't always comes from exactly the same hostname as the webpage, so "Allow cookies from this site" isn't a complete solution for people defaulting to blocked cookies.
I don't think the cookie data should appear in the same table as the list of sites which depart from the default behavior. Presenting two different sets of information in the same table is confusing. Bug 53354 needs to be considered here too. I would suggest there should be one place set the default cookie setting, and a table to set departures from the default setting. default choices: () accept () accept from originating server () reject [] warn me [] limit cookie lifetime to ()session ()__ days Clicking on a site in the table of exceptions would bring up the "exceptions" dialog: from domain mozilla.org: () accept () reject [] warn me [] limit cookie lifetime to ()session ()__ days All the choices should be available, including whatever the current default choice is. If the user changes the default choice, the selections the user has made in the "exceptions" table should remain. I remember that OmniWeb (a Mac OS X browser) had a pretty flexible and easy-to-use cookie UI, but I don't have it installed and don't remember exactly what it was like.
Bug 67580 and to some extent bug 53354 contain discussion about how to make the cookie UI management less modal. The way I would like to see this is to select your default policy (accept or deny cookies), and then override this when you enter a page you don't want to apply your default. The UI for this is already there (although it could be improved): Tasks|Privacy & Security|Cookie Manager|Unblock/Block Cookies from this Site. The only problem is that blocking/unblocking currently doesn't override your _default_ setting. Changing the order of the tests would be easy, but that would change the meaning of currently stored cookies... Having a four-way selection (with "soft/hard-disable/enable") sounds a good solution. Anyway, I think this (possibility to record per-site accept/deny overrides to your default) is all that is needed from the backend and it should be implemented now. How to present this and the other UI improvement details should be pushed off to another bug to not prevent this new feature from being implemented.
bug 82734 and bug 74257 are also related.
Blocks: 100573
*** Bug 107125 has been marked as a duplicate of this bug. ***
Target Milestone: Future → mozilla1.1
*** Bug 118423 has been marked as a duplicate of this bug. ***
*** Bug 124808 has been marked as a duplicate of this bug. ***
*** Bug 129318 has been marked as a duplicate of this bug. ***
#9 - I don't find a cookies.txt in Mozilla's directories (v0.9.8+) It looks like it stores cookies in some kind of binary format. I don't care how this function looks in the UI but I would very much like the ability to whitelist cookies AND (the option to?) make all the non-whitelisted sites "think" they are setting cookies normally when their cookies are actually never even getting written to disk but to memory where they are erased when the browser is closed. This is what happens when you write-protect cookies.txt in Netscape and I like it very much. Ideally this function would go one-better than Netscape and redirect ALL cookie-related requests (from non-whitelisted sites of course) seamlessly to the "imaginary" cookie file in memory. I know in some cases (for reasons I never was able to discern but that I suspect were Java/JavaScript related) certain sites weren't able to create these "RAM cookies".
Re: comment 23: except for "whitelisting" certain sites, you can already do what you are describing using the "Limit maximum lifetime of cookies to: current session" preference setting.
No, you can't. The best you can do is limit ALL cookies to the current session except for some few that end up with permanent cookies (accept cookies, let the site set them, then change back to current session only). However, this doesn't account for letting certain white listed sites change or update cookies whenever they want. What we want is to deny any site from setting a cookie (or even only letting them be set for the current session) EXCEPT for some whitelisted sites that can have changing cookies from session to session.
*** Bug 138947 has been marked as a duplicate of this bug. ***
*** Bug 141435 has been marked as a duplicate of this bug. ***
*** Bug 143880 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: mozilla1.1alpha → mozilla1.2alpha
*** Bug 156858 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.2alpha → mozilla1.3alpha
Frankly, this is pathetic. The original filing of this bug/feature was 2001-04-13. It is now more than a year later. This feature has been requested by dozens of independent people. To any one half familiar with the mozilla source code, this is surely a trivial feature to add: A simple if statement coupled to a one page form will suffice. If I had any familiarity with the Mozilla tree I would do it myself. Still the target milestone gets bumped farther back (no it's at Moz1.3; at one pont I think it was destined for 0.9.*). For privacy and security I think this is a rather important feature an deserves more effort from the developers. Just my 2¢.
Re: comment #30. So get familiar with the tree. You say you're familiar with the codebase, so...
Compare bug 7380
*** Bug 163904 has been marked as a duplicate of this bug. ***
Summary: Cannot block all cookies EXCEPT for those sites specifically allowed access to place cookies. → [RFE] Block all cookies EXCEPT for those sites specifically allowed access to place cookies.
wesha, please stop adding [RFE] to all bugs that you run into. the severity is enough to indicate the enhanvement status of a bug. thank you.
Summary: [RFE] Block all cookies EXCEPT for those sites specifically allowed access to place cookies. → Block all cookies EXCEPT for those sites specifically allowed access to place cookies.
My suggestion for a prefs panel would be: [ ] Enable Cookies +- By default -------------------------------------------+ | | | ( ) Reject cookies | | ( ) Accept cookies for the originating web site only | | ( ) Accept cookies | | ( Manage Execptions ) | | | +------------------------------------------------------- + ... the rest .... The 'Manage Execptions' would open the cookie manager, with the permissions tab open. The manager needs an 'add site' button, as in bug 33467. If we can get some agreement on the UI, someone can start to makeat least the back-end. And yes, if nobody is working on this I am willing to do it, but I want to be sure to create an acceptable UI.
Why have the "Enable Cookies" check at all? It would be simpler to check "Reject Cookies" and have an empty whitelist for the same thing. (The extra UI just gets in the way - unless there's some purpose behind it that's escaping me.) Also, I think that it should be "Manage Cookie Permissions" rather than "Manage Exceptions". "Manage Exceptions" suggests that the sites listed there will behave the opposite of the radio button you have checked. (So, with a click, you change your whitelist to a blacklist and vice-versa.) "Manage Cookie Permissions" would still be the same list but, in that list, you would set whether cookies from those sites are accepted or denied (as per Manage Image Permissions).
> Why have the "Enable Cookies" check at all? Let me answer my own question - so you can temporarily disable all cookies, even those from whitelists, without having delete those entries? Is there enough of an interest in this feature for such a thing? (I'm not sure why I would ever care to temporarily disable cookies from sites from which I've already said I'd like to accept them.) How about, rather than "Enable Cookies" where you put it, an "Enable Cookie Permissions" in the sub-screen listing the cookies? It would do the same thing, but it would remove the somewhat confusing check from where it's currently proposed and put it directly into the location where it's most obvious what it does.
Yes, the enable cookies checkbox was to be able to turn of all cookies, without needing to clear the permission list. But that one is open for disccusion. Not sure anymore if it is needed. My problem with 'manage cookie permissions' is that is what you are already doing. You are managing cookie permissions. A button with that text can be confusing. The permissions dialog are in my opinion exceptions. They don't care about the general settings, but allow or reject cookies for a specific site. The behaviour at those sites is clearly listed in the dialog.
Okay, it's just the "exceptions" part that doesn't grab me because even if you tell it to accept all cookies, you could still have a list of specific sites that are set to accept cookies. So those wouldn't be exceptions. (I don't know why you'd have this, but it would be possible.) How about "Manage Sites"?
Blocks: 164421
Manage Sites sounds ok. We can alse call is 'Manage rules'. If we implement features like wildcart filtering and regular expressions, that would make sense. Ans now I think that the 'enable cookies' dialog is not necessary. It is not a very common situation to browse just for a while without cookies. In that case, you can use another profile.
When this it's implemented I think adding a button/menu option/popup option for allow actual server to write cookies. A little icon on status bar showing the actual server uses cookies will be good also. The popup could be shown rigth clicking this icon.
NetVicious: that would be a separate bug, possibly depending on this one.
*** Bug 174556 has been marked as a duplicate of this bug. ***
From bug 67580 and bug 174556: I think there should be a check box in prefs that makes cookies default to session-only and adds a cookie indicator to the status bar. Clicking the cookie icon would make existing and future cookies from the site permanent. Double-clicking the icon would open some kind of dialog: cookies from that site, all cookies, or all exceptions. (This is a replacement for "ask me before storing a cookie" as well as part of the UI for a whitelist.)
The cookie icon in the status bar is a great idea. Single clicking shouldn't do a silent action like making cookies permanent though. It should function just like the security icon. One click would show a dialog listing all of the cookies that apply to the current page (just like the security icon). You could remove any/all, and make any/all permanent. This would allow you to see what client-side state applies to the current page. Seems like power users would like this capability. The icon should be off by default. It would work great with default-to-session-only setting for power users.
Clicking the icon to accept a cookie as permanent would not be completely silent. It would change the appearance of the icon in some way. I think accepting cookies from a site would be a more common and basic action than going through the list of cookies from a site, trying to decipher each one, and exercising a line-item veto when the site is nice enough to use separate cookies for the things paranoid users want to be separate. That's why I suggested single-click to accept cookies and double-click to view a list of cookies.
*** Bug 82734 has been marked as a duplicate of this bug. ***
Summary: Block all cookies EXCEPT for those sites specifically allowed access to place cookies. → whitelist for sites allowed to store (permanent) cookies
*** Bug 74257 has been marked as a duplicate of this bug. ***
My concern is still that a single click should not do something nonobvious, and take a double-click to find out what. If the user is slow and missed the double click, they can perform an unwanted action. This is also highly inconsistent with other toolbar buttons. Single click on the lock brings up security info. Single click on the plug thingy toggles online status, easily reversable, and fairly obvious. (Since you'll get a "you are offline error" if you don't reverse it). Maybe left click to auto-accept permanently all the cookies on the current page? And a right click would bright up the info dialog, listing them, and explaining this stuff.
> Maybe left click to auto-accept permanently all the cookies on the current > page? And a right click would bright up the info dialog, listing them, and > explaining this stuff. I see nothing wrong with double-click. There's nothing arduous with doing that and the main point here is that a single click is far to easy to have happen accidentally. A double-click is hardly ever accidental, but it's also quite simple to perform - intentionally. Single click should be informational only, as per other functions, for the sake of consistency. However, at this point, further discussion is simply repetitive. Unless somebody wants to actually submit a patch (about which more discussion can take place) more dialogue should happen offline.
*** Bug 178048 has been marked as a duplicate of this bug. ***
*** Bug 173490 has been marked as a duplicate of this bug. ***
Actually I think you are all on the right roads - however there needs to be some pulling together of the ideas: There are two areas to consider: Preferences Dialog and Imediate Interface. The preferences dialog ought to be a place where one can review the current status and apply all the management functions you desire too. The Imediate interface should be quick and relatively simple so that it becomes an accepted part of browsing behaviour, not a frustration to be avoided. The Preference Dialog needs to allow the specification of the default operation and show what the current state of affairs is. Preference Dialog: +---------------------------------------------------------------------+ | SITE : # : ACCEPT : WARN : CONTROLS + +---------------------------------------------------------------------+ | DEFAULT SETTING : 763 : None \/ : [X] : {View} | | +-----------------------------------------------------------------+---+ | bugzilla.mozilla.org : 25 : Persist\/ : [ ] : {Remove} {View} | - | {up} | mozilla.org : 3 : Any \/ : [ ] : {Remove} {View} | | | {Down} | sun.com : 0 : Session\/ : [ ] : {Remove} {View} | - | +-----------------------------------------------------------------+---+ {Add} where \/ is a dropdond list {OK} is a button [x] is a check box (·) is a radio button - | is a scroll bar - The default line would be at the top of the list and specifies the actions that apply when any cookie from a site not in the list below is recieved. If the site is in the list below then apply the site specific rules. The View button allows you to view the contents and of all of the cookies stored by that site, remove individual cookies, and block individual cookies from being reapplied. Basically the current 'Stored Cookies' tab of the cookie manager. Remove allows the removal of a site from the list - the Default Settings cannot be removed. The # column shows the number of cookies each site has stored. I believe such a dialog would allow complete flexibility at a site level, I don't think working at the per cooke level is something many people will be willing to do so it shouldn't clutter the interface. If anyone had the time it would also be great if the SITE entry could take wildcards and regular expressions. Imediate Interface: The imediate interface should take the form of a cookie on the status bar that when double clicked pops up the preference dialog with new line auto-matically added for the current site, taking the default options, and being scrolled to be visible. This would then allow the user just to tweak the settings they want to alter, press ok, and return imediately to their browsing. The cookie icon on the status bar could light up every time a site tried to write a cookie so that it is possible to monitor what is going on non-intrusively. Finally I'd like to propose that the same style of interface could be applied to various related areas: Protocols Popups Animations Sounds Stylesheets etc
workaround : This ought to work on most systems (*nix given as example) 1) open the Cookie Manager 2) keep the cookies you want to have persist - delete all others 3) quit Mozilla 4) find 'cookies.txt' in your profile 5) modify the permissions : chmod 400 cookies.txt which will set it to be read-only - also to Mozilla caveat: the persistent cookies won't be updated If you want to modify/add cookies to the persistent list: 1) find 'cookies.txt' in your profile 2) modify the permissions : chmod 600 cookies.txt which will set it to be read-write - also to Mozilla 3) do as above results: 1) you'll have a list of persistent cookies 2) all other cookies will be session only no matter your cookie settings 3) the persistent cookies won't normally be modified/updated
> This ought to work on most systems An easier solution is to allow all cookies just before visiting a site you want to allow a cookie from, let it place its cookie, then change the setting back to session only. This is what I do anyway, and it can be done via the UI.
Every ordinary user isn't going to be a wizard of whitelists. If nothing else, observe the straightforward solution done by Cookie Pal for years: you make a simple set of choices in the preferences as follows: Cookies from unknown servers: O Reject All O Accept All O Ask for confirmation There simply must be a method implemented NOW to get rid of the bulk of the stupid cookie dialogs (which incidentally should say Accept, Always accept, Reject, Always Reject)!
*** Bug 184059 has been marked as a duplicate of this bug. ***
Ya know...<p> I think Mozilla should really have something like MSIE's browser helper objects--pieces of code that run whenever the browser navigates, sends a request, etc. The BHO code can look at the outgoing and incoming HTTP headers and modify them as it wishes. That would make it possible to implement any desired cookie management behavior in XUL and connect it up to the Preferences Toolbar (http://www.xulplanet.com). <p> A BHO-like feature would also allow conveniently rewriting clickthrough URL's to not redirect through the ad server, and all kinds of other things that are now done in messy ways with external ad-blocking proxies.<p> It would also be desirable to have some kind of dbm interface accessible to user scripts, if there isn't one already (I'm not a mozilla wizard, just a relatively newbie user).
Bug 173490 is said to be a dupe of this one, but there's a subtle aspect in it that I don't see here. (Apologies if I've missed this in the comments somewhere.) 173490 asked simply for the ability to always accept session cookies. The UI Duncan describes in comment #53 seems to enable that, but I'd like to clarify something. Does selecting Session under ACCEPT mean that Mozilla will only accept session cookies from that site (or by default)? Note that this is a bit different than accepting all cookies and limiting their lifetimes to the browser session. I really think it'd be useful to simply accept session cookies, and reject all others. (I personally feel that session cookies are quite palatable, but I only want long-lived cookies from specific sites. I'd like my browsing habits to reflect this to webmasters.) Many sites attempt to set a mix of session and long-lived cookies. Here's the behavior I'd like to be able to configure: - Accept session cookies - If a site tries to set a non-session cookie, ask me if I want to accept it. I think Duncan's proposed UI is really great, and the cookie icon in the status bar is cool too. I just really want to only accept session cookies and (usually) reject all others. A thought on the cookie icon: (I'm thinking of something that looks like a chocolate-chip cookie here.) It should reflect three states: accepting a cookie, rejecting a cookie, and modifying a cookie. Accepting a cookie could be a flash or pulse. Rejecting a cookie could show a red circle-slash over the icon, like a no-smoking sign (it'd be nice to somehow see a count of rejected cookies too). I'm not sure how to visually depict modifying a cookie. Twirl it around? Invert its colors? Morph it into an Oreo?
*** Bug 140137 has been marked as a duplicate of this bug. ***
People were asking for UI. I suppose I subscribe to Keep It Simple Stupid. As of build 2002101612, the cookies management really provides just about everything that people are asking for, except for the following: 1) The ability to add sites manually to the cookie management dialog (it's possible to add "block" sites manually, using the menu, but AFAIK it's not possible to add "allow" sites at all except by turning on the "ask me" nag dialog or by hacking into Mozilla's preference files manually). This could be added via a new menu where "Block cookies from this site" is, and/or an "add" button on the management dialog (more complicated). 2) Right now, "limit all cookies to session cookies" basically ignores the whitelist (not sure about the blacklist). The whitelist already exists, so the UI and backend are there. My suggestion (no UI changes needed) is to alter it such that: a) All cookies assigned (in cookie manager) to "can set" are always accepted for their full duration, no matter what b) All cookies assigned to "cannot set" are always blocked c) Any other cookies are governed by the existing cookie dialog box in the preferences (e.g., they would be allowed, denied, or limited to session) 3) The ability to limit specific sites to session cookies (e.g. by using the cookie manager). This one might not be really necessary if point (2) is implemented? Alternately perhaps this could be implemented by using the menu as well (e.g., "Block all cookies from this site," "Allow all cookies from this site," "Limit all cookies from this site" or whatever). Don't know if the backend for this would support it though. This is a lot simplier than lots of new dialogs and UI and such...
I like M.Paugh's proposal.
Just wondering - the 'target milestone' says 'mozilla1.3alpha', but this is still unadded.
Target Milestone: mozilla1.3alpha → ---
Whitelisting functionality should make 1.4. M. Paugh's proposal is good for the short term, although long-term a more functional and flexible UI for managing permissions would be desirable. Whether "long-term" also means 1.4 is uncertain, though it would be nice. Thanks for all your comments; we've taken them into consideration and should have some nice new stuff for 1.4.
*** Bug 202089 has been marked as a duplicate of this bug. ***
One of the joys of using Mozilla is the emerging pro-privacy, anti-spam, etc features. Another is the level of information available via Tools menu. I particularly love the feature to expire all cookies after a particular timeframe. (Personally, I think that it should be enabled by default: no cookie lives more than 14 days, but I'm NOT a cookie expert) Recently, I cleaned out over 4000 cookies from a friend's computer!! (Not a mozilla user quite yet, but soon!) Just a couple of things I wanted to point out in relation to 1.3... The status bar would benefit with some extra indicators: Javascript (with indication of error and/or blocking) Cookies (with indication of blocking) Popups (with indication of blocking) The idea being if a page doesn't display/behave, there is some visible clue to the reason why. (Without a blaring dialog) I think this fits reasonably with the padlock open/closed for secure sites. In a way, a GUI version of the tools menu... Another thing I wanted to point out is that there is no information about Javascript or Cookies in the context of the Page Info dialog. Anyway, overall, thanks for Mozilla!
*** Bug 145690 has been marked as a duplicate of this bug. ***
The popup blocking indicator is there already.
Blocks: 145690
CC -> self
I don't know whether this is the right bug to add this comment: advice is appreciated. These comments all seem to be about when to accept and store cookies that a remote site sends. I think there should also be some control over when to send cookies (especially cross-site cookies) that are ALREADY SET. Real-life example: I login to www.paypal.com and it sets a permanent cookie connected to my user ID. I WANT this cookie because it saves me login typing when I use Paypal by explicitly visiting it. Call this cookie "Alice". Now the bad part. www.junkmerchant.com has a Paypal logo on their site that says "Pay here with Paypal". The logo gif comes from www.paypal.com, which means that as soon as the merchant's page loads the gif, the browser sends Alice to www.paypal.com. Paypal now has personally identifying info that I visited junkmerchant.com, and further, it shares this info with junkmerchant (the Paypal privacy statement specifically says that this info can be shared). The only way to stop it is to not take persistent cookies from Paypal, which gets rid of the convenience feature. So it would be very useful to have a setting for: "do not send any cookies to any site except the one in the navigation bar, even already-existing cookies". That's stricter than the currently available "don't accept new cookies unless they're coming from the site being visited". There may have to be a way to override this case-by-case with the cookie manager, but those instances should be pretty rare.
Clarification to #70: junkmerchant.com was a made-up example of a merchant site with a Paypal logo. The Paypal cookie description and note about Paypal's privacy statement are real. Also, in case it wasn't absolutely clear, I'm talking about controlling cookies that the browser sends to the web site, not the other way around.
> "do not send any cookies to any site except the one in the navigation bar, > even already-existing cookies". That's called "Enable cookies for the originating web site only", available in the cookies dialog, and does exactly what you want, I think. Not sending real referrers to 3rd parties would help as well. In any case, that's offtopic here.
According to the help file, "Enable cookies for the originating web site only" stops non-originating sites from STORING cookies. If it also stops the non-originating site from RECEIVING cookies that have already been stored, then the help file's description is incomplete. Anyone know for sure? I may try an experiment sometime to see what actually happens.
Ben's description is correct, but there are ways that sites can circumvent this, and always will be. Thanks for pointing out the help file is wrong - I'll see about updating that ;)
Blocks: majorbugs
If anyone cares, as a temporary stopgap til something is done for this CR, I threw together a Python script that cleans out my cookie file (.mozilla/default/whatever/cookies.txt) according to a whitelist and blacklist flie. I run it a few times a day (actually much more than that, because it's a new toy) and enjoy seeing the junk it sweeps out. It prints a list of how many cookies it's deleted from each domain. I use it under Linux (installed in same directory as the cookies.txt and whitelist and blacklist files) and have no idea whether it can be ported to Windows. It's at: http://www.nightsong.com/phr/python/tosscookies.py
Another FYI for users wanting this functionality, bug 184059 was just fixed which should provide the backend for this, and allow this functionality now, if you're up to manually editing cookperm.txt.
*** Bug 82858 has been marked as a duplicate of this bug. ***
*** Bug 192176 has been marked as a duplicate of this bug. ***
*** Bug 200873 has been marked as a duplicate of this bug. ***
*** Bug 67580 has been marked as a duplicate of this bug. ***
Jesse a lot of those bugs you duped here are valid, seperate ideas. There's no design spec here that shows those will be implemented simultaneously, so the bugs should remain open as the only documentation available.
Hmm...it would be good to merge these subjects into one and try to get the best of all of them. Marking them as a dupe usualy implies "the person who posted that bug didn't bother searching for this bug, so ignore that bug", whereas it would be better to consider all of the comments in the bug marked as dupe...perhapse that calls for an RFE to bugzilla itself to address it :)
I too wish that there was a cookie whitelist option. There are only a few websites that actually use cookies that I commonly visit. I have all of them marked as being allowed to store cookies. It is annoying to have to disable all cookies so I don't get prompted for each cookie that I don't want. I should be able to select what cookies I want beforehand and then put the whitelist option. With it, only those cookies would get stored, and the others would not be prompted for. Similarly, it should affect the tools menu so that block and unblock cookie would become whitelist and ignore cookie or something to that effect.
[This comment concerns the workaround script previously posted, as I believe it is of interest to users watching this bug. Also, I retract comment 76, as the implemented white-listing doesn't (yet?) work with the session-only cookie setting, which is of more practical use] If anyone cares to hack a little Python (I only know Perl unfortunately), Paul Rubin's script is /almost/ there. Issues that really need to be fixed to make it usable: This dies if /tmp and the profile aren't on the same file system. Very common. os.rename(tempname, cookie_filename) Most users won't need blacklist functionality, so don't die if there is no file: File "./tosscookies.py", line 61, in read_ruledict for line in open(filename): IOError: [Errno 2] No such file or directory: 'blacklist' I think those changes, and a little cleanup would make it generally usable for a great number of interested people. Additionally, it would be nice if it could automatically find your profiles, and provide a way to match domain cookies without having to use both the white and black lists. (For random partner sites under a domain which sets cookies you do want, but happen to be domain-wide) P.S. If anyone would like to send me the latest edition of Programming Python, I'll make those changes for you myself. Take up a collection or something. ;)
I see no mention in this bug about the fact that cookie whitelisting and blacklisting has been implemented quite recently in Mozilla Firebird. I'm wondering whether it would be feasible to backport that implementation into Mozilla.
Where did you see cookie whitelisting enabled Per? I did not see anything mentioned ahywhere about this...
In Mozilla Firebird, it's called Cookie Exceptions. I can't find any direct announcement or a Bugzilla bug for it, but it's in release 0.7 if you want to try it out (the user interface is in the Cookies section of the Privacy Options panel).
See bug 217086 comment 1. There's mention there, that Blake introduced cookie whitelisting no later than August 23rd. (But I can't find any actual bug for this either.)
Hmm...this doesn't quite fit what I had in mind with the bug I reported earlier. What I was thinking involved having a toolbar control toggle, similar to the blue popup icon, that would whitelist the site for cookies when you click on it. All other cookies would be session only. (of course, this entire system is opt-in only (at first anyways) via a checkbox in the cookie section of the privacy tab)
dwitte implemented this via another bug in the cookies backend, so if you make the edits by hand in Seamonkey in cookperm.txt it'll work. Blake implemented the exceptions UI into Firebird, there are plans to implement similar changes into Seamonkey, along with statusbar notifications/whitelisting, which was waiting on further rewrites of the backend code now done, so its a matter of UI work now (I wonder who the slacker responsible for that is...)
I strongly agree with comment 53 from Duncan Kimpton, with Marc Branchaud's update in comment 59 - I'd strongly invite powerfull interface to disallow some behaviour (cookies, popups, images, sounds) of lame www pages. for images/popups/sounds a simpls whitelist/blacklist is enough (just to implement it) for cookies, It's a little bit harder because of session cookies, but that could be probably resolved by: - possibility to differ between session and permanent cookies (if user wishes so) - force "permanent" cookies to be forgot after session ends. for comment 61 - could there be two (simple and advanced) interfaces? However, one feature what I REALLY MISS is to have whitelist of cookies. To have denied cookies by default and only allow them from menu. Another idea is that behaviour "accept" and behaviour "reject" should ONLY be the defaults, with possibility later choose, which rejected cookies on current page to allow and which to deny. That would imho make the thing much easier - one of options "flag" and "ask before storing a cookie" would become redundant. How do coolkies differ? - First party / third party - Permanent / session - 4(?) privacy settings What can we do with them? - allow (with blacklist) - deny (with whitelist) - limit them ("permanent" cookies only) I'd see it this way: First party cookies: permanent cookies session cookies: [X] the same (*)Allow [ ] Ask for storing ( ) Allow [ ] ask for storing ( )Deny [ ] Limit life for this long ( ) Deny Third party cookies: [X] the same first party cookies permanent cookies session cookies: [ ] the same ( )Allow [ ] Ask for storing ( ) Allow [ ] ask for storing ( )Deny [ ] Limit life for this long ( ) Deny - if "ask for storing" is checked, Allow/Deny and limit are the defaults which can be overridden in dialog. Otherwise (or if user presses escape on cookie dialog, the default action is taken. - when Limit is "0", it means current session, empty limit means no limit. I am not sure if privacy settings are important. However, site's privaty policy should appear in dialog, or there would be more settings like in font selection
Whitelisting of cookie and images is in the current builds. (the entries in the sites tab of the cookie manager now overrides the prefs, and you can add sites to the list) Bug 216743 tracks the tweaks to the UI.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Last time I checked, there was no way to do what this summary says, which is my ideal cookie configuration. Have a whitelist of friendly sites, that I want to track me, for my own benefit (bugzilla, slashdot, yahoo, etc). This works as of recently. Have a blacklist, as always, for sites I do not want to accept cookies from at all. This has always worked. And, here's the important part, accept all other cookies as session cookies, so there is not a MAJOR loss of functionality. Last I checked, this was not possible. A default policy of accept creates too many unwelcome permanent cookies. A blacklist can not keep up. And a default policy of deny, with whitelisting, breaks too many innocent sites, that mearly need session cookies. Have any additonal changes been made that this is now "FIXED"?
then i suggest you check again. it's possible to do that now.
> accept all other cookies as session cookies Edit -> Preferences -> Privacy & Security -> Limit maximum lifetime of cookie to (x) current session. It's been in the suite for many months now. This will cover all circumstances that aren't covered by existing blacklists and whitelists. The only thing that's currently missing is the UI for what's already in the backend w/r/t whitelists/blacklists. This bug *could* be closed as resolved - except that the current situation (hacking the backend cookperm.txt file) doesn't satisfy the intitial reporter's "very simple cookie management" criterion.
Attachment #136640 - Attachment is patch: false
Attachment #136640 - Attachment mime type: text/plain → image/png
Attachment #136641 - Attachment is patch: false
Attachment #136641 - Attachment mime type: text/plain → image/png
Verified fixed Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031201 see bug 222553 for the UI fix to this, misc bugs for the rest screenshots provided for those who obviously aren't using nightlies to base their opinions on
Status: RESOLVED → VERIFIED
*** Bug 230202 has been marked as a duplicate of this bug. ***
No longer blocks: 164421
Blocks: 158464
No longer blocks: majorbugs
*** Bug 301467 has been marked as a duplicate of this bug. ***
Any chance of getting this for Firefox 2? Did it fall through the cracks? We're up to rv:1.8.1.3 now, and there's no sign of it.
Erm... Firefox 2 has this capability?
(In reply to comment #102) > Erm... Firefox 2 has this capability? > I'm afraid not. I'm looking at the Tools menu right now and comparing with the screen shots. The Tools menu has the following entries: Web Search, Downloads, Add-ons, Error Console, Page Info, Clear Private Data, and Options. I've also looked through the options menus and the Help menu. No sign of the Cookie Manager. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3 . New, default profile.
Try the settings/options/preferences menu (I'm not sure what it's called in the EN Version..I'm using a localized version) and then the Privacy tab. There's the cookie manager. You can uncheck "Accept cookies" and then add sites under "exceptions". This will cause Firefox to accept cookies only from the specified websites.
OK, now I see it. There are two UI problems: 1. The "cookie manager menu option" attachment is NOT implemented. 2. The word "Exceptions" does not lead users to a white list. The word seems to imply a black list. You'd be surprised how many veteran users do not discover this, and how many cookie extensions there are to do this. I'll consider a separate bug, but let's see if we can educate users first. Thanks.
1. This was a Mozilla bug from the time before Firefox existed, and it still exists in Mozilla's successor SeaMonkey. In Firefox, the cookie manager menu item was deliberately removed, together with all other manager menu items. A bug asking for it to be restored would just be WONTFIXed. 2. Please cut the chatter in this long-dead bug. If you need further information, take it to one of the support newsgroups, mozillazine forums, or IRC.
I'd like to have a whitelist for sites, which are allowed to save login or form data. Some login usernames or passwords are not customizeable and it would be nice to have the possibility to save these and only these.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: