443784 - "Accept third-party cookies" preference is inaccurate, third-party cookies are also not *sent*

Status: UNCONFIRMED

(Firefox :: Settings UI, defect)

Description

[Eric Pederson]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_3; en-us) AppleWebKit/525.18 (KHTML, like Gecko) Version/3.1.1 Safari/525.20
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7 GoogleToolbarFF

Lots of discussion about this in
https://bugzilla.mozilla.org/show_bug.cgi?id=417800
https://bugzilla.mozilla.org/show_bug.cgi?id=419596
https://bugzilla.mozilla.org/show_bug.cgi?id=421494

It seems that the decision was made to NOT emulate the behavior of Safari and IE where 3rd party cookies are not set but they are sent if "Accept third-party cookies" is disabled.      The preference should read "Block third-party cookies" based on the current behavior.

I understand that tracking is evil but sending 3rd party cookies can be very useful for mashups.  I would prefer to have the Safari-like behavior for this reason.   But if it is not to be then the preference copy should get fixed.


Reproducible: Always

Steps to Reproduce:
1. 
2.
3.

Comment 1

[Steve Gibson]

The Mozilla guys have done it correctly, though I agree that the wording on the label of the GUI switch could made more clear.

If you're not going to (optionally) block *both* incoming and outgoing third-party cookies (which would be best) then blocking sending instead of receiving is important because otherwise a cookie can "sneak into" the browser through a first-party channel (like many links on PayPal's site which redirect through DoubleClick.net) and then even though the cookie was received in a first-party context, it will then be SENT in third-party page asset queries ... EVEN THOUGH "Block third-party cookies has been requested in the UI".

Comment 2

[Eric Pederson]

Right, but it should say "Block", not "Accept".   

I understand your issue with tracking cookies "sneaking in".    In those cases the user probably does not know that the cookie is being sent in a third party context.  

However, consider this mashup scenario - sites that you visit have a widget from my site that displays personalized information.   If a user is already logged into my site (say with a persistent cookie) then they would not expect to have to log in again on each visited site to get access to their personalized widget.

The last 2 UIs in https://bugzilla.mozilla.org/show_bug.cgi?id=421494#c22 seem like the next steps.  The last UI may need a little polishing in terms of making the language as accessible as possible.

Comment 3

[Steve Gibson]

Hi Eric,

I see what you mean. The idea is that there *are* instances where you *want* to allow a "cross-context" cookie -- one received in a first-party context that is subsequently returned in third-party contexts.  But there are also times where that's exactly what a user might want to prevent.  sigh.  It's amazing how complex something so simple can be.

Given the fact that BOTH the desired scenario that you described and the undesirable scnerio that I described depend upon *exactly* the same browser behavior, it's clear that no static configuration setting in the browser could satisfy both needs.

It would seem that the only solution would be asking the user to either manually whitelist or blacklist a site's cookies as a means for making an exception to the statically set rule ... and then, for example, allowing an explicitly whitelisted cookie to bypass the block rule.

That way, for example, a site that wanted to maintain a connection with a user while/when they are on another site could mention: "If your browser is set to block third-prty cookies, please whitelist this site's cookies so that we'll be able to extend our services to you while you're visiting other sites."

Comment 4

[Eric Pederson]

I agree, it's definitely a conundrum.   I think you're right, the ultimate solution is to have a really nice and easy to use whitelisting system.   Right now explaining to your average user how to use each browser's whitelisting controls (if even possible) is a pain.   Using first party cookies as proxies is the way I'm dealing with it now.

Comment 5

[Nochum Sossonko [:Natch]]

How about two options, one to accept third-party cookies, one to deny sending third-party cookies, I think that would do it, which is great because whitelist/blacklist sucks as you can see that ff3 removed some of them (addon whitelists etc.)

Comment 6

[Mike Connor [:mconnor]]

There is talk of having an IE/Safari style sending mode, but we haven't figured out the UI treatment yet.  Needs better UI that we were able to implement when we fixed the option, but its worth some cycles when dwitte is done defending for his PhD.

There's a lot of hard tradeoffs that the generic cases don't solve well.  We're thinking about how to solve that better for a follow-on release.

Comment 7

[A. Glez. B.]

Interestingly bugzilla's rembember login won't work with third party cookies disabled.

Comment 8

[scientus]

I cant figure it out, which is the current behavior?

If you visit example.com,(which sets a cookie) and then go a site which embeds example.com, while having the "Accept third-party cookies" option off, does Firefox send that previously set cookie to example.com?

I am of the strong opinion that it should not, but there could be an option over this.

Comment 9

[[e-mail]]

It does not.