Fx 2.0 / Cookies management

HorseDrawnZepplin · November 5th, 2006, 8:55 pm

I would like to propose that a whole lot of options be added with nice titles like 'improve browsing speed', 'extra security enabled' and 'spam protect'.

They would, of course, do nothing, but should make lots of people very happy.

WulfTheSaxon · Post by **WulfTheSaxon** » November 8th, 2006, 12:30 am

I really wish it was still in the GUI...

In the meantime, it's just causing more confusion, because if you had previously set it to block 3rd party cookies before Fx 2, the setting remains at 1, but the GUI to change it back is gone. I can see an average user getting quite confused by that.

Athan · Post by **Athan** » November 9th, 2006, 11:13 am

At the very, very least about:config needs to have a 'help' option on right click of an entry. Not everyone thinks to google, or search the mozilla knowledgebase directly, to find out what options do, or which option does what they want.

But, as this whole thread has been saying, stop taking options OUT of the Firefox GUI. Put them on some 'Advanced' tab if you must, but leave them in the GUI config please.

-Ath, who was VERY annoyed about default TAB scrolling and close button behaviour when first switching to FF2.0

the-edmeister · Post by **the-edmeister** » November 11th, 2006, 12:58 am

At the very, very least about:config needs to have a 'help' option on right click of an entry.

That would add a ton of bloat! And what about preferences added by an extension? If a user doesn't know how and where to search for info about what a preference does, maybe they shouldn't be in about:config to begin with.

Mozcricket · Post by **Mozcricket** » November 11th, 2006, 1:12 am

Why has Firefox removed the ability to disable 3rd party cookies in F.F.2.0 ? As a browser that likes to trumpet the fact that it is more secure than I.E. then why on earth would they give ammunition to the enemy.This is a standard feature in I.E.. Right away I start thinking they don't want users to disable them for corporate interest ie: Search bars, and it makes me uncomfortable. Most people concerned with privacy would rather disable all 3rd party cookies and then enable individually as desired, or at least give us that option. The new way is enable everything (all cookies) and then ban the sites on a one by one basis.

Steve Gibson of <a href="http://www.grc.com/default.htm">grc.com</a> talked unfavorably about this new feature on <a href="http://www.grc.com/SecurityNow.htm#64">podcast #64</a> of his "Security Now" page and will be talking more about cookies in future episodes. 100,000+ and growing each week listen to and hang on every word he says on his pod-casts, and over 46 million people have hit his site since it's inception. This is one guy you don't want dissing Firefox. For those of you who don't know Steve is a very large voice in the security culture of the net and is responsible for a lot of the terminology and acronyms floating around. He has shone the light on a multitude of M.S. security flaws so brightly that even the all powerful M.S. has had to concede...at times. Him and Leo Leport ,the Host who also links this pod-cast on the very popular site <a href="http://www.thisweekintech.com">This Week in Tech</a>, command a very large audience and I would hate to see them influence the growth of Firefox for such a simple change.

Most people probably never bother with third party cookies and just accept them; but for the few who take privacy seriously I would urge people to request that this feature be reinstalled if not for the perceived threat alone. I think this simple change will be used by Firefox detractors for the rest of it's life until it's changed back. Let's not give them the ammunition.

old zeniko · Post by **old zeniko** » November 11th, 2006, 1:41 am

Mozcricket wrote:Why has Firefox removed the ability to disable 3rd party cookies in F.F.2.0 ?

<a href="http://forums.mozillazine.org/viewtopic.php?p=2526468#2526468">Above</a>, chob wrote:
<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=349680#c14">Mike Connor in bug 349680 comment 14</a> wrote:As dveditz noted in Bug 324397, this option doesn't really work due to iframes/redirects, and the methods they're using can't effectively be stopped without breaking the web in general. We've been through this before, and there really isn't a good way to make this effective.

As much as it would be nice to have it just work, it doesn't, and there's unfixable ways around it, so the UI is either pointless (barely works) or damaging (users perceive the app as broken).

Athan · Post by **Athan** » November 11th, 2006, 9:03 am

the-edmeister wrote:
At the very, very least about:config needs to have a 'help' option on right click of an entry.
That would add a ton of bloat! And what about preferences added by an extension? If a user doesn't know how and where to search for info about what a preference does, maybe they shouldn't be in about:config to begin with.

And yet that is the very recommendation for people when they 'lose' an option that used to be in the GUI config screens.

Note that I personally am tech-savvy enough to work these things out. I did indeed google and find the information in the knowledgebase.

Ok, how about a compromise, a single big 'Help' button up on that 'Filter' line that opens a new tab/window to the about:config bit of the knowledgebase ? Oh and note that the Right-Click -> Help -> Knowledgebase URL option wouldn't bloat at all, as all such URLs seem to simply be http://kb.mozillazine.org/<name>

-Ath

old zeniko · Post by **old zeniko** » November 11th, 2006, 9:39 am

Athan wrote:And yet that is the very recommendation for people when they 'lose' an option that used to be in the GUI config screens.

Which is quite unfortunate. about:config shouldn't be used as an excuse for bad planning... In fact, people not knowing how to deal with about:config should rather get an extension to do the job for them so they don't accidentally break things (the same advice should also be for the Windows registry and other configuration hives).

And yet that's at least the second time that UI has been removed with no way of resetting the corresponding prefs to the expected default values (for Firefox 1.5, one pref for disallowing extension installation was removed, now prefs for 3rd party cookies and for image zooming).

Still, I doubt that the Firefox devs would approve of any such change to about:config (in a similar way as they won't allow any changes to the Profiles manager, either, since that's not supposed to be seen by "the user" as well). They'd rather ignore the facts and recommend you to use the Preferential extension or something more specific.

IMHO the solution for these cases should be to (1) get an additional code-review requirement for such UI changes to make sure this doesn't happen a third time and to (2) offer an official extension to reset these specific prefs to their default where users can be pointed to (instead of just hinting at a pref name in the release notes).

casey1992 · Post by **casey1992** » November 12th, 2006, 5:28 pm

Athan wrote:Ok, how about a compromise, a single big 'Help' button up on that 'Filter' line that opens a new tab/window to the about:config bit of the knowledgebase ? Oh and note that the Right-Click -> Help -> Knowledgebase URL option wouldn't bloat at all, as all such URLs seem to simply be http://kb.mozillazine.org/<name>

Some kind of help would be cool, but it's probably not a good idea to have it lead to a link not maintained by Mozilla.

casey1992 · Post by **casey1992** » November 12th, 2006, 5:28 pm

Athan wrote:Ok, how about a compromise, a single big 'Help' button up on that 'Filter' line that opens a new tab/window to the about:config bit of the knowledgebase ? Oh and note that the Right-Click -> Help -> Knowledgebase URL option wouldn't bloat at all, as all such URLs seem to simply be http://kb.mozillazine.org/<name>

Some kind of help would be cool, but it's probably not a good idea to have it link to a page not maintained by Mozilla.

xformerfhs · Post by **xformerfhs** » November 14th, 2006, 3:30 am

Hello,

I never liked this "temp change" thing in FF1.5 cookie management and I understand that it is a good idea to remove options that cause confusion. I also understand that it is a good idea to disable 3rd party cookies. OK.

However, I would really liek to have the following:

- I open the cooky list
- I see a cooky I don't want (e.g. google.com)
- I select the cooky
- I press the button "Delete & block cooky"

This is easy, understandable and does not lead to confusion, does it? The change does not need to be temporary, it should take effect immediately.

Regards,
Frank

Havin_it · Post by **Havin_it** » November 18th, 2006, 6:52 am

I'm not sure which is worse: having a poor-privacy default and burying the option for non-expert users, or the revelation that "it never really worked in the first place". This is a real slap in the face for Firefox's reputation IMHO.

Nobody has actually explained WHY third-party blocking is so easily circumvented by sites. "Frames and redirecting" is mentioned, but how about some detail here?

Okay, frames is understandable: an ad-page in an iframe sets a cookie, which is not treated as "third-party" because it's from a site that is indeed loaded in your browser. But how hard can it be to tell Firefox (as an option, but preferably a default one): "Only let the top-level document set cookies"? I'm pretty sure this would be practically a one-liner of code, and would wipe out a massive amount of offending third-party cookies. There can't be many examples of well-meaning sites that would be damaged by it, I would have thought, and anyway such sites could notify their users in the same way

On the other hand, I confess to having no clue how "redirects" can banjax cookie-control safeguards, and I would like it very much if someone can explain what this means and how the exploit works. (Only then can I knock it down!)

Something about this issue smacks of collective (and long-standing) apathy to me. How often do you hear of such a large security/privacy flaw being apparently ignored for such a long period of time by an open-source dev community? Very out-of-character and VERY unsettling.

casey1992 · Post by **casey1992** » November 18th, 2006, 7:05 am

As an example, apparently <a href="http://kb.mozillazine.org/Pogo.com">Pogo.com can break</a> without accepting third party cookies.

WulfTheSaxon · Post by **WulfTheSaxon** » November 18th, 2006, 11:49 am

Havin_it wrote:On the other hand, I confess to having no clue how "redirects" can banjax cookie-control safeguards, and I would like it very much if someone can explain what this means and how the exploit works. (Only then can I knock it down!)

I imagine a site could make, for example, their homepage link point to an external site that sets a cookie and then redirects to their homepage without the user ever seeing it.

I'll save you the trouble of shooting it down:

It could be easily addressed by setting a minimum redirect time of, say, 3 seconds for sites that set cookies. Then, at least the user would realize that they had been at the site and could've gotten a cookie from there.

Besides, according to statements made by Mozilla regarding past security bugs in Firefox, if a site has to trick a user into performing an action to take advantage of a hole, it really isn't very critical.

Havin_it · Post by **Havin_it** » November 19th, 2006, 8:12 am

WulfTheSaxon wrote:I imagine a site could make, for example, their homepage link point to an external site that sets a cookie and then redirects to their homepage without the user ever seeing it.

It's hard to imagine many sites doing this. It would kill their PageRank stone dead, for a start. It seems a very tortuous method of tracking compared to the iframe method... Also if cookie-acceptance is set to "prompt" then you'd immediately see the cookie-pushing domain wasn't the one you expected.

WulfTheSaxon wrote:Besides, according to statements made by Mozilla regarding past security bugs in Firefox, if a site has to trick a user into performing an action to take advantage of a hole, it really isn't very critical.

Sorry, I don't follow how this relates to the discussion? What is the user being tricked into doing, and in what context?