324397 - Third-party cookies should be blocked by default (flip the hidden pref)

Status: RESOLVED WONTFIX

(Firefox :: Settings UI, enhancement)

Description

[bugzilla]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

"Allow sites to set cookies for the original site only" should be selected by default. There are almost no 'legitimate' uses of third-party cookies. 

Reproducible: Always

Comment 1

[Daniel Veditz [:dveditz]]

While I agree, and have my own preferences set that way, in practice it doesn't help all that much. Advertisers have long gotten around this through redirects and hosting ads in frames. You can easily test this by setting the "no 3rd party" pref and the "ask me about cookies" pref and see all the requests you get for advertizer's cookies anyway. Or just check your cookies and see all the advertisers in there that you have never directly visited.

Withholding cookies during redirects or from frames breaks lots of legit sites, so the "no 3rd party cookies" option is mostly a feel-good measure but doesn't accomplish much.

Comment 2

[Rick Stockton]

I understand your point, *BUT*

(1) If it's a legit site which really becomes unreadable by disabling 3rd party cookies, and I REALLY want to see it, I should be able to temporarily flick the pref to "allow", reload the page, and then flip it back after I'm done with that Site. Obviously, hand-editing in 'about:config' is a real slow way to do this.

(An "allow/disallow 3rd party cookies" button which I could drag into the toolbar via "customize" button would be great for FF3!!!)

Is Gecko unable to understand that the advert./phishing frame is merely a "child" of the different Parent site, and enforce the Cookie limitation (must match original Parent) as desired?

Thanks for consideration. I wonder what IE7 plans to do, or how Opera works....

Comment 3

[Jesse Ruderman]

This would make more sense as a site-specific pref than as an easy-to-toggle pref, IMO.

Comment 4

[Rick Stockton]

(In reply to comment #3)

Do you mean site-specific "allow 3rd party cookies from these sites", or do you mean "cookies from these sites are always dis-allowed?"

The latter would result in an awful lot of sites, but could work very nicely if users were able to import/add to their "banned list" from other peoples' giant lists of ad-tracking sites, ala "adblock" filtersets.

(In reply to comment #1)

Daniel, could you list me a couple of pages which 'break' with FF2 (I use nightlies) so I can compare what Konqueror does? Some sites listed in old bugs, such as cnn.com, now set all their adware cookies as site "a.cnn.com", not as completely foreign sites.

Thank you both!

BTW, I'll start using FF3 nightlies AFTER the "places" on/off flipping appears to be resolved.

Comment 5

[Jesse Ruderman]

> Do you mean site-specific "allow 3rd party cookies from these sites", or do you
> mean "cookies from these sites are always dis-allowed?"

I meant the former, although with a good UI framework for site-specific preferences might make it possible for a user to do either.

Comment 6

[Jesse Ruderman]

Rumor has it that IE and Safari block third-party cookies by default.  Do they block third-party cookies for iframes, or just for things like images?  Either way, I think we should match them, at least.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

This morning on Ronn Owens' radio talk show on KGO 810 in San Francisco, Leo LaPorte counseled someone wanting anonymity on the net to turn off third-party cookies.  Then he said IE and Safari do this by default, while Firefox doesn't even let you do it manually anymore.  This was, for him, another reason (the first being reliability) not to use Firefox.

Comment 8

[Jesse Ruderman]

How much of the web breaks when third-party cookies are not sent to iframes?  Depending on how much of the web breaks, it might make sense to re-instate the pref (bug 349680).  I'm not very worried about sites sharing cookies through redirects; that would slow down page loads too much for sites to do it regularly.

Comment 9

[Daniel Veditz [:dveditz]]

I've blocked third party coookies for ten years (ever since I discovered the option in netscape 3 or 4) and have never had a problem.

It's only marginally effective, the ad-servers still get their cookies to you.

Comment 10

[Mike Connor [:mconnor]]

Not a blocker, but we should get a patch in on trunk during the alphas to get wider testing on whether this is actually harmful.

Comment 11

[Arunas B.]

I agree with Daniel Veditz, the blocking of 3rd party cookies makes more privacy, and I also didn't had a problem with this setting. Of course There should be setting from FF1.5 reintroduced, and in FF2 there is already list of sites preference where you can block or allow individual sites.

Comment 12

[Daniel Veditz [:dveditz]]

Attachment: flip the pref: Firefox should disallow 3rd-party cookies

Comment 13

[Mike Connor [:mconnor]]

Comment on attachment 261523 [details] [diff] [review]
flip the pref: Firefox should disallow 3rd-party cookies

I think this is quite sane, and probably not harmful, though as noted elsewhere might do nothing useful as well.

Comment 14

[Mike Connor [:mconnor]]

Comment on attachment 261523 [details] [diff] [review]
flip the pref: Firefox should disallow 3rd-party cookies

I think this is quite sane, and probably not harmful, though as noted elsewhere might do nothing useful as well.

Comment 15

[chris hofmann]

we got beat up on this a bit at defcon, and a presentation that outlines how an attacker can learn quite a bit about your surfing habits by posting a dynamic image at multiple web 2.0 sites were content generation by users is pervasive.

turning off third party cookies provides a few defenses against privicy and possible security problems outlined in 
http://people.mozilla.com/~chofmann/security/dc-14-schrenk.pdf

other browsers still surface UI to control 3rd part cookies but Firefox doesn't except buried in about:config.  that point was made during the talk.

Comment 16

[Jesse Ruderman]

Preventing sites from finding out which other sites you visit would require changing a lot more than this cookie pref.  For example, it would require fixing bug 147777.

Comment 17

[Mike Connor [:mconnor]]

dveditz, were you going to land this?

Comment 18

[Nickolay_Ponomarev]

mozilla/browser/app/profile/firefox.js  1.198

Comment 19

[Nickolay_Ponomarev]

Weird, but This caused orange bm-xserve08. I backed it out.

Comment 20

[Nickolay_Ponomarev]

Also A went from ~491K to ~505K on bm-xserve11 (mac too).

Comment 21

[Daniel Veditz [:dveditz]]

Do you know which tests broke, or better, why?

The nsCookieService::IsForeign() check seems to do a lot of extra work. We could maybe save on some of the allocs if we first checked for equal hosts so that the wanted case bails out quickly.

Comment 22

[Nickolay_Ponomarev]

The tinderbox output is pretty cryptic:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1188748860.1188750214.5914.gz&fulltext=1

LayoutPerformanceTest: firefox-bin successfully stayed up for 300 seconds.
TinderboxPrint:Tp:[CRASH]
LayoutPerformanceTest: test failed

My interpretation is that it crashed, hanged (perhaps waiting for the user), or just took longer than expected to complete the tp tests.

Comment 23

[chris hofmann]

interesting that safari 3 for windows has UI for controling this and they also set the default to disallow third pary cookies.

preferences | security

Accept Cookies:

   o always
   o never
   * Only from sites you navigate to
      For example, not from advertisers on those sites

Can we put adding this UI on the table?

Comment 24

[Mike Connor [:mconnor]]

Right now, it doesn't do what it says it does, which is why we removed the UI.

We'd like to flip the pref assuming we can make it not regress things.  The other problem is that there's a lot of unblockable ways around first/third party detection, note all of the bugs about how this pref doesn't work as advertised.  We're not going to block on this though.

Comment 25

[[e-mail]]

on irc dveditz mentioned a likely common breakage case with this pref on:

<dveditz> The usual culprit would be sites with a www.foo.com site with a <finances.foo.com> frame -- it's the "same" site, but we don't know that

which can be solved by using etld to find the effective host of both URI's and comparing those. if that's the only breakage case we're really worried about, then we can turn this on by default without much stress.

re the loopholes of 3rd-party frames and redirects; not sure if those can be solved. does anyone know the risk of implementing 3rd-party frame checks, assuming it's possible?

see bug 385299 re using etld in cookies.

Comment 26

[Daniel Veditz [:dveditz]]

could also be done by comparing document.domain of the two to see if they're really cooperative sites, although I bet in most such cases they don't need intra-frame communication beyond domain cookies so they don't bother setting document.domain.

Comment 27

[[e-mail]]

re comment 19, i'm a little shocked this would cause Tp hangs/crashes or the A numbers to go up. i agree with dveditz, we could add a fast path into the IsForeign check, but it's really just a bunch of string compares and shouldn't show up in perf. it could be the PR_StringToNetAddr call showing up, and if that's the case then we need to think about fast paths elsewhere as well. (namely, now that we're moving to eTLD (bug 385299), we should see if the PR_StringToNetAddr is holding things up.)

if there are no objections, i'd like to get a= to land this again on trunk, to make sure the orangeness isn't just a figment of the tinderboxen's imagination. i just find it so unlikely that this could be responsible that i want to make sure of it before i go trying to debug. ;)

Comment 28

[[e-mail]]

Comment on attachment 261523 [details] [diff] [review]
flip the pref: Firefox should disallow 3rd-party cookies

requesting a= for relanding per comment 27. if any kind of perf regression shows up i'll back this out again.

Comment 29

[[e-mail]]

Attachment: tell prefpanel about the change

think we also need this part, if we want the prefpanel to know what's going on.

Comment 30

[Mike Connor [:mconnor]]

Comment on attachment 288798 [details] [diff] [review]
tell prefpanel about the change

yeah, indeed

Comment 31

[[e-mail]]

landed and backed out again. this caused a Tp test crash on bm-xserve08:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1195119540.1195120797.30968.gz

Running LayoutPerformanceTest test ...
Timeout = 300 seconds.
Begin: Thu Nov 15 01:49:54 2007
cmd = /builds/tinderbox/Fx-Trunk/Darwin_8.8.4_Depend/mozilla/../build/universal/dist/Minefield.app/Contents/MacOS/firefox-bin -P default http://pageload.build.mozilla.org/page-loader/loader.pl?delay=1000&nocache=0&maxcyc=4&timeout=30000&auto=1
Process killed. Took 2 seconds to die.
End:   Thu Nov 15 01:54:55 2007
----------- Output from LayoutPerformanceTest ------------- 
----------- End Output from LayoutPerformanceTest --------- 
LayoutPerformanceTest: firefox-bin successfully stayed up for 300 seconds.
TinderboxPrint:Tp:[CRASH]

i thought this might be related to some cookies being rejected, that the Tp test relied on (although i know this shouldn't be the case); so i disabled cookies entirely for a cycle and this box went green again. it could be a legitimate bug in the code, but my money's still on some some weird Tp test thing, because the code in question is well tested (it's been in releases for years!). will look into it further.

fwiw the A stats didn't change, although MH on bm-xserve11 did go down from 19MB to 17MB (and back to 19 when cookies were disabled!), go figure...

Comment 32

[[e-mail]]

if there's some way to get more info (backtrace etc) from bm-xserve08, that might help.

Comment 33

[[e-mail]]

cordoned off the tree, landed again, and investigated the orange for about 5 hours. it turns out it's not crashing, but the Tp test is timing out because of a 400% regression; see bug 404399. we can't land this until that bug is resolved, either by a tinderbox configuration change or an NSPR fix. (adding a fast path, which i'm doing in bug 385299, may hide the issue from sight and allow us to reland but the underlying problem really needs to be resolved.)

Comment 34

[[e-mail]]

relanded with nary a regression. yay!

beltzner, this would be nice to put on the list of changes when b3 is released.

also, to increase visibility of this feature (and possibly give users a way to switch back to 'accept all' behavior), we might want UI for this. having this show as the default when users open their prefpanel would be a big win towards showing we're better at privacy than other browsers. any takers?

FIXED, but feel free to reopen or file a followup for UI

Comment 35

[Stig Nygaard]

Some time ago this setting was causing much confusing and frustrating for me. It was part of the UI back then (Must has been an older Firefox-version).

Suddenly some sites just didn't work anymore, and it took me very long time to find the connection to the "Allow coockies from the original site only" setting. And that is even though I consider myself to be over average in web/technology experience and knowledge.

If this is going to be default there definitely needs to be some kind of a UI to control this, and it got to be called something better. The problem with "Allow cookies from the original site only" is that it sounds like something that should be really fundamental for cookies: Of course only sites setting a cookie should be able to read that cookie again. In the beginning I don't I understood that this actually is about remote objects (ie. images) on a page. The Safari 3 way as quoted in comment #23 is probably much better, though I think it should also be stressed somehow that this is a setting to experiment with if you are having problems on some sites.

Comment 36

[Jesse Ruderman]

Safari's text is also misleading, since cookies are still allowed for third-party iframes, and many advertisers use iframes rather than images.

Comment 37

[Jesse Ruderman]

The frame issue is covered by bug 158463.

Comment 38

[peter]

To the extent wording is an issue, how about "Only allow a page's own site to set cookies from that page".

Also, as a feature request, it would be good if this could be set on a per-domain, per-site, or per-cookie basis in the cookie manager. (perhaps should be in a different bugid?)

Comment 39

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

(In reply to comment #38)
> To the extent wording is an issue, how about "Only allow a page's own site to
> set cookies from that page".

That's not exactly clear, and I'm not sure if it even parses properly. :)

The clearest, most concise way of putting this is: "Allow third-party cookies to be set" and flip the checkbox value. That way, if someone needs this for web compat (comment 35) then they can turn it on.

I don't really buy the argument of comment 34 - we should be better at privacy by being better at privacy, not by having options that show how cool we are and allow people to turn off our functionality when it will likely hurt them to do so. :)

Finally, AIUI, this brings us in line with IE7 and Safari's treatment of third party cookies by default, so web-compat issues should quickly fade away.

Comment 40

[peter]

(In reply to comment #39)
> That's not exactly clear, and I'm not sure if it even parses properly. :)
> 
> The clearest, most concise way of putting this is: "Allow third-party cookies
> to be set" and flip the checkbox value. That way, if someone needs this for web
> compat (comment 35) then they can turn it on.

Regarding wording, the problem is this:  Although "Allow third-party cookies
to be set" would be exactly correct, the average user does not know what a "third party cookie" is.  (And, passive voice is inherently confusing, since it leaves out the agent.)  I suppose that could be remedied with context-sensitive help, but my experience with context help on FF is that it is very weak.  As far as parsing, assuming that was at least a semi-serious comment, it could maybe be improved as "Allow only a page's own site to set cookies from that page".

But my point isn't to push any particular wording, but rather that some of the problems might be mitigated if the wording were *both* accurate and also transparent to the average user.

Comment 41

[David Thomas]

Changing the default behavior mid-release will definitely cause surprises to users. On top of it, if there is no UI to revert back, users will be left without any options. Is it possible to focus this change for a major release and undo this from FF 2.x series?

Comment 42

[Jesse Ruderman]

I don't think this change has been made on the Firefox 2 branch.  I was made on trunk (for Firefox 3), but there's talk of reverting it (see bug 417800).

Comment 43

[Jesse Ruderman]

Reverted in bug 417800.

Comment 44

[War59312]

This needs to be fixed or people are going to start switching to Opera!! Cookie handling in IE7 is broken as well.

So yeah the option is now 1 in FF3 beta 3 but it is useless. Still allowing third party cookies:

http://www.grc.com/siteoptions.htm

Enable third party test and refresh page again and you will see that the third party cookie is still enabled. So delete all cookies and then test and guess what third party cookie is still allowed. :(

Lots of feedback about this on the grc.com newsgroups...

Comment 45

[[e-mail]]

(In reply to comment #44)
> This needs to be fixed or people are going to start switching to Opera!!

we can't enable this by default, because it breaks legitimate sites. we are, however, hoping to include it as an option in the firefox 3 prefpanel.

> So yeah the option is now 1 in FF3 beta 3 but it is useless. Still allowing
> third party cookies:

i'm working on ways to tighten up our third party checking; i'll look into this.

Comment 46

[dan_500]

Applications should ask the user gently for an permission. Enabling Third-party cookies by default is inadequate in terms of privacy.

Comment 47

[Allasom]

(In reply to Dan Witte (:dwitte) (not reading bugmail, email to contact) from comment #45)
> (In reply to comment #44)
> > This needs to be fixed or people are going to start switching to Opera!!
> 
> we can't enable this by default, because it breaks legitimate sites. we are,
> however, hoping to include it as an option in the firefox 3 prefpanel.
> 
> > So yeah the option is now 1 in FF3 beta 3 but it is useless. Still allowing
> > third party cookies:
> 
> i'm working on ways to tighten up our third party checking; i'll look into
> this.

I have yet to find a site that breaks when third-party cookies are denied. An example of such a site would be illuminating.