192176 - Statusbar-based cookie controls

Status: RESOLVED WONTFIX

(Core :: Networking: Cookies, enhancement)

Description

[alphawolf_]

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
advertizing.

Reproducible: Always

Steps to Reproduce:
N/A
Actual Results:  
N/A

Expected Results:  
N/A

Comment 1

[Darin Fisher]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

Just have to watch out for sites that go into an infinite redirect loop when
cookies are blocked...

Comment 3

[benc]

alphawolf: I tried to make the summary more searchable... let me know if this
was not what you intended.

Comment 4

[Jesse Ruderman]

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.

Comment 5

[alphawolf_]

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 :)

Comment 6

[Jesse Ruderman]

*** This bug has been marked as a duplicate of 75915 ***

Comment 7

[Mike Connor [:mconnor]]

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.

Comment 8

[Mike Connor [:mconnor]]

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.

Comment 9

[Mike Connor [:mconnor]]

-> me
-> removing dependency
-> depends on 221185

Comment 10

[Mike Connor [:mconnor]]

Attachment: screenshot of blocked cookies dialog

we need an icon, someone gave me one a while back, but I think I lost it

Comment 11

[Jeremy M. Dolan]

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.

Comment 12

[[e-mail]]

yes. that's entirely a different bug, and entirely a different goal.

Comment 13

[alphawolf_]

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.

Comment 14

[Mike Connor [:mconnor]]

another separate bug, see bug 216743

Comment 15

[Mike Connor [:mconnor]]

Attachment: first patch

Comment 16

[Mike Connor [:mconnor]]

Attachment: new files to go with above patch

new files:

mozilla/extensions/cookies/locale/en-US/cookie/cookieBlockedList.dtd 
mozilla/extensions/cookie/content/cookie/cookieBlockedList.xul
mozilla/extensions/cookie/content/cookie/cookieBlockedList.js

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

this icon sucks, we need artwork :)

Comment 17

[Scott Plante]

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 'www.asite.com' the cookie
you want to allow is from 'asite.com' or 'login.asite.com'.

Ideally, IMHO, the current statusbar icon for 'view cookie controls' would bring
up the list of cookies and sites associated with the current page.

Comment 18

[Michiel van Leeuwen (email: mvl+moz@)]

And what do you think the screenshot shows?

Comment 19

[Jeremy M. Dolan]

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?

Comment 20

[Mike Connor [:mconnor]]

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

Comment 21

[alphawolf_]

Scott, I believe we could easily solve that problem by allowing the user to
enable *.domain.com wildcards. In fact, I think the current cookie whitelisting
feature could use a wildcard option as well...

Comment 22

[[e-mail]]

cookie whitelisting already works that way.

Comment 23

[Mike Connor [:mconnor]]

*** Bug 203586 has been marked as a duplicate of this bug. ***

Comment 24

[Mike Connor [:mconnor]]

Not going to be working on any Seamonkey UI bugs for the foreseeable future. 
You can filter on "danlikesgoats" to delete this spam.