Closed Bug 192176 Opened 17 years ago Closed 4 years ago

Statusbar-based cookie controls


(Core :: Networking: Cookies, enhancement)

Not set





(Reporter: alphawolf_, Unassigned)





(3 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

Please hear me out on this one, I have done lots of planning on how this would
work out, and I truely believe that this is the ultimate magic-bullet solution
to internet privacy via cookie management. :)

Basicaly what I am suggesting is the ability to easily and painlessly toggle
whether or not cookies will be accepted on any given site, without having to go
through several menus to specificaly allow/denie specific sites like you
currrently have to do. Instead of having to use menus and managers, we will have
just one button that handles it all.

First, there would be an option in the preferences menu which allows you to turn
this specific feature on. (it would be off by default of course) When it's
turned on, a new button shows up on the the toolbar (or a separate bar), which
is basically a toggle switch for allowing cookies at site that is currently
being viewed.

Now in this mode, all cookies at all sites are blocked by default. If the given
site needs to use cookies, then all you have to do is click the toggle button,
hit reload, and the browser accepts all of the sites cookies. If the user
returns to that site later, and decides to no longer accept cookies from that
site, he/she can simply hit the toggle button, and the browser discontinues
accepting cookies from the site again. It will not delete the cookies from that
site however; it will simply hold on to them until they expire, but will not
acknowledge their presence to the site that is asking for them. This way if you
set anything specific for the site (e.g. googles preferences), then you decide
to accept its cookies again, all of the info you set is not lost.

Now that the basic features are out of the way, there is also room for more
advanced features. The toggle button could have a "right click" context menu,
which lists all of the cookies that the spcific site issues. When the user
enables cookies for that site, he/she can go through the context menu and
specificaly block certain cookies that the site issues, while accepting others.
The cookies listed in that menu could also be color coded by the type of cookie.
For example, color code the cookie listing as red if it has any words mentiong

Reproducible: Always

Steps to Reproduce:
Actual Results:  

Expected Results:  
sounds almost similar to the way popup blocking works.  say you get a cookie
icon in the status bar when cookies are blocked.  then you could say click on
that to inspect the cookies that the site wanted to set.  you could imagine
manipulating your cookie blocking rules from that dialog.  or something like that.

-> future
Ever confirmed: true
Target Milestone: --- → Future
Just have to watch out for sites that go into an infinite redirect loop when
cookies are blocked...
alphawolf: I tried to make the summary more searchable... let me know if this
was not what you intended.
QA Contact: tever → benc
Summary: New, easy to use approach to cookie management and privacy. → Toolbar based cookie controls
If you're ok with the default being "restrict cookie to session" (rather than
"disable completely", which has the problem mentioned in comment 2), then this
is a dup of bug 75915 via bug 67580.
That sounds like a good idea. Or there could be a checkmark like toggle in the
cookie control properties to switch between keep for session, or block
completely. Although the UI they have in mind isn't quite as good as the one I
have in mind IMHO :)

*** This bug has been marked as a duplicate of 75915 ***
Closed: 17 years ago
Resolution: --- → DUPLICATE
whitelist support is effectively in thanks to bug 184059.  This is really a
separate concept from a whitelist, although it would logically be dependent on
whitelist support.  Reopening based on that, I expect to have a patch for this
in time for 1.6a.
Resolution: DUPLICATE → ---
Blocks: 217199
Okay, no patch until the backend gives a sane cookie notification that includes
the site for the blocked cookie. dwitte said he needs to do this, but he doesn't
know when it'll be done.

As a note, 217199 is the Firebird equivalent since the XUL work won't quite be
the same.  I will do both patches once the backend is implemented.
-> me
-> removing dependency
-> depends on 221185
Assignee: darin → mpconnor
No longer blocks: 217199
Depends on: 221185
Summary: Toolbar based cookie controls → Statusbar-based cookie controls
Blocks: 216743
we need an icon, someone gave me one a while back, but I think I lost it
Idealy, the dialog should provide a way to actually accept the cookie that was
already recieved, not just add the site to the white/blacklist, and then having
to reload to actually have it set.

This is also true for the popup notification. Idealy you should be able to click
'show' instead of allow, to see what it tried to pop up, without having to
accept all future popups from the domain, or reload to see the popup, then enter
prefs are remove the site if it's just an ad.

Is there a technical reason why this can't be done for cookies? Is the cookie
code syncronous in that say, img=/foo.png may depend on the cookie from '/'
already being set?

Regardless, Mike's current work would be a great start. I know accepting the
cookie in "real-time" would be (much?) more difficult to implement, I just want
to make sure everyone has their eyes on the right goal, even if it's another
year away.
yes. that's entirely a different bug, and entirely a different goal.
Well, couldn't we just "session-only" every cookie thats received unless told
otherwise by the user? In this case, the website can't malfunction due to a
missing cookie, since all cookies *will* be present, and at the same time,
accomplishing our goal.

Also, to prevent the website from detecting that we are doing this (in case the
website malfunctions because of any expiration date anomalies,) store the
cookies exactly as the website specifies (e.g, expiration date remains intact,)
only we don't actually treat the cookie as the website instructs, by deleting it
at the end of the session.
another separate bug, see bug 216743
new files:


and copy the png to both of 
mozilla/themes/classic/skin/classic/navigator/icons/cookie-blocked.png and

this icon sucks, we need artwork :)
This is a bit tricky because what you really want is to toggle the cookies for
all the sites on the *page*, not necessarily the site in the URL bar. This can
be different because images and other included content may come from different
sites and have different cookies. Often times ads on a page will have their own
cookies that you want to block, and while you're on '' the cookie
you want to allow is from '' or ''.

Ideally, IMHO, the current statusbar icon for 'view cookie controls' would bring
up the list of cookies and sites associated with the current page.
And what do you think the screenshot shows?
Is this still a moz1.6/fb0.8 contender? This could be another killer feature for
power users. I'm happy to test the heck out of it, but incapable of building. Is
there time to get a review and checkin for the beta timeframe?
this isn't ready, the notifications code isn't quite giving me enough info to 
do this effectively.  1.7/0.9 is my expected target
Scott, I believe we could easily solve that problem by allowing the user to
enable * wildcards. In fact, I think the current cookie whitelisting
feature could use a wildcard option as well...
cookie whitelisting already works that way.
Priority: -- → P3
Blocks: 217199
*** Bug 203586 has been marked as a duplicate of this bug. ***
Not going to be working on any Seamonkey UI bugs for the foreseeable future. 
You can filter on "danlikesgoats" to delete this spam.
Assignee: mconnor → nobody
Priority: P3 → --
Target Milestone: Future → ---
Closed: 17 years ago4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.