7

Firefox stores HSTS data in a file named SiteSecurityServiceState.txt.

This poses two serious issues:

  1. It creates an opportunity for tracking. See http://www.radicalresearch.co.uk/lab/hstssupercookies

  2. It creates a privacy issue by leaving behind a plain text list of many of the secure sites the user visited, even after they have cleared the browser's cache and history.

Because of these issues, many people have chosen to create a dummy SiteSecurityServiceState.txt file by creating a zero-byte file with that name, and marking it as read-only.

This technique prevents Firefox from writing anything to SiteSecurityServiceState.txt.

Obviously, this prevents the inter-session benefits of HSTS (meaning one Firefox session benefiting the next session), since no data persists. But does this technique prevent the intra-session benefits of HSTS (meaning the benefits within a single Firefox session)?

As an aside, other major browsers suffer from these same issues. But to keep answers focused, this question only deals with the Firefox browser.

Improve this question
2
  • 1
    On a sidenote: at least the "well-known" HSTS sites that are hardcoded into the browser version would be protected.
    – Hagen von Eitzen
    Aug 25, 2016 at 12:01
  • You could test this yourself - sounds like you already understand it in detail
    – paj28
    Aug 25, 2016 at 12:30

1 Answer 1

Reset to default
1

According to Comment #68 on bug 775370 the file is flushed on browser exit or after five minutes. This is the bug that introduced the SiteSecurityServiceState.txt file.

It implies that intra-session HSTS "cookies" are stored in memory.

From a quick glimpse at the code it seems it's a memory data structure called DataStorage that's serialized to the file.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .