hi, the testpage referenced in the article was http://www.radicalresearch.co.uk/lab/hstssupercookies - please try if it assigns the same ID to you in different firefox sessions (i couldn't reproduce the issue when no history is kept).

Thanks for the link, philipp.

When I test the site in a regular window, then open the URL again in a second tab, it can read the code it set. Similarly, if I open the site in a private window, a second tab in the private window can read the code set in the first private tab. But I couldn't make it cross over between regular and private windows.

In case it matters, I have cookies set to expire when I close Firefox (but I didn't close Firefox during this test).

(As an aside, the article referenced in the original question seems to be copied from this article: http://www.ghacks.net/2015/10/16/how-to-prevent-hsts-tracking-in-fire...)

Hi philipp,

the test page works as expected: the values it stores seem to be deleted when I close my (private) browsing session.

However (and I do apologize as this was probably not very clear) my question was about values already present in the "SiteSecurityServiceState.txt file. This file has a bunch of entries which, if I clear them, seem to be eventually added back by Mozilla.

Examples of these are shown in the image below. Note that it has entries e.g. for Facebook even though I do not explicitly visit FB (I do not have an FB account).

So perhaps the issue is that private browsing does delete new entries from this file but that Firefox for some reason keeps it populated with pre-defined entries?

Or otherwise this is some bug...is this file populated with entries in your system?

thanks for the follow up - i tested a little bit and could reproduce an issue that looks a bit like this: entries "collected" before firefox was set to always run in private browsing mode remain in this file (though some other cached entries and history data gets cleared once you set "never remember history" - so it may be a minor bug here that this is not extended to the HSTS list). maybe this happened for you as well? in this case simply delete this file & the entries shouldn't come back.

firefox also contains a preloaded list of hsts-hosts - but this is stored elsewhere and isn't suitable to be used for tracking purposes. more information is available at https://blog.mozilla.org/security/2012/11/01/preloading-hsts/

Thank you for your response, philipp.

I have in fact cleared the file before and the values are eventually added back to it (as in that case in my original post).

I will dig into this and check if I can find where they come from.

On another note I suspect that that test page (at http://www.radicalresearch.co.uk/lab/hstssupercookies) does not store it's "cookie" in the "SiteSecurityServiceState.txt" file but somewhere else.

I am saying this because of following test steps that I did:

1. opened the "SiteSecurityServiceState.txt" file open in Notepad++ 2. took at note (or screen shot) of the "SiteSecurityServiceState.txt" file (still open in Notepad++) 3. navigated to the test page at http://www.radicalresearch.co.uk/lab/hstssupercookies 4. took a note of the tracking ID provided by the test page. Left the page open. 5. reloaded the "SiteSecurityServiceState.txt" file (using File > Reload from disk) 6. took at second look at the "SiteSecurityServiceState.txt" file (At this point there was no difference to how it looked like in Step 2) 7. cleared the "SiteSecurityServiceState.txt" file and saved it. It was now empty. 8. closed the tab that had the test page open but did not close the browser. 9. re-opened a new tab and navigated to the test page. Noticed that it gave me the same number as previously. 10. reloaded the "SiteSecurityServiceState.txt" file (using File > Reload from disk) However at this point "SiteSecurityServiceState.txt" is still blank.

In conclusion it looks like the test page is saving it's "cookie" somewhere else than in "SiteSecurityServiceState.txt". As such it may not be suitable for testing the HSTS persistence.

during a session this information is stored in RAM memory - once you close firefox (and you are not in private browsing mode), the changes are written into that file in your profile folder. did you file bug 1230559 as well? if so i think we could re-purpose it to deal with the bug i've described in my prior answer...

edit: so in conclusion, please try to delete the file while firefox is not running in order to address the issue!

as existing cookies are kept when switching firefox from "remember history" to "never remember history" as well, i think this was the expected behavior anyway and not a bug as i've first thought.

Thanks philipp, it could well be that FF was running earlier when I cleared the file, and that for this reason the entries were eventually put back.

I noticed in the tests I did today that when FF puts the entries back, it does not do so when it is closed but when it is eventually re-launched.

So it could be that 1. initially the entries where from the time before I had enabled to always surf in Private Mode 2. when I cleared the entries from "SiteSecurityServiceState.txt", I did it while FF was running 3. I did not use FF for a while after clearing the entries. So then when I eventually launched FF again it added the entries back at that time. So then when I eventually launched FF again it added the entries back at that time.

Now I cleared the file again a couple hours ago (while FF was not running) and have since been surfing the web without the entries coming back.

Misunderstanding how it is expected to work was probably the cause of my problem with that test site as well. I had assumed that it would have added some entries to the file while FF was running (and that these would have been deleted when closing FF because of my private browsing mode). Instead it did not use the file at all because of my private browsing mode.

And yes I had opened the bug at https://bugzilla.mozilla.org/show_bug.cgi?id=1230559. I have now closed it with an explanation.

Thank you for your help.