Cookies not listed in Firefox Settings but visible to CCleaner
I see several cookies in the CCleaner cookies windows that I can't find anywhere else. These cookies do not appear in the cookies list under Firefox Settings, and Firefox is the only browser I use.
Some examples are connect.facebook.net, cdnjs.cloudfare.com, and login.wikimedia.org, and these cookies keep coming back after cleaning them up even though I haven't visited those sites and have 3rd-party cookies blocked in Firefox except from visited sites. Notice in the attached image that these cookies are listed in CCleaner, but they aren't listed in Firefox Settings.
Can anyone tell me where these cookies are stored and why I can't see them in Firefox Settings?
All Replies (6)
jscher2000 said
Could you check whether the SiteSecurityServiceState.txt file is the source of "cookies" that CCleaner is finding? Once Firefox has shut down, you can simply delete the file and then do your CCleaner scan.
Indeed, SiteSecurityServiceState.txt is the source of the semi-invisible cookies. I followed the steps I outlined above to re-create the semi-invisible www.facebook.com cookie, and a new line for www.facebook.com was created in SiteSecurityServiceState.txt. I could see the facebook.com cookie in CCleaner. I then edited SiteSecurityServiceState.txt to remove the www.facebook.com line, and the facebook.com cookie immediately disappeared from CCleaner's list.
(Sidenote: CCleaner is clearly aware of SiteSecurityServiceState.txt, because the other sites that persist in that file after a CCleaner clean are exactly the sites I've included on my "Cookies To Keep" list in CCleaner. When CCleaner does its cleaning, it knows to clean the entries in SiteSecurityServiceState.txt.)
So that's it. Well done!
jscher2000 said
(1) Use private windows, which should limit the duration of retention of HSTS data to the length of your private session (2) Use anti-tracking and ad-blocking features/add-ons, since this is not anticipated to be a problem with legit servers
Neither of these suggestions works. Entries in the SiteSecurityServiceState.txt file made during a Private Browsing session persist after the browser is closed, as I demonstrated above. Entries are created in SiteSecurityServiceState.txt by sites that are on my block lists.
--
Attention Mozilla folks: This is clearly a security flaw in Firefox. (I'm using Firefox ESR 52.7.3, 64-bit.) When in Private Browsing mode, the FF documentation clearly states that no traces of browsing activity will remain in the FF profile once the session ends. Either entries should not be created in the profile's SiteSecurityServiceState.txt file during Private Browsing, or any such entries should be deleted when the Private Browsing window is closed. Furthermore, entries created in SiteSecurityServiceState.txt should be visible (and erasable) from within Firefox's own cookie-management workflow.
Okulungisiwe ngu Jon9
Hi Jon9, thank you for reporting on your further testing.
Jon9 said
jscher2000 said(1) Use private windows, which should limit the duration of retention of HSTS data to the length of your private sessionNeither of these suggestions works. Entries in the SiteSecurityServiceState.txt file made during a Private Browsing session persist after the browser is closed, as I demonstrated above. Entries are created in SiteSecurityServiceState.txt by sites that are on my block lists.
(2) Use anti-tracking and ad-blocking features/add-ons, since this is not anticipated to be a problem with legit servers
Sites you visit only in private windows should not be added to SiteSecurityServiceState.txt in the first place. If that is broken it needs to be fixed.
You might want to repeat your test in a clean profile with your preferred privacy settings but no add-ons. See: Profile Manager - Create, remove or switch Firefox profiles
You can file a bug here: https://bugzilla.mozilla.org/enter_bug.cgi
On the second suggestion, I don't know what block lists you are referring to. Firefox's built-in Tracking Protection feature, for example, refuses to load files from known tracking servers. Since third party tracking servers are the ones most likely to root around for trackable data, this should be a useful form of protection. This does not block "first party" scripts on facebook.com or its essential servers (fbcdn domains).
jscher2000 said
Sites you visit only in private windows should not be added to SiteSecurityServiceState.txt in the first place. If that is broken it needs to be fixed. You might want to repeat your test in a clean profile with your preferred privacy settings but no add-ons. See: Profile Manager - Create, remove or switch Firefox profiles
It is indeed broken. I created a new profile, started Firefox in that profile, quit Firefox, deleted the SiteSecurityServiceState.txt file for that profile, and restarted Firefox in a Private Browsing window in that profile. I vistied facebook.com, quit Firefox, and examined SiteSecurityServiceState.txt again for file for that profile. The entry for www.facebook.com was there.
Is somebody from Mozilla here on this forum who can report this and have it fixed? I don't have the technical background to explain all of this is a formal bug report.
jscher2000 said
On the second suggestion, I don't know what block lists you are referring to. Firefox's built-in Tracking Protection feature, for example, refuses to load files from known tracking servers. Since third party tracking servers are the ones most likely to root around for trackable data, this should be a useful form of protection. This does not block "first party" scripts on facebook.com or its essential servers (fbcdn domains).
I am using both Firefox's native Tracking Protection with the "disconnect.me strict protection" option, and AdBlock Plus with the following custom filters, which are obviously not being applied to the SiteSecurityServiceState.txt entries:
facebook.com^$domain=~facebook.com ~facebook.net|~fbcdn.com|~fbcdn.net facebook.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net fbcdn.com^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net fbcdn.net^$domain=~facebook.com|~facebook.net|~fbcdn.com|~fbcdn.net
Jon9 said
I created a new profile, started Firefox in that profile, quit Firefox, deleted the SiteSecurityServiceState.txt file for that profile, and restarted Firefox in a Private Browsing window in that profile. I vistied facebook.com, quit Firefox, and examined SiteSecurityServiceState.txt again for file for that profile. The entry for www.facebook.com was there.
I can't replicate that in ESR:
- Empty SiteSecurityServiceState.txt
- Launch Firefox to the home page (default settings)
- Open a new private window
- Log into Facebook, check notifications, mark them read
- Log out of Facebook, close private window, exit Firefox
SiteSecurityServiceState.txt contains three sites:
self-repair.mozilla.org:HPKP self-repair.mozilla.org:HSTS aus5.mozilla.org:HSTS
How exactly are you launching the private window?
jscher2000 said
I can't replicate that in ESR:
I didn't log in to Facebook. (I don't subscribe.) I just went to fb.com, waited for the homepage to load, then quit FF.
I've launched the private window two ways, with the same result: From a blank regular FF startup window, I clicked on the burglar mask icon; and from the Windows Start menu, I chose "New Private Window" from the Firefox submenu.
Are we both using the same FF version? Mine is 52.7.3 (64-bit) on Windows 10 Pro.
Okulungisiwe ngu Jon9
Jon9 said
Are we both using the same FF version? Mine is 52.7.3 (64-bit) on Windows 10 Pro.
My main installation is 64-bit Firefox 59.0.2, so to avoid a folder conflict, I run 32-bit Firefox 52.7.3. This is on Windows 7.