Closed Bug 421823 Opened 16 years ago Closed 16 years ago

Cookie blocking non-functional for asset fetches in page headers

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: steve1207, Assigned: dwitte)

References

Details

(Keywords: privacy) 

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461; .NET CLR 1.1.4322; .NET CLR 2.0.50727)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12

Assets fetched from a page's headers, such as FAVICON or Style Sheets, are not being checked against third-party cookie blocking rules.  If the browser has third-party cookies it will include them in requests for header-located page assets.

Reproducible: Always

Steps to Reproduce:
1. Place a third-party asset - a favicon or style sheet - into any page header.
2. If the third-party server is returning cookies with those assets...
3. The browser will, when requesting those assets, IGNORE any cookie rules.
Actual Results:  
Watching the packet flow under Wireshark, the outbound third-party cookies from the browser can be seen.  Similar third-party assets in the main page body, inside the <body> tags, *are* properly blocked ... but not those in the page's header.

Expected Results:  
Clearly, this is a privacy/tracking leak that Firefox doesn't want to have.  The same thing happens in the current betas of FFv3 as well.

I'm sure you already 'get' the nature of the problem.

Thanks for considering fixing it!
This might be a dupe, I think Dan was saying something about having found this a day or two ago on IRC. At least he mentioned the favicon one. <head><style></head>  not obeying the cookie settings is a new one to me.
Assignee: nobody → dwitte
Keywords: privacy
the favicon one will be fixed by bug 421494; leaving this open to check out the css problem.
Steve, do you have a testcase for the specific css case you're referring to? (does http://www.grc.com/siteoptions.htm cover it?)
I'm getting ready to start notifying GRC's visitors when they are surfing with third-party cookies enabled.  That test will eventually be enabled by default, but for now, the notification system needs to be enabled by setting a bit in a persistent cookie, which the SiteOptions page makes easy.

In order to collect the data all of GRC's pages pull a few assets from an affiliated third-party server (www.grctech.com).

Sunday, when I was watching packet traffic under Firefox, I noticed that with third-party cookies blocked, ONLY the favicon.ico (a third-party asset) of several third-party assets on our pages was seeing cookies sent from Firefox.

So, on a hunch that the issue might be the fact that the asset was in the page header, outside the main body, I briefly made our two CSS assets third-party as well, and saw that they, too, were returning the third-party cookie to the server.  So it seemed to me that this was some general-case that hadn't come up before.

If it would help you guys, I could set up a dummy .CSS file in GRC's page headers to continuously pull a .CSS file from our third-party server, but I would hope that the solution you come up with for handling header-located asset fetches would apply to all assets fetched, right?  Otherwise it might be possible to come up with some other way around third-party cookie blocking.

Let me know if I can do anything to help!  :)

And thanks for looking at this!

Steve.
(I was just reading through 421494 and it's clear that the solution you're aiming at will very nicely solve the whole problem the right way... (At least providing the core technology needed to create a comprehensive solution, if not the continuing dilemma over defaults, UI and "how it should work exactly".))
Bravo!
Depends on: 421494
i've checked, and you're right, the existing blocking scheme fails because the "originating URI" of the css request is the css document itself. (favicons are different - in this case the originating URI is chrome - so different cause, same symptom.)

i've tested the new scheme and it handles the css case fine, so we can mark this fixed once bug 421494 lands. as you say, this will apply to other header-fetched resources - if only because if an appropriate parent can't be found (such as the favicon case), we'll default to blocking. :)

also, thanks for reporting this, and for making your tests accessible; it's certainly been helpful to have a testcase i can use to improve our situation.
Status: UNCONFIRMED → NEW
Ever confirmed: true
fixed per bug 421494.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
I'm guessing bug 421494 isn't something we want to land on the branch? Is there a more minimal fix we can include there?
Component: Security → Networking: Cookies
Flags: wanted1.8.1.x?
Product: Firefox → Core
QA Contact: firefox → networking.cookies
Gang...
I have completed the core technology for GRC's forthcoming browser cookie handling analyzer. I'm writing because it demonstrates a bit of odd behavior for Firefox v3 that is going to result in questions.  Specifically ...

o With third-party cookies disabled, you are NOT transacting first-party cookies for FAVICON requests (but you are for CSS content).

o With third-party cookie enabled, you ARE transacting first-party cookies with both FAVISON and CSS content.

o And if third-party cookies are THEN disabled, you are RETURNING an "old" (stale) cookie that you previously exchanged during the FAVICON queries when third-party cookies were enabled.  GRC's cookie forensics page shows this as an orange colored (stale) cookie.

http://www.grc.com/cookies/forensics.htm

This is NOT a privacy concern, of course, since you have third-party cookie leakage nailed down tight under FFv3.  But the behavior demonstrates an oddness that's going to make people wonder what's going on.

Secondly ... Our visitor cookie statistics first showed that Apple's Safari browser has third-party cookies DISABLED by default.  And then we followed-up by confirming that Safari is, in fact, the ONLY browser to have TPCs disabled by default.  It would be spectacular if FFv3 were to follow suit.

http://www.grc.com/cookies/stats.htm

Thanks for your attention and consideration.

/Steve.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Steve, could you please file a new bug to discuss the strange behavior? The original issue reported here is still fixed, and keeping track of more than one issue per bug just leads to trouble.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Group: core-security
Flags: wanted1.8.1.x?
You need to log in before you can comment on or make changes to this bug.