From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020502 BuildID: 1.0 RC2 If a third-party image is included in a page, then under certain curcumstances, it can set cookies. Specifically, if the (third-party) link is served by a redirect to the actual image, with cookies being set as well, then the cookies will get set, against the users wishes. Note this bug allows people such as clickagents.com to set cookies against the users wishes by having their actual adverts served through redirects. Reproducible: Always Steps to Reproduce: 1. Enable cookies for 'originating site' only 2. go to test url (and possibly reload) Actual Results: The cookie TEST=COOKIE for the site moonraker.ddts.net is set Expected Results: The test cookie should be ignored. e.g. given the following page residing on mozilla-bug.flowerday.cx <html> <body> <img src="http://moonraker.ddts.net/image.cgi"> </body> </html> The GET for http://moonraker.ddts.net/image.cgi returns something like the following (only important lines showed): HTTP/1.1 302 Moved Temporarily Set-Cookie: TEST=COOKIE; path=/ Location: /red.gif This cookie is being set even though it comes from a site that is not the originating one.
Yes, what you are saying is absutely true, and is a well-known flaw in the idea of blocking third-party cookies. The double-clicks of the world are aware of this and have been taking advantage of it for quite a while to set cookies in N4.x (and now in mozilla) in spite of the block-third-party-cookie pref being set. The reason we need to consider a redirect as the original server is because a site could have a bona-fide reason for redirecting. They have changed their server and are doing a redirect for people that access them through the old server. In that case we would be breaking the site if we didn't consider the redirected location as the original server. What you are stating in this bug report is something that I have been saying on my soap box for several years now. Namely the whole idea of blocking third-party cookies is of no practical value. I would have dropped it long ago from the product if it were not for the PR outcry that would result -- "Netscape no longer cares about users privacy!" Therefore I would like to close this bug report out as wont-fix. Not because I don't think there is a problem. But rather because I don't think there is a solution -- whatever we do will either break legitimate sites or will have some other flaw that the doubleclicks will take advantage of. Blocking third-party cookies is something that sounds like a good idea in theory but falls flat on its face when put into practice.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Both RFC 2109 (section 4.3.5) and RFC 2965 (section 3.3.6) explicitly mention redirects as an "unverifiable transaction" that should not be sent cookies. Following this spec might end up breaking legit uses of things like tinyurl, but it would also stop a lot of abuses. Since we already violate the specs by not blocking 3rd party cookies by default there's no excuse not to take a stricter interpretation when users really do want 3rd party cookies blocked.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Summary: third-party cookies allowed when cookie option set to originating server only → redirects can set third-party cookies despite pref setting (violates RFCs)
Assignee: morse → nobody
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: tever → networking.cookies
Bitrot: http://mozilla-bug.flowerday.cx/cookie_bug.html is not currently working: Resolving mozilla-bug.flowerday.cx... failed: Host not found. Too bad Crispin Flowerday is not receiving bug mail. I put the HTML up at http://elvey.com/it/cookie_bug.html, but it still doesn't work because moonraker.ddts.net no longer resolves to a real IP: host moonraker.ddts.net moonraker.ddts.net has address 169.254.0.0 We could use a new example. However, The 4 Stanford authors of http://www2006.org/programme/files/xhtml/3536/index.html conclude: Unless the user is willing to disable all browser features that maintain long-term state, or frequently reset this state, no modern browser can offer meaningful privacy guarantees against cooperative attackers. This seems to support what Morse is saying in Comment #1.
Thanks to chpe, I was pointed back at this bug as my test case wasn't working. I have updated the test case, and the good news is that the bug appears to be fixed from my reading of my original bug report - I'll leave it open for other people to check.
indeed, this bug is actually WFM with our current implementation (quite old now, but post-epoch relative to when this bug was filed!) - yay!
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.