New: Block Third Party Cookies

[sidki3003]

Despite the topic title, the idea isn't new at all and is implemented as an option in most browsers. There's no reliable data confirming that this is safe. Wikipedia says it doesn't cause any problems, but only offers the opinion of some Washington Post columnist as source.

Anyway, Proxomitron doesn't have all the information that the browser has, in this case: what is the main document? Thus, it has to rely on the original referrer header (not the one that we've possibly "corrected"). As a result, the entire concept fails (gracefully), if you've told your browser to suppress the "Referer" header.

I've started with the assumption that all cookies from all off-domain referred documents, which don't come as text/html, can be blocked. That was too simple, as some sites bounce your request through several 302 redirects, setting test cookies along the way (netflix.com being a good example).

Consequently, i had to allow cookies from offsite referred onsite redirects, which is a pity, since a couple of webbugs are using the same bouncing strategy.

Code:

[HTTP headers]
In = TRUE
Out = FALSE
Key = "Set-Cookie: 2a Block Third Party Cookies     9.04.03 [sd] (d.1) (In) WIP9"
URL = "^$TST(keyword=*.(a_cookie|a_cookie3p).*)|$LST(AllowCookies)"
Match = "?&(^$IHDR(Content-Type:( ) (text/html|application/xhtml\+xml))|$IHDR(Location:( ) ((^[^/.]+//)|[^/.]+//$TST(uHost)(^.))))\1&$TST(hOrigRef=(^[^:]+://([^/]++.|)$TST(uDom)(^.))\0)&($IHDR(Content-Type: \2)|)&$LOG(wRESP $DTM(c) : Set-Cookie 3P killed: \1)($TST(volat=*.log:2*)$ADDLST(Log-Main,[$DTM(d T)]\tHDR_In Set-Cook_3P\t\u \t\2 \tRef: \0 \t\1)|)"

So far so good. After having the filter integrated, "Set-Cookie: 3 Block Ad Cookies" is basically jobless, *except* for secondary documents requested via Flash. I've never seen a "Referer" header in these cases. Luckily, the Flash plugin / AX control is sending its own user-agent header (latter not verified lately).

So, a possible future extension would be having the filter also block cookies of "Flash requested" documents.



Note 1: Anticipating scenarios where this filter needs to be bypassed, i've added a new keyword: "a_cookie3p".

Note 2: If you like to try this filter, then - besides merging it - you'd also *have* to do a "Configure -> OK -> Save" from Proxomitron's main window several times, in order to get it into the right "physical" position.

Note 3: Ideas/comments/suggestions welcome!

[Graycode]

(Apr. 02, 2009 11:13 PM)sidki3003 Wrote:  Note 3: Ideas/comments/suggestions welcome!

I think cookies, whether 3rd party or not, are primarily undesirable when they're used to track you the way DoubleClick and many others do. Normal server-side processes don't try to set (or read) a cookie for image requests, but advertising and tracker servers routinely do that. I'm attacking that tracking strategy by denying them the ability to assign cookies on things like invisible images, 3rd party image requests, and ad banners.

The default handing of an image request in my proxy is to strip off "Set-Cookie:" and "Set-Cookie2:" headers when the requested file extension is: gif, png, jpg, jpeg, ico, wmf, ... and a few others. Also if a server presents a MIME starting with "image/" then any cookie headers are removed.

Images account for the greatest majority of browser requests. By getting them "out of the way" you're then left with a much smaller percentage of cookie-setting events to worry about.

[lnminente]

Sidki, as you said blocking offsite cookies doesn't works well. For example when we are in a web and we open one of our bookmarks, proxomitron would interpret that first request as offsite. If we refresh the page with F5 the same would occur. But we should click in the address bar and press enter, in that way the referer would be the right to make proxomitron think it isn't offsite... So having in mind all our modern browsers can kill the third party cookies and it is better... what i'm doing with proxo just now is to kill third party ad cookies and doing some log.

Graycode, I didn't killed image/* cookies because i thinked it would work as the referer, killing some images. Have you tested if it works well in some social pages like Facebook?

About my logs for blocking offsite cookies most of them were:
- text/html with extensions php or cgi and response 302 (also some 301 and 303)
- image/* with extensions jpg or gif and response 200

[sidki3003]

(Apr. 03, 2009 06:05 AM)Graycode Wrote:  Normal server-side processes don't try to set (or read) a cookie for image requests, but advertising and tracker servers routinely do that.

Hmmm... I think if this "don't try to"/"routinely do" ratio would translate to only 1/99, it would already be too much. As lnminente implied, often you only see a potential problem on a site, if you have an account there.

[sidki3003]

(Apr. 03, 2009 10:57 AM)lnminente Wrote:  Sidki, as you said blocking offsite cookies doesn't works well.

No, the filter as posted does work fine for me so far. I'm running it for several weeks now.

Quote:For example when we are in a web and we open one of our bookmarks, proxomitron would interpret that first request as offsite. If we refresh the page with F5 the same would occur. But we should click in the address bar and press enter, in that way the referer would be the right to make proxomitron think it isn't offsite...

That's why HTML documents (as well as onsite redirects) are excluded.

Quote:So having in mind all our modern browsers can kill the third party cookies and it is better...

Again, i disagree. Yes, the browser has more information. But only with Proxomitron we can really fine control such things.

Quote:About my logs for blocking offsite cookies most of them were:
- text/html with extensions php or cgi and response 302 (also some 301 and 303)
- image/* with extensions jpg or gif and response 200

I've also logged the first couple of thousand hits. Zero text/html here, logically. ~50% images (only). Noticeably >1% webbugs coming as CSS, JS, etc.

[ProxRocks]

(Apr. 03, 2009 12:46 PM)sidki3003 Wrote:  Noticeably >1% webbugs coming as CSS, JS, etc.

very interesting indeed...
i have also been noticing an increase in injected "backgrounds" via CSS...

i wouldn't call these "backgrounds" a 'webbug' per se, but i tend to (prefer to) block images that sneak in vis CSS, whether it's a "beacon tracker" or not... (i block favicon's for the same reason, our own IT guy logs visitors to our website based solely on favicon requests...)

[sidki3003]

Of course you can also use documents with legit content as webbug. But such cases are hard to spot. The "greater than 1%" cases were obvious due to empty content and suspect cookie.

[sidki3003]

(Apr. 02, 2009 11:13 PM)sidki3003 Wrote:  After having the filter integrated, "Set-Cookie: 3 Block Ad Cookies" is basically jobless, *except* for secondary documents requested via Flash. I've never seen a "Referer" header in these cases. Luckily, the Flash plugin / AX control is sending its own user-agent header (latter not verified lately).

So, a possible future extension would be having the filter also block cookies of "Flash requested" documents.

Well, no. I only see the "Shockwave Flash" user-agent string when Flash is POSTing to a FlashCom server (like here). Apparently in all other cases the Flash client is sending the string of the hosting browser.

The AX control does also send a "x-flash-version" header, but not the plugin. So the only thing in common is the missing referrer, which we probably can't use, because it would break cookies for browsers that are set up to not send a "Referer" header.

[lnminente]

Don't know what is AX control, but the content type "application/x-fcs" sent to the plugin is helpful?

[sidki3003]

I mean the ActiveX control that Internet Explorer is using, in my case Flash10a.ocx.

I think application/x-fcs is only used for communication with a dedicated Flash server. That doesn't happen too often, so this content-type doesn't help to generally identify requests sent by the Flash client.

[Graycode]

(Apr. 03, 2009 10:57 AM)lnminente Wrote:  Graycode, I didn't killed image/* cookies because i thinked it would work as the referer, killing some images. Have you tested if it works well in some social pages like Facebook?

I'm not stopping browsers from sending out a cookie with an image request where that cookie was set by other non-image methods. What I'm stopping is servers from Setting a cookie on images.

I've not encountered any issues, and my limited use of places like Facebook works fine.

[sidki3003]

In that case, why not go beyond that, blocking set-cookie for any reply that is a 304 etc., or that is a 200/206 but not HTML/XML?

If that's an option, the 3rd party cookie filter wouldn't be required, except maybe for cookie setting offsite redirects.

[lnminente]

Graycode, when you said "Normal server-side processes don't try to set (or read) a cookie for image requests" i understood you was blocking the read, a misread...

Sidki, just after writing the first post here i wrote two filters to kill Set-Cookies from offsite webs for...
-all non 200 or 304 responses
-all incoming with content type equal to image/*

That's WIP, maybe i modify the second filter to delete Set-Cookie when Content-Type is not text/html...

[Graycode]

(Apr. 03, 2009 05:44 PM)sidki3003 Wrote:  In that case, why not go beyond that, ...

If that question is for me, I'm just suggesting that images have special handling. Cookies being Set on them is done by many advertising and tracking sites. Images are a large proportion of all requests, and setting cookies on them is usually the kind of tracking that people want to avoid. Whether it's a 3rd party cookie or an off-site IMG link doesn't really matter when it comes to images. I've personally not yet encountered a normal site that needs to be allowed to Set a cookie on an image that it serves.

As you indicate, cookies can also be managed with consideration of response codes, other MIMEs, etc. That often leads to having to define exceptions for those rules. Even a 204 could validly assign cookies as mentioned in that thread.

I see images as a more clear-cut rule which eliminates many of the undesirable cookies that are routinely encountered. It's not the only rule for managing cookies, but IMHO it's an important one. You did ask for "Ideas/comments/suggestions"

[sidki3003]

lnminente, as Graycode mentioned, there are a couple of responses that don't necessarily come with a content-type header, but should be allowed to set cookies nonetheless.

I'm not too familiar with HTTP, but besides "204 No Content", there are at least: "202 Accepted", "301 Moved Permanently", "302 Found".

(Apr. 03, 2009 07:46 PM)Graycode Wrote:  As you indicate, cookies can also be managed with consideration of response codes, other MIMEs, etc. That often leads to having to define exceptions for those rules.

Yep, that's exactly what i want to avoid.

Regarding images, okay, i've got your point. I'll test-drive a corresponding filter. Thanks for the input.