X
點擊此處開啟此網站的行動版。

技術支援討論區

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?

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?
附加的畫面擷圖

額外的系統細節

已安裝的外掛程式

  • Shockwave Flash 28.0 r0
  • 5.1.50907.0

應用程式

  • User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0

更多資訊

提出問題者

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.

''jscher2000 [[#answer-1098328|said]]'' <blockquote> 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. </blockquote> 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 [[#answer-1098328|said]]'' <blockquote> (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 </blockquote> 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.'''

由 Jon9 於 修改

jscher2000
  • Top 10 Contributor
8695 個解決方法 71076 個答案

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

Hi Jon9, thank you for reporting on your further testing. ''Jon9 [[#answer-1099115|said]]'' <blockquote>''jscher2000 [[#answer-1098328|said]]'' <blockquote> (1) Use private windows, which should limit the duration of retention of HSTS data to the length of your private session <br> (2) Use anti-tracking and ad-blocking features/add-ons, since this is not anticipated to be a problem with legit servers </blockquote> 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.</blockquote> 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: [[Use the Profile Manager to create and remove 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

''jscher2000 [[#answer-1099132|said]]'' <blockquote> 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: [[Use the Profile Manager to create and remove Firefox profiles]] </blockquote> '''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 [[#answer-1099132|said]]'' <blockquote> 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). </blockquote> 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
jscher2000
  • Top 10 Contributor
8695 個解決方法 71076 個答案

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?

''Jon9 [[#answer-1099335|said]]'' <blockquote>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.</blockquote> 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: <pre>self-repair.mozilla.org:HPKP self-repair.mozilla.org:HSTS aus5.mozilla.org:HSTS</pre> 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.

''jscher2000 [[#answer-1099344|said]]'' <blockquote> I can't replicate that in ESR: </blockquote> 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 於 修改

jscher2000
  • Top 10 Contributor
8695 個解決方法 71076 個答案

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.

''Jon9 [[#answer-1099348|said]]'' <blockquote> Are we both using the same FF version? Mine is 52.7.3 (64-bit) on Windows 10 Pro. </blockquote> 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.