Statusbar-based cookie controls

RESOLVED WONTFIX

Status

()

Core
Networking: Cookies
--
enhancement
RESOLVED WONTFIX
15 years ago
2 years ago

People

(Reporter: alphawolf_, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
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

15 years ago
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
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Future
Just have to watch out for sites that go into an infinite redirect loop when
cookies are blocked...

Comment 3

15 years ago
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

Comment 4

15 years ago
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.
(Reporter)

Comment 5

15 years ago
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

15 years ago

*** This bug has been marked as a duplicate of 75915 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 15 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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Updated

15 years ago
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
Status: REOPENED → NEW
Depends on: 221185
Summary: Toolbar based cookie controls → Statusbar-based cookie controls

Updated

15 years ago
Blocks: 216743
Created attachment 134957 [details]
screenshot of blocked cookies dialog

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

Comment 11

14 years ago
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

14 years ago
yes. that's entirely a different bug, and entirely a different goal.
(Reporter)

Comment 13

14 years ago
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
Created attachment 135160 [details]
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

14 years ago
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.
And what do you think the screenshot shows?

Comment 19

14 years ago
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
(Reporter)

Comment 21

14 years ago
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

14 years ago
cookie whitelisting already works that way.

Updated

14 years ago
Status: NEW → ASSIGNED
Priority: -- → P3

Updated

14 years ago
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
Status: ASSIGNED → NEW
Priority: P3 → --
Target Milestone: Future → ---
Status: NEW → RESOLVED
Last Resolved: 15 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.