Google PREF cookie undeletable in Firefox?

I experienced this issue today. My workaround is to quit Firefox, delete file cookies.sqlite, then restart Firefox. I'm not sure why I didn't notice this before, or why it just started happening very recently if that's the case.

Others have noticed this too:
http://stackoverflow.com/questions/6301114/how-pref-cookie-google-com-appears-in-firefox
http://superuser.com/questions/723331/this-google-cookie-is-indestructable
https://support.mozilla.org/en-US/questions/987493

Comment from the first link:

 

I don't have this issue with v3.6.14 !

 

Here's what I've found since the first post:
1. This Firefox feature (if turned on) as of v30.0 will periodically set a Google PREF cookie if your cookie settings allow it.
2. If you have Firefox extension Biscuit (as of v2.4.2) installed, this cookie normally can't be deleted unless it's a session cookie. To delete it, disable Biscuit, restart Firefox, delete the cookie, enable Biscuit, restart Firefox. Go into cookie Exceptions and make cookies from google.com "Allow for Session." This Google PREF cookie will thereafter be deleted when you exit Firefox, since it's now a session cookie.

 

Cookies Manager+ add-on has an option to "delete and block" certain cookies

https://addons.cdn.mozilla.net/img/uploads/previews/full/56/56084.png

 

I tested that extension today. If I recall correctly, its block functionality uses the existing Firefox cookie Exceptions functionality to block cookies.

 

Has anyone seen this behavior in other Gecko browsers (PaleMoon, SeaMonkey, etc) or is it exclusive to FireFox?

 

I'm not sure, but in Firefox 30.0 that cookie was set within roughly 2-5 minutes of starting the browser (if the cookie settings permitted it) every time that I tested it. The undeletable aspect happens only if Biscuit is installed.

 

I forgot to mention that either with or without Biscuit installed, deleting just that particular cookie doesn't necessarily work, if I recall correctly; try to delete it by deleting all cookies.

 

I kept a couple of links:

shouldn't send Google's cookie with SafeBrowsing API requests (focus on later comments)
https://bugzilla.mozilla.org/show_bug.cgi?id=368255

implement a separate cookie jar for safebrowsing
https://bugzilla.mozilla.org/show_bug.cgi?id=897516

The first of which (which links to the second) I did see mentioned by Bacon man. I lost track of where that effort stands and how things are supposed to be working now. Note that both of those bug reports are marked resolved fixed, target milestone FF27. Which was released Feb 4th 2014 looks like. So as is always the case, older comments have to be considered potentially out of date in some way.

Last I checked, Google Safebrowsing requests/responses were visible in the browser console (click to inspect) and you can also monitor them via extension (like HttpFox). So I think it should still be a straight-forward matter to 1) disable safebrowsing, 2) take steps to purge all cookies, 3) enable safebrowsing, 4) immediately capture [safebrowsing] requests/responses and walk through them to see what is actually happening and where the Google cookies do/don't show up. While you are at it, you'd probably want to take a close look at the safebrowsing wrkey handling and how persistent it is. IIRC, when I spent some time monitoring it I found it to be very persistent and in some respects arguably worse than a persistent cookie that people are better prepared to deal with. One way to acquire a new value was deleting a particular file in the Firefox profile directory (in which it was found). The name of which escapes me ATM.

IOW, a bit of study should answer all questions. If the separate cookie jar is in some way operational and some extensions don't know how to deal with it, then it would be good to understand the details.

 

No Google cookie observed in Seamonkey 2.26.1 with Startpage as default search engine, safebrowsing on, no cookie manager addons, third-party cookies blocked.

(Edited to fix typos from my posting with a tablet last night )

 

If you disallow third-party cookies and don't have a google.com "Allow" item in cookie exceptions, I believe you won't get that cookie.

 

Bug 1026538 - Cookie Manager can't delete cookies with appid != 0

 

From Bug 1008706 - Google.com PREF cookie keeps coming back even with network disabled and cookies disabled:

 

Good hunting! Bug 1008706 is informative. One point I find interesting is this:

Which seems to be Mozilla's Lead Privacy Engineer acknowledging something that is a serious problem from a privacy POV. The cookie manager should properly display and delete ALL cookies... regular ones, ones acquired while in private browing mode (assuming you are still in that private browsing session and they haven't been erased on exit), the safebrowsing cookies, etc.

It sounds like Bug 1026538 may take care of the cookie manager. Assuming someone actually picks it up and works on it, and no one tries to prevent a full and proper fix. Mozilla's Sr Manager of Security and Privacy Engineering and Mozilla's Lead Privacy Engineer commented in Bug 368255. We shouldn't have this, or these, problems.

Anyway, it sounds like at least some cookie blocking extensions cannot block (delete) the safebrowsing cookie(s) reliably. Given what was said about private browsing, I'm inclined to think that at least some cookie blocking extensions can't block cookies properly while in private browsing mode either. If you use private browsing mode and a cookie blocking extension, you might want to run some tests. Even though Firefox should delete the cookies when you exit that mode, such cookies can still do damage while you are in that mode.

Edit: I forgot I wrote some cookie blocking code as an experiment. Specifically, code that watches for cookie-changed events and immediately deletes new cookies that match a regular expression... and which also examines outgoing requests to see if cookies slip past that blocking mechanism and make it into Cookie headers. An "allow cookies in Firefox, this extension takes over cookie blocking without relying upon Firefox's rules" type of approach. WRT to FF 30.0 private browsing, it didn't see the cookies being set. A little searching turned up this 2013 bug report:

cookie-changed notifications are not useful for private cookies
https://bugzilla.mozilla.org/show_bug.cgi?id=837091
Resolved Fixed, Target Milestone Firefox 21

Which describes the addition of a private-cookie-changed event. I modified my code to also observe that event and the cookies set in private browsing mode were successfully blocked/deleted. I also came across this 2012 bug report:

Cannot see cookies stored in private window with using cookie viewer
https://bugzilla.mozilla.org/show_bug.cgi?id=823941
New, Assigned To: Nobody

Then on to the safebrowsing cookie. My extension received the cookie-changed event, saw the new cookie that matched its block rule, and as with other matching cookies immediately called nsICookieManager remove(). Only it didn't work in the safebrowsing context. The extension subsequently reported precisely the same PREF cookie headed out in numerous safebrowsing requests.

So I think in both the private browsing and separate app ID/cookie jar scenarios there are some issues that could affect extensions.

 

Nice work .

I agree. As an example, some reviews for Self-Destructing Cookies mention the inability to delete this cookie.

 

Im not sure what Im doing right or wrong but I haven't seen any reference to this PREF cookie anywhere in my FF. I have 2 instances of google blocked in the exceptions. BTW I just downgraded to FF28 from 29.

 

I am obsessed with this PREF cookie. I have been studying ways to defeat it for weeks. Google is just a nightmare.

 

does anyone know if Disconnect blocks whatever this cookie is doing?

I have ABE with Fanboy Ultimate List, is that redundant to add disconnect or do they work in tandem?

this site suggests ABE is superior to disconnect by a wide margin. http://www.areweprivateyet.com/

 

See post #11.

 

I use Ghostery and Adblock Plus (EasyList+EasyPrivacy). There is some overlap but they work in tandem from what I've seen.

 

you might consider moving to Ad Block Edge also I read disconnect was open source.

I worry about these add ons, when the money is offered, they will sell out imo.

 

Even if an addon developer sells out, it won't affect how the addon performed before that. When an app that you like goes bad, stay with the last good version.

 

I worry about the data they can collect then sell. these addons could be honeypots

 

Nor does anyone using v28.0

Yet more evidence of why you:

a) Can't trust any version of Firefox after 28

b) Should disable all that "safebrowsing" crap and throw away the key.

I even delete all the URL's in about:config to try to stop it from connecting, on top of turning it off in the options & about:config, and it will STILL try to connect... until I also placed block rules for it in my Comodo D+ to thwart it for good. Nothing short of that will truly stop this thing from mining your data. It is, by definition, adware at best, and malware at worst. I have WOT, Ixquick, Comodo Secure DNS, and my own discretion to protect me from bad sites already... that is plenty sufficient.

I hold all other phishing filters in the same contempt, btw. It is not worth the potential privacy hit to me. I have other measures in place (foremost my own discretion) to turn away bad/rogue sites already without having to risk having who knows what sent out to "the man".

 

For sure. And this is why you NEVER, ever throw away old installers of known/good versions of apps when new ones become available. Always hang onto them at least until you know the new version is kosher, which may take awhile until it's properly dissected by the community, so don't be quick to toss it. Back them up in several different places. You never know when the version you're on now may become a famous "legacy app" years from now that's hard to find an installer for. I get the feeling Comodo FW/D+ v5.10, Firefox v28.0, and TrueCrypt 7.1 will be in those categories in the not so distant future.

Heck, I get the feeling the XP Pro SP3 is going to be THEE legacy OS too... especially once it's proven that Win7/8 have backdoors hardcoded into them. I get the feeling a certain very talented group of cryptographers discovered this already and all h3ll broke loose in the process.

It even applies to addons. I started looking at the release notes of them ever since v29 came out, and any time I see references to adding compatibility/features for Australis I pass them by. So I will be backing up "legacy add-ons" as well from now on. lol

I feel like any and all attempts at maintaining a truly secure, private setup are as fickle as a house of cards right now. I don't have the confidence in any of the new stuff to migrate to it, and also know a time will come that sticking with the old will render me vulnerable as well. With things like stringent HIPS setups, sandboxing, virtualization, massive hardening/trimming, etc... that time can be delayed indefinitely... but only for so long. Then you either have to just bend over and take it if you continue wanting to use the internet, and accept defeat... or find a new hobby and give it up. Reduce my box to purely a gaming console, offline. Oh well... it'd take away one of my bills.