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.

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 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.

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.

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.