417800 - Revert to not blocking third-party cookies (was: 3rd party cookies should be *sent* even when blocked from being *set*)

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect, P2)

Description

[mdawaffe]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9b3) Gecko/2008020511 Firefox/3.0b3

Cookie sets should not be accepted from third party sites, but cookies should still be *sent* to third party sites.

Bug 324397 was closed by changing the default of network.cookies.cookieBehavior from 0 to 1.  Now Third party cookies cannot be set (e.g. within an iframe).  I understand and support this behavior.

However, pre-existing cookies for that third party are not currently *sent* to that third party.  I believe this behavior is incorrect and is an unintended consequence of changing the default "accept cookie sets from third party sites" behavior.

Reproducible: Always

Steps to Reproduce:
1. User goes to example.com and logs in to that site.  example.com cookie is set.
2. User goes to a different site: example.NET which contains a "widget" for example.com: an iframe showing example.com content to logged in users.
Actual Results:  
Since Firefox 3b3 does not send pre-existing cookies to third party sites, that example.com widget does not work from example.net.

Expected Results:  
Firefox should send third party cookies so that the example.com widget works.

Related bugs:
1. Bug 324397: deals with accepting cookie sets from third party sites.
2. Bug 417286: deals with UI for allowing cookie sets from a whitelist of third party sites.

Comment 1

[Jo Hermans]

The example.com widget (let's say an advertisement) is telling its home server that a certain event occurred on example.net. Isn't the whole purpose that this potential privacy leak is stopped ? As a user, I never gave permission to example.com to do this. Yes, it's less severe than the old way (you can't set the cookie anymore), but the privacy leak is still there. example.com is still tracking your surfing habits.

(I know there are also ways around this, but that's not the point)

Comment 2

[mdawaffe]

You *did* give example.com the permission to do this.  You logged into example.com.  See "Steps to Reproduce" in original report.  There's no privacy issue (that I can see) since you clearly trust example.com.

Let me clarify:  I am in no way suggesting that example.NET cookies be sent to example.COM.  Only that example.COM cookies be sent to example.COM when example.COM is loaded in an iframe on a page on example.NET.

As an aside, the same issue holds not just for external iframes, but for any external content (e.g. images).

Comment 3

[Jo Hermans]

(In reply to comment #2)
> You *did* give example.com the permission to do this.  You logged into
> example.com.  See "Steps to Reproduce" in original report.  There's no privacy
> issue (that I can see) since you clearly trust example.com.

No, I did not. example.com has set a cookie, because I just happened to be on its website. I did not give permission or log in or something. I just happened to be on that website.

To give an easier example (all resemblance to an existing Internet giant is coincidence obviously) : just because I happened to use searchengine.com for something (search engine, maps, mail, ...), a cookie was set. But that same cookie is still accessible by an iframe on another website (let's say somepornsite.comr whatever), and you still want it to be sent to searchengine.com ? That site can (and will) use that cookie to identify me! At what point did I give permission to searchengine.com to do that ?

Your proposal would be reverting the decision, so that the tracking cookies can be used again.

Comment 4

[mdawaffe]

I don't believe my proposal would revert the earlier decision to not accept third party cookies.  I think my proposal lies between two extremes:  never doing anything with 3rd party cookies (current behavior), and allowing anything with 3rd party cookies (old behavior).

The fact is, you did display trust of example.com by going to their site.  I understand that the trust of going to a site is *totally* different than the trust of allowing a site to receive 3rd party cookies from you, but it is some level of trust.

Contrast that to third party cookies sent to a site you've never been too.  In that situation, you never showed any level of trust to that site.  In my proposal, such a site would never have had the opportunity to set a cookie and so would never receive 3rd party cookies from you.  But sites you have trusted at least enough to visit would receive any 3rd party cookies they set while you were at that site.

It's not perfect, but neither is the old or current behavior.

Here's a concrete example of a site broken by the current behavior.

WordPress.com blogs serve images from someblog.files.wordpress.com and use a .wordpress.com cookie to make sure that you are allowed to see any private images.  If "someblog" is a has a non-WordPress.com domain (say someblog.com), the "third party" cookie is not sent and the images don't display.  (Full disclosure: I work for the company behind WordPress.com.)

I will look around for other "legit" examples, as I'm sure they exist.

Comment 5

[Jesse Ruderman]

> The fact is, you did display trust of example.com by going to their site.

If you've used PayPal recently, you've been to doubleclick.  See http://www.grc.com/securitynow.htm#119.

Comment 6

[Matthew Mullenweg]

The advertisers have and will just move on to other methods of tracking like flash cookies, redirects, or Etags. Visit here:

http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager06.html

Even if you clear cookies and block third party cookies, you'll still likely see pagead2.googlesyndication.com there.

That's not really the issue though.

Good guys, normal widgets, and many sites use iframes to tie distinct sites together are being punished by behaviour that changed from b2 to b3 and there is no good guy workaround for. The new stats widget in 2.5 shows a beautiful iframe-loaded flash graph in IE6+, Safari, and Firefox through 3b2, but now in b3 it shows a login form. Even if I submit the login and get new cookies (although they already exist), if I navigate away from the page or reload it wants me to login again. (And again.)

I'm most familiar with how this breaks things around WordPress because that's what I work with every day inside of Firefox, but would it help to find other examples of widgets or functionality broken by this change in b3?

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

At the very least, we need to revert the change from bug 324397. The foundational assumptions in that bug (that this wouldn't affect web-compat) turned out to be wrong.

At the most, we need to reintroduce the UI, but that's a late string hit.

Comment 8

[Daniel Veditz [:dveditz]]

Mozilla has had a "3rd-party cookie blocking" feature since forever, and it has
always meant to block cookies full stop. It was never the default, however, and
since most people never set that pref the UI for it was removed in an earlier
version (we figured the people who were that interested in cookie management
probably used one of the cookie-related addons anyway).

We caught some flack for that ("Mozilla is in the pocket of an unnamed search
giant who wants to track you everywhere"), and so when we noticed that both IE7
and Safari now default to "blocking" 3rd party cookies we thought we could do
the same. We just recently found out that Safari's idea of blocking is the
half-assed blocking requested in this bug. IE probably is doing the same given
the sites that have broken in FF3b3 due to this -- IE can't be doing what we're
doing. I doubt that's what their users think is happening based on the wording
of their UI.

In Mozilla if 3rd party cookies are blocked you can explicitly allow them for
particular sites you need to work by adding that site to the cookie exception
list. If a site is explicitly "Allowed" then it can always read and set cookies
regardless of other settings (either the "no 3rd party" or even the "no cookies
at all" settings). That will make your widgets work (but your general users are unlikely to figure that out).

Because of the problems we've been talking about reverting to the FF2 cookie
behavior (as Mike mentions). If we added a half-blocked option we could make that the default instead, and leave the full blocking in as an option for the hardcore privacy people.

Comment 9

[mdawaffe]

(In reply to comment #5)
> If you've used PayPal recently, you've been to doubleclick.  See
> http://www.grc.com/securitynow.htm#119.

I think the insecurity (or untrustworthiness if you prefer) of first party cookies is a different issue.

We can brainstorm all kinds of crazy ideas about when to send third party cookies back out from the client: Look at P3P headers; only send the cookie if it was set as a first party cookie as a result of a traditional (i.e. non-JS non-flash non-whatever initiated) POST request; ...

I'm sure anything I could think of would all be easily circumvented by advertisers and other "malicious" trackers and would probably break as many things as it'd "fix" (both in FF and in the web).

As mentioned above, Bug 324397 comment #39 says the change in that bug brings FF in line with Safari and IE.  I have Safari set to accept cookies "Only from sites you navigate to (for example, not from advertisers on those sites)".  With that setting, once logged in at http://wordpress.com/ (Set-Cookie accompanied by P3P), .wordpress.com cookies are sent in image requests on privateblog.com to privateblog.files.wordpress.com and in iframe requests on comp.local to subdomain.wordpress.com.

Safari also sends .wordpress.com cookies in both of those scenarios when I log into WordPress.com from an "third party" iframe on comp.local (again Set-Cookie accompanied by P3P).

So I have no idea what Safari means by that deceptive quoted phrase, but Safari's behavior is not the same as FF's (which sends no .wordpress.com cookies in either of those scanarios).  Which behavior is actually better is what we're discussing I suppose :)

I haven't looked in detail at the request/response headers when using IE, but I trust comment #6.

Comment 10

[Jo Hermans]

Note that you can permission to wordpress.com to set 3th party cookies, to adding it to the Option->Privacy->Exceptions dialog box and setting it to 'allow'.

Comment 11

[[e-mail]]

(In reply to comment #9)
> As mentioned above, Bug 324397 comment #39 says the change in that bug brings
> FF in line with Safari and IE.

it turns out bug 324397 comment 39 isn't accurate. to help clear up all the confusion around this issue, i've posted comparisons between FF, Safari, IE6, and IE7 in bug 417286 comment 14. to summarize:

1) IE6, IE7, and Safari 3's third-party blocking works only when setting cookies. once a cookie is set, it can be read third-party or not. our feature has always blocked setting and reading.

2) IE6 and IE7 (at least) can use the p3p policy to determine whether to permit setting of a third-party cookie. per comment 9, it appears that Safari can also do this, though i haven't verified that.

3) all browsers have the ability to block third party cookies in iframes.

the debate about what to do here can be considerably simplified by presenting the design decisions we've made along the road to where we are now:

a) blocking only setting, and not reading, of third party cookies is indeed half-assed - there are plenty of ways you can get cookies to various sites, and the fact that you have them doesn't mean you want to send them for every unrelated site you visit. having a feature like this that purports to block third party cookies is misleading, and i don't support us doing it, regardless of what the competition does.

b) the ability to make decisions based on p3p policies was removed for firefox 3, because p3p isn't an effective way to establish trust with a site. it's a one-way system; anyone can say they're the good guy.

c) a common argument against third party blocking is that "it can never be done right"; and it's true. however, it's not an argument against trying. for instance, controlling flash cookies is a worthy cause (bug 290456), and redirects involve latency and thus there's a price for using them.

in the face of the problems this feature has caused, we should revert the default pref, and leave this as an option. since it appears to be reasonably effective (at least moreso than the competition), it would be nice to add this back into the pref panel as a choice, rather than keeping it hidden - but that's an l10n call for drivers to make. people who want this should use it in conjunction with whitelisting for legitimate sites. (given the amount of confusion around whitelisting, better discoverability of this feature seems necessary - but that's a different topic.)

Comment 12

[[e-mail]]

Attachment: revert the pref

Comment 13

[[e-mail]]

as a followup to a) above, since IE and Safari block setting of third party cookies by default, i wouldn't be averse to mimicking that - provided we don't call it third party blocking. (we could just do that for "accept all", though that might cause problems too - and having two prefs for third party blocking would be confusing.)

Comment 14

[Reed Loden [:reed]]

Checking in browser/components/preferences/privacy.js;
/cvsroot/mozilla/browser/components/preferences/privacy.js,v  <--  privacy.js
new revision: 1.25; previous revision: 1.24
done
Checking in browser/app/profile/firefox.js;
/cvsroot/mozilla/browser/app/profile/firefox.js,v  <--  firefox.js
new revision: 1.284; previous revision: 1.283
done

Comment 15

[[e-mail]]

filed bug 419596 on adding this back to the pref UI as an option.

Comment 17

[[e-mail]]

bug 421682 notes that this feature breaks some facebook apps that use third party iframes.

Comment 18

[Luke Shepard]

Facebook Connect is a product that relies on reading third-party cookies (from facebook.com) in an iframe. It does not work for Firefox users with this setting configured. It does work for IE7, IE6, and Safari:
http://bugs.developers.facebook.com/show_bug.cgi?id=3447

I saw that this ticket was resolved; sorry if I'm new to the Mozilla bug queue, but what was the resolution? One of the other tickets implied that it was reverted; if so, when can we expect the reversion to be released?

Comment 19

[Daniel Veditz [:dveditz]]

This ticket was resolved as "don't block 3rd party cookies by default", it did not change our behavior when we do block 3rd party cookies.

We're pretty much not happy with the way Safari and now IE have implemented this feature, which deviated from the way Mozilla and Netscape have always done it. 3rd party cookie blocking is for privacy (anti-tracking) reasons, and sending them when set is a hole big enough to drive a truck through since it's trivial to redirect through your tracking ad-server to set a first-party cookie. Sites actually do this. If we block redirect 1st-party cookies then we break single-signon type applications.

Comment 20

[Luke Shepard]

I see, so all that has changed is the default option. For users that explicitly uncheck "Accept third-party cookies", Firefox will still neither accept nor send cookies from third-party sites.

I'm curious, what do you think is the right solution to enable Facebook Connect, OpenID, and other single-signon type applications, given the restriction that the browser shouldn't send cookies to a third-party site in an iframe?

(Also, since a resolved bug probably isn't the right place for this, where would you suggest is the best forum to raise these issues?)

Comment 21

[Chris Lawson (gone)]

(In reply to comment #20)
> I see, so all that has changed is the default option. For users that explicitly
> uncheck "Accept third-party cookies", Firefox will still neither accept nor
> send cookies from third-party sites.

Isn't that exactly the point of that setting?

If there are sites or add-ons that plainly require third-party cookies to be accepted, and users deny third-party cookies, I'm not quite sure what they would *expect* to happen other than that third-party functionality breaking.

> (Also, since a resolved bug probably isn't the right place for this, where
> would you suggest is the best forum to raise these issues?)

Probably in the newsgroup.

Comment 22

[Eddy Nigg (StartCom)]

Just for the record, OpenID does NOT require third party cookies to be set! Most currently available open source libraries for OpenID don't require it either. It's a specific problem of Facebook and perhaps RPX.

Comment 23

[Luke Shepard]

Eddy- thanks for pointing that out. It's true that if an OpenID relying party uses full-page redirects or browser popups for auth then this has no impact. And Facebook Connect also works fine under those restrictions.

However, a site that wished to do an OpenID checkid_immediate request in an iframe would be unable to do so without reading third-party cookies. Similarly, the Facebook Connect use case that breaks is the ability to read logged-in status in the background while on a remote site.

In any case, I understand where we are currently at - thanks for the explanation Daniel and Chris. I'll search for the Mozilla newsgroups to continue the discussion.

Comment 24

[[e-mail]]

i'd also note that there's a simple workaround here - just whitelist ("allow cookies from this site") the openid host. it'll bypass third party prefs and work inside any iframe or third party context.

Comment 25

[Dão Gottwald [:dao]]

(In reply to comment #13)
> as a followup to a) above, since IE and Safari block setting of third party
> cookies by default, i wouldn't be averse to mimicking that - provided we don't
> call it third party blocking. (we could just do that for "accept all", though
> that might cause problems too - and having two prefs for third party blocking
> would be confusing.)

Do we have a bug on that?

Comment 26

[[e-mail]]

Nope. I think we can come up with some smarter solutions that give us proper 3rd party blocking but don't break as much. Needs more thinking.