Closed Bug 217199 Opened 17 years ago Closed 7 years ago
Status bar indicator for blocked cookies
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
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.
Should have 4 states No cookies All blocked All allowed Some blocked, some allowed
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.
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.
*** 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/
Assignee: mconnor → nobody
Status: ASSIGNED → NEW
QA Contact: location.bar → general
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: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.