sidki-config: Feb 13 2009

[sidki3003]

(Apr. 04, 2009 03:21 PM)lnminente Wrote:  The filter Block Cookies, i think it is for blocking the full outgoing cookie. And if i'm right the filter Fake Cookies on sel. sites, is replacing also the full cookie, all his fields.

Yes, it replaces the entire set-cookie string, unless you use one of the two modifiers, which are explained in the respective list comment.

Quote:So we could focus in typical tracking cookie fields like __utma, __utmb, __utmc etc...

This type of JS tracking cookies should definitely be blocked on function/script level, *before* it comes into existence.

---

If i get you right you are discussing two different things:

1 - Add another filter targeting the "Cookie" header, using the same CookieValues list.

Yes, it has a useful aspect when it comes to modifying JavaScript generated cookies. And only there. I had it like that for a while (i.e., a Cookie header filter using the same list), because there was a site (linux.com) which stored a redirect URL in a JS cookie. Turned out it was the only site doing that, and it stopped doing that after a few months.

Personally, i didn't find it comfortable to handle two different versions of a respective cookie: The one the browser had stored (and was still using for document.cookie tests, of course). And the one that got sent back via HTTP.

Right now, if a specific JS generated cookie is causing trouble, i simply override it via the IncludeExclude list.


2 - Do all the cookie faking from that same CookieValues list.

I agree that this list gives more fine control over what part of the cookie we like to modify exactly. However, usually that isn't necessary. Luckily, because it allows us to just test the cookies coming from a specific URL, and not every phreaking cookie in the world.

There's one important exception. The Google PREF cookie does require a lot of fine control. Which is why it is included in that list.