Closed Bug 217199 Opened 21 years ago Closed 12 years ago

Status bar indicator for blocked cookies

Categories

(Firefox :: General, enhancement, P4)

Product:
Firefox
Component:
General
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: andrew, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030824 Mozilla Firebird/0.6.1+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030824 Mozilla Firebird/0.6.1+

One of Firebird's best features is the integrated popup blocking that provides
an icon indicator when it has blocked a popup window, allowing the user to click
on it and selectively enable any popups for a certain page.  I submit that a
similar feature should be implemented for cookies to simplify in cookie
management.  If all cookies are set to be blocked in Options/Privacy, then an
indicator on the status bar would allow the user to see a list of blocked
cookies (both for the site currently in view and possibly a log of recently
blocked cookies, which would clear an old bug report) and then allow the user to
allow specific cookies for either the session or permanently add them to their
whitelist.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Summary: Status bar indicator for blocked cookies with management system → Status bar indicator for blocked cookies
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Firebird0.8
See also bug 216743.
-> taking

I was already working on this.  This requires making the backend not suck, which
dwitte is going to do at some point.  Adding dep on the seamonkey bug for the
same functionality.

Possibly during 1.6a cycle, but not 100% sure.
Assignee: blake → mpconnor
Depends on: 192176
This would be absolutely wonderful to have.

I highly recommend that all blockers (popups, images, cookies, JavaScript
actions, plugins, etc.) be given consistent treatment: an icon in the status bar
that appears when blocking takes place.

Not only would this be consistent and give immediate visual feedback as to what
has just gone on, it would also give the user an easy way of finding out more
information about what blockage has just happened (for instance, if the user
wants to see exactly what was blocked or undo the blockage).

This would give a great sense of empowerment to the user!

Possibly instead of having separate icons on the status bar for different
blocked media (popups, cookies, even images if the devs decide to go that far),
maybe a central dialog box that allows total control over what's temporarily
allowed, permanently allowed via whitelists, and a listing of recently blocked
media would be a good way to go.  That would provide a consistent interface for
all the recently blocked media, though I'm not sure how simple it would be to
navigate once implemented.  It would almost have to be like a separate options
dialog if fully implemented like that.
Status: NEW → ASSIGNED
QA Contact: asa
Should have 4 states
No cookies
All blocked
All allowed
Some blocked, some allowed
QA Contact: davidpjames
No longer depends on: 192176
slipping, more work on backend for this to work, won't be until 1.7a
Target Milestone: Firebird0.8 → Firebird0.9
In the long term I'd like to see optional tool bar icons that could be used to
enable/disable images, scripts, plugins, cookies and popups, integrating the
status-bar indicator and behaviour (perhaps in a drop-down?).

In the more immediate future, a simple status bar icon for blocked cookies as
described would clearly be *really* useful.

I would suggest that Hotmail be used as a test case for this feature (since this
is -always- when I wish I had it!).

When logging into Hotmail, they set an ungodly horde of cookies from several
different sites (hotmail.com, msn.com, passport.com, passport.net--several
domains on each!).  And all of this happens as it merrily forwards me along to
different pages and servers.  To fix this, it seems the cookie backend would
have to keep track of cookies set not on individual pages, but between
"user-interactive" pages.  Then once I finally am stopped, I can click on the
status icon and see a list of all the cookies the server tried to set, and then
select which domains I wish to add to my whitelist.

Also, having a simple way to add only the root domain (just one passport.com,
instead of login.passport.com, hotmail.passport.com, etc.).  It looks like the
popup blocker dialog does this now, so perhaps it could just be the default. 
The only problem is the case where the user -wants- all the specific domains, in
which case they wouldn't even be displayed.  I'm unsure of an appropriate
solution to this--perhaps a preference pane for "blocker notification" or
something, especially if all the blockers are merged as suggested above (another
good idea).

This is my opinion of how cookie handling should work:

Session cookies should always be allowed by default and always be discarded at
the end of the session.

Permanent cookies should be accepted by default (checkbox in prefs) but all
third party cookies should be blocked by default (again, checkbox in prefs).

In all cases, unless otherwise specified, the accepted cookies would be removed
at the end of the session, just like session cookies. This means that there's no
cookie-tracking/security issues associated with cookies by default.

Now, here's the thing... if a site tries to set permanent cookies (which will be
accepted for the session by default), there should be a status bar alert icon
(like the popup blocker). On clicking it, the user will be informed that the
site has tried to set cookies/store data (something user friendly), which will
be removed when they close the browser, with an option to remember them
(whitelist the site and keep the cookie when the session is ended).

This would allow for mostly seamless browsing IMO.
comment 9 just isn't feasible without some major changes in the backend.  It
would also cause a huge number of problems with the default settings that way,
since you're now forcing users to actively whitelist sites.  A lot of users
simply don't want the hassle of doing that.

comment 8 is tricky to implement, without screwing up how other things work.  It
might be possible, but its a few degrees of difficulty higher than making this
work on the basic level.
My ideas in Comment 9 dont require you to actively whitelist cookies... they
only require you to do so if you wish the cookies to be remembered beyond the
current session. In most cases, this would eliminate the need for user action
completely except for web applications such as forums and others where
peramanent cookies are appropriate.

To date I have around 20 cookies, not all from individual sites (maybe 12 or so)
that have set useful cookies in my 7+ months of Firebird/Firefox usage. Since I
dont want people tracking my browsing or doing anything else relating to
cookie-abuse, I actively blocked out all cookies and whitelisted sites
individually. With the "temporary cookie" scenario, this would not be required,
and is more user friendly.

Try browsing with cookies disabled, and you'll get the same browsing experience
I have daily. It doesn't create any problems, and like I said, I have very few
sites (mostly forums) where I use cookies. You'll note that with cookies turned
off, some forums wont work (and you'll experience other similar behavior). With
temporary cookies, this wouldn't happen, while maintaining security.
I don't think its a sane default, and I think the security concerns over cookies
are overstated.  I have probably tried more variations on cookie prefs in the
last two months than anyone, given my work on the cookies backend, and I
personally think that having to manage cookie sites, even just for specific
sites, is irritating to a large proportion of users.  There might be a case for
enabling "for the originating site only" but that's nothing to do with this bug.

If it negatively affects users and forces users to configure the browser to
accept certain sites, this is an undesirable decrease in usability for a
majority of users.  There is no way I'd propose it, and no way I'd expect the
module peers to accept this.
Ok, maybe being the default setting is not the best idea afterall, however,
would it be worth filing an additional bug requesting support for this in the
backend so that an extension can be produced? As far as I can guess (I'm no
expert) it should only require a flag, and some code that chooses writing and
reading from virtual (in memory) cookies and real cookies based on the
whitelist. If you think it'd require too much work I will forget it, but either
way it's going to exceed the scope of this bug.
The problem with retroactively keeping session cookies for longer is that 
cookies are read-only.  You would need to a) preserve the original lifetime and 
b) have a function to delete the cookie and recreate it with the same values 
except for the lifetime.  It could probably be done, but it wouldn't be easy at 
all.
When I submitted this enhancement, I had something similar to comment 8 in mind.

The way I see this enhancement coming out in my mind is an indicator that
appears on the toolbar when a cookie is either accepted or is offered to be
accepted by a website, depending of course, of what the default behavior is set
either by the browser upon first activation or the user.  The indicator then
opens a small dialog that allows you to view all the cookies currently loaded by
the browser, sorted by site name and perhaps even time of acceptance (so it
would be obvious if you're on the NYTimes website which requires a cookie to be
loaded to read articles that the cookie from www.nytimes.com is on the current
page you're viewing), that would allow you to accept a specific cookie either
for the session or permanently, as well as a check box with language similar to
"Accept all cookies from this site?" which would allow domain-level cookies,
again, either permanently or just for the session.

I think the default behavior of the browser, however, should definitely be
accept all cookies for the life specified by the cookie.  I have a whitelist of
20 or 25 sites that I visit frequently, but just because I enjoy browsing with
cookies turned off and I know the benefits of the reduced privacy risk doesn't
mean that the average user cares.  Most users--the ones that Firefox is
attempting to make inroads with, either through press or fellow users
introducing them to it--want simple, predictable behavior, and having cookies
disabled by default doesn't fall under that idea.  Privacy and security is a big
issue with Mozilla and its sub-projects such as Firefox and Thunderbird, though,
so perhaps an addition to the help documentation should be created and linked
from the dialog that pops up.  Education of users would definitely make a
difference, and instead of forcing the behavior that requires some thought to it
upon them, we should leave it up to them to discovered this by themselves.
As a brief status report on this, I do have nearly working code in bug 192176.  
However, this doesn't work well across multiple tabs/windows.  Once that issue 
is resolved, I should be able to produce the FF portion of the patch with very 
little modification.

Allowing the ability to accept cookies from the statusbar would require a lot 
of work, since cookies are simply accepted or rejected.  Once they're rejected 
a notification is fired that gives us the ability to show the blocked site, but 
that doens't contain the info for the blocked cookie.  We could do it, but I 
don't know if its necessary.  The initial goal for this is to provide an 
indicator and a popup showing the sites that couldn't set cookies, along with 
the ability to assign permissions to that site.  After the fact acceptance is 
possible in theory, but I doubt anyone wants to work on that for the backend.

Future enhancements will include selecting parent domains in the popup, having 
another indicator for accepted cookies, and the ability to filter the blocked 
sites indicator by the sites permanently blocked in the blacklist.  (I might do 
that for the initial implementation too, I'm currently thinking of pro/con 
arguments for that)
I don't mean to rain on the parade here, but there's very little benefit to
doing this.

Here's why:

Background: The principal reason for interaction with any of the cookie
functionality on the part of the majority of users aware of cookies is to remove
them all, for reasons of privacy (they're handing their machine to someone else)
or because a site is suffering from a bad state (and the user is sophisticated
enough to know that cookies are the reason for this).

As a result the cookie UI in Firefox as it stands today probably represents the
maximum level of detail and control that even the mildly paranoid would be
interested in having. (There are some simplifications that can be made to the
manager).

Cookies are implementation details of web sites, and as such the data they
contain is rarely human readable. Making it more accessible to people is not
consistent with the philosophy of simplicity. 

Popup blocking is on by default, and represents a problem experienced by a vast
majority of web users, and offering a way to open blocked popups would be a
beneficial enhancement. Cookie blocking is off by default, and the problems
encountered as a result are problems that those enabling cookie blocking should
be prepared to endure. 

The only potential aspect of value to Firefox is per-site preferences, where
there would be the ability to enable/disable cookies from a page from the
browser UI. We are beginning to think about how to do this in conjunction with a
variety of other preferences after 1.0.

This feature belongs in an extension. 
ben, http://bugzilla.mozilla.org/attachment.cgi?id=134957&action=view is the 
maximum amount of UI I could ever justify for this.  Just because we have don't 
block cookies by default doesn't mean we should make things more difficult for 
users that choose to be more paranoid.  If a user happens to block cookies for 
whatever reason, and goes to a site to that requires cookies, with this dialog 
they click an icon and unblock the site they want.  Without this, they need to 
go through Tools->Options->Privacy-Exceptions and manually type in the site 
they want to set the cookie for, which might not even be correct.  The problem 
with Seamonkey's implemenation (Tools->Cookie Manager) is that it uses the 
current URI, which might not be the URI of the site trying to set the cookie 
that is needed.  This actually uses the URI that was specifically blocked, and 
lets that user have a far better user experience even with a non-standard pref.

This is a big win for usability in a non-standard setting, for a relatively 
small size loss.
Target Milestone: Firefox0.9 → After Firefox 1.0
This bug will need to wait on the new extension manager bug 170006. No sense in
writing some code then have the extension manager change drastically when bug
170006 is checked in.
Sorry about the bug spam ignore comment 19, had a few tabs of bugs open. 
(In reply to comment #17)
> 
> I don't mean to rain on the parade here, but there's very little benefit to
> doing this.
> 
> Here's why:
> 
> [...]
> 
> This feature belongs in an extension.

I don't see it that way. Here's why:

The current standard UI contains two useless functions.  The total list of
functions is:

1. Silently accept all (this should probably be default, as I assume it is)
2. Silently accept from originating site
3. Silently block all
4. Confirm all new sites

That list doesn't match the UI knobs, but it's quite obvious which settings
correspond to which function.

Both functions 3 and 4 are impractical.

Number 3 is impractical because it doesn't provide an indicator that cookie
blocking might be a problem when you're trying to figure out why a particular
site isn't working.  Nor does it provide a way to allow a particular cookie
in that case.

Number 4 is impractical because it pesters the user with questions to which
the answer is almost always, "No".

I suspect both 3 and 4 could be replaced with functionality like this:

Accept all cookies but don't return any.  Provide a status bar icon (like the
one for popup blocking) that lists cookies for the current page and allows them
to be enabled, and optionally for the site to be whitelisted.

Such a change would replace two useless functions with one useful function. It
does not belong in an extension.  OTOH, additions like full regex matching on
all cookie attributes, which many hardcore Unix users might like, _does_ belong
in an extension.
Depends on: 192176
Priority: -- → P4
*** Bug 239990 has been marked as a duplicate of this bug. ***
I am the one who filed the bug in comment 22.  Please have a look at my take
there.  An excerpt:

> - Have visual feedback when a cookie is used/denied.
> - Make it so that the user is prompted only when he/she
>   wants to make an exception, not every time.
> - Make editing the exception list a single click on the
>   icon, not 2 levels down the perfs.

In relation to this bug, I think it is particular important that:

- There should be visual feedback not only when a cookie is blocked, but also
when a cookie is accepted.  Ideally this is so that the user can then click on
the indicator to (re-)block a site, that was previously unblocked by policy or
by user request.
> > - Have visual feedback when a cookie is used/denied.

used?  show on use would be so common as to be fairly useless as a feedback
mechanism.

> > - Make it so that the user is prompted only when he/she
> >   wants to make an exception, not every time.

er, how would you determine whether the user would want to make an exception?

> > - Make editing the exception list a single click on the
> >   icon, not 2 levels down the perfs.
> 
> In relation to this bug, I think it is particular important that:
> 
> - There should be visual feedback not only when a cookie is blocked, but also
> when a cookie is accepted.  Ideally this is so that the user can then click on
> the indicator to (re-)block a site, that was previously unblocked by policy or
> by user request.

that's probably excessive, and not really useful to most users.  I might hook up
functionality for that in an extension and/or seamonkey, but I'm not sure on that.
> used?  show on use would be so common as to be fairly useless
> as a feedback mechanism.

The way IE6 does it is to have a different indicator for 'cookie-accepted' apart
from the one for '(some or all) cookie-denied'.  It is useful feedback that way.

> that's probably excessive, and not really useful to most users.

I assume you are not referring to 'letting the user click on the icon to edit
his/her cookie pref for the site', since you you propose the same thing on
comment 18.

So if you mean 'indicator for accepted cookies too', it just seems to me that
it'll be more consistent & intuitive,  that if a user can block a site one way,
he/she ought to be able to unblock it a similar fashion.  It doesn't seem to me
that would be too much additional code over 'indicator for blocked cookies
only', but I'm not the coder.
Sometimes it is useful; for example, I am a developer of forum software.  There
are always some users having cookie issues - and the first thing I have to check
is whether the server is sending the Set-Cookie header on login or not.

The problem is that this is still a specialty feature; it fits more for the "Web
Developer" extension, etc. than for general use.

As "scary" as some people think cookies are.. (I've even seen documentaries
making them out to be the devil's tool or something!) the fact is that, in most
cases, for most users, cookies should always be accepted.  Showing the icon when
cookies are being set has one major disadvantage: it makes people with paranoia
problems get scared that they must be getting "tracked".

Cookies are your friend.  While an indicator for when cookies have been blocked
- for whatever reason, from the wrong domain etc. - would be useful, only the
bare minimum would be helpful to most end users.

Being someone who has to deal with people paranoid about cookies, I would
actually prefer that this bug do only what it was meant to do; tell you if
cookies were blocked.  Even maybe have a popup the first time, like for popup
blocking.

-[Unknown]
Just as an FYI to those concerned, this can't be fixed for 1.0 because the
current notifications setup is insufficient to make this work "right" and will
not be changed on 1.7 branch.

*** Bug 288547 has been marked as a duplicate of this bug. ***
Until a status bar indicator for cookie settings is included, a useful
extension, called 'Permit Cookies' -- which allows a user to enable/disable
cookies/session cookies for the current site by pressing Alt+C, or clicking on
an optional toolbar button -- can be found at http://mfe.gorgias.de/
Blocks: majorbugs
No longer blocks: majorbugs
QA Contact: davidpjames → location.bar
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
QA Contact: location.bar → general
Blocks: 245159
Blocks: 255199
https://addons.mozilla.org/en-US/firefox/addon/1328 does pretty much what this bug asks for.
The CookieSafe extension, which is currently maintained, also does what this bug asks for. It's at https://addons.mozilla.org/en-US/firefox/addon/2497  Personally, I think this bug should be closed with a status like USE_EXTENSION.
(In reply to Seth W. Klein from comment #32)
> The CookieSafe extension, which is currently maintained, also does what this
> bug asks for. It's at https://addons.mozilla.org/en-US/firefox/addon/2497 
> Personally, I think this bug should be closed with a status like
> USE_EXTENSION.

I concur!
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.