648609 - Firefox can be "blocked" by sending lots of cookies

Status: RESOLVED DUPLICATE of bug 430006

(Firefox :: General, enhancement)

Description

[Christian Boltz]

User-Agent:       Mozilla/5.0 (compatible; Konqueror/4.6; Linux; X11; de) KHTML/4.6.0 (like Gecko) SUSE
Build Identifier: Firefox 4.0 for openSUSE 11.4

(initially reported as https://bugzilla.novell.com/show_bug.cgi?id=408545)

Firefox can be "blocked" by sending lots of cookies. Not in the technical
sence, but it's like a DoS for the user.

Reproducer:
- go to the preferences dialog. In the privacy tab, enable "accept coocies"
  and set the "keep until" dropdown to "always ask"
  [wording might differ, I'm using the german version]
- open http://www.derwesten.de

[ If you want to exacerbate someone, send him the above reproducer without the 
  following text ;-) ]

Opening the page sends 75 cookies at once (!). Combined with the setting to ask
for confirmation for every cookie, Firefox opens 75 dialogs asking if I want to
accept the cookie.

Having to click 75 times is very annoying, I decided to use xkill instead.
Unfortunately "remote-kill [e-mail]" didn't work ;-))


Better solutions for the cookie dialog would be:
a) "collect" all cookie requests and combine them to one dialog:
       "www.derwesten.de wants to set 75 cookies. Accept?"
b) delay the dialog for the second...75th cookie until the user has decided 
   what to do with the first one. If the user sets a default for the domain 
   after clicking away 5 cookies, the remaining 70 cookies are handled with 
   this behaviour instead of displaying 70 more dialogs.

Reproducible: Always

Comment 1

[George Carstoiu]

Mozilla/5.0 (X11; Linux i686; rv:5.0a2) Gecko/20110417 Firefox/5.0a2

This more of an enhancement request - marking as such.

I find the ideea good. Voting!

Comment 2

[Thomas Ahlblom]

Reproduced (maybe not as much as 75 cookies at the moment, but anyway).
Mozilla/5.0 (X11; Linux x86_64; rv:6.0a1) Gecko/20110515 Firefox/6.0a1

Observation: It's hard to keep track of all cookie pop-ups. Apparently one has to handle them in some kind of order and it's hard to find out which pop-up is blocking at the moment.

I can see some problems with the suggested enhancement:
* Most of the cookies are third-party cookies.
* The cookies are not issued at exactly the same time. How long should the dialog wait before handling them as a batch and what to to with already issued pop-ups? Or should the dialog always be updated incrementally, with no pop-ups at all? Then one will lose the opportunity to inspect each and every cookie.

Comment 3

[Christian Boltz]

I agree delaying the popup doesn't sound like a good idea, and updating an open dialog might also be a problem because the user might accept or deny more cookies than he initially wanted (it's just a race condition between reading and clicking the button ;-)

What about my proposal b) from the initial report? Basically:
1. display the dialog for the first cookie (as soon as it arrives)
2. do NOT open additional cookie dialogs as long as the first one is open
3. collect/queue other cookies in bckground
4. after the user closed the (first) cookie dialog, open another cookie dialog
   for all cookies that arrived until then
5. if more cookies arrive, GOTO 2.

Comment 4

[Johannes Rohr]

(In reply to comment #1)
> Mozilla/5.0 (X11; Linux i686; rv:5.0a2) Gecko/20110417 Firefox/5.0a2
> 
> This more of an enhancement request - marking as such.

At least on Linux this is not merely an enhancement request, but it is definitely a bug to be fixed. 

There are many sites out there, which send tons of cookies, resulting in a stack of confirmation dialogues popping up. I often see situations, where the topmost popup dialogue does not react because some other cookie dialogue  needs to be clicked first. I.e. the currently active one is not necessarily on top, and unless you identify which one is next in line to be clicked, there is no way of continuing to browse short of killing firefox altogether. 

So it should at least be ensured, that the popups are presented in the correct order and that the one which needs to be clicked next is the one which is actually on top.

Comment 5

[Olivier Mehani [:shtrom]]

Same problem here (Various Linux distros and OpenBSD, FVWM and GNOME). Sometimes, the dialog appears on other desktops, or under other windows, making them quite hard to hunt down, and until when Firefox appears completely frozen.

Maybe be these cookies don't deserve a dialog each, but instead should be attached to the *page*'s awesome bar (and no longer block further loading) just like  more and more metadata for the page (and all the dependent sites from which content is loaded) already are.

See the attached mockup (quite similar to the current cookie manager for the basics) where 
1) All of example.com's cookies are accepted;
2) Only session cookies for login.net are accepted (note the tristate chekbox for the site “folder”);
3) There is no site-wide policy for sistersite.com (note the greyed out checkbox for the folder);
4) All cookies for ad.com are blocked.

This would also make cookies more easily manageable rather than the current “Favicon>More information>Permissions>Set cookies” technique which is needed for some sites which require their seemingly useless cookies to be accepted.

(Also, bug 516224 seems quite similar to this one.)

Comment 6

[Olivier Mehani [:shtrom]]

Attachment: Mockup for a new cookie acceptation dialog replacing the current one-dialog-per-cookie UI.

Comment 8

[S A]

I think this is related to bug 430006 and its other dupes such as 597325.

https://bugzilla.mozilla.org/show_bug.cgi?id=430006
https://bugzilla.mozilla.org/show_bug.cgi?id=597325

Comment 9

[S A]

Still going on in 8.0.1 - the behavior of the check box isn't being respected.  Just trying to go to someone's tech blog yesterday took my whole browser down because the site sent so many cookie requests.

Comment 10

[Thomas Ahlblom]

Duplicating against bug 430006 since it's almost the same issue.

Comment 11

[John Smith]

It's ridiculous this bug has persisted for nearly a decade.  I actually STOPPED using Firefox two years ago because I got tired of this bug on my Mac.  I now use Chrome as my only web browser.  This is ridiculous.  It's a shame, because I really really really wanted to support Mozilla, but this bug rendered the browser totally unusable on my Mac.