Closed Bug 75915 Opened 23 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: