disable SiteSecurityServiceState.txt creation

[joe04]

v27 added the always-empty SiteSecurityServiceState.txt file to my profile. Can you remove its creation altogether? (Very minor, I know, but it's nice to remove profile clutter.)

[joe04]

after posting it occured to me that this may actually be something useful so looked it up on github:
https://github.com/MoonchildProductions ... &type=Code

So perhaps a better request is to ask -- what does this do, and in what cases would the file be non-empty? Also, if it is non-empty and pertains to something serious that the end-user should know about, would the browser indicate this in another way? (Obviously I'm not going to monitor the state of this file; I'm only noticing it because of my recent move from v26 to v27 and paying particular attention to the changes from the big re-base.)

[New Tobin Paradigm]

Better code search: http://xref.palemoon.org/palemoon-trunk/search?string=SiteSecurityServiceState.txt

[GMforker]

I suggested #830

[deckard]

There is a way to "solve" the "problem".
Please note that it is UNOFFICIAL.

Open the file with notepad or equivalent.
Clear the content and save the file.
Make the file READ ONLY.

[kizo07]

SiteSecurityServiceState.txt

Privacy vs. security?
What I've done, I have kept some sites and make file protected/read only (expiry date?). So far this is, for me, ok compromise option to prevent tracking without compromising security.

Edit: As always, my fight to coordinate brain, fingers and keyboard + English

inkl. \User\Palemoon\Profiles\Default\storage You clean inside folders 'http +++ ...' (but retains the folders)

Not big deal those two, but, anyway for those who is 'worried'.

[Moonchild]

A simple regression. Will be fixed by reinstating network.stricttransportsecurity.enabled

[joe04]

ah yes, HSTS, something I'd only briefly learned about sometime ago. For me and my workflow it's definitely not desired; privacy the clear winner.

I went ahead and set these:
user_pref("network.stricttransportsecurity.enabled", false);
user_pref("network.stricttransportsecurity.preloadlist", false);

When the next beta drops I'll report back. Hopefully disable will get rid of the text file (which I now see does indeed contain HSTS stuff given that I've had the broswer open for a while.)

Thanks @GMforker for creating the issue and providing the helpful link. And thanks @MC for the quick regression fix.

[joe04]

just updated to latest beta and can verify that SiteSecurityServiceState.txt is not used at all during browser operation, i.e. I close PM, delete the file, re-launch PM and it's not generated during the course of browsing. So that tells me HSTS is properly disabled.
BUT, an empty SiteSecurityServiceState.txt is auto-generated by the exit routine when I close the browser.
Can you fix this nuisance of auto-generating the file at program exit?

EDIT: a minute after I post this, lo and behold what appears again during this very same browser session... Since the .txt is still being generated during the course of browsing, how do I know for sure that HSTS is indeed disabled?

EDIT2: still same browser session as prior edit. Update is that SiteSecurityServiceState.txt is now NON-EMPTY with several HSTS entries plus one HPKP entry (for github, as I just logged in there to post an unrelated bug).

So now I'm wondering what's going on... are these HSTS and HPKP entries in the text file indicative of the protocols being used? Both should be disabled per my HSTS settings above + HPKP by default settings. So why the activity in the text file?

EDIT3: can confirm HPKP activity, as I just context switched to my text editor and it indicated the file needed to be updated and one of the parameters changed (looks like it could be a timestamp.)

[joe04]

opened github issue:
https://github.com/MoonchildProductions ... issues/840

[Moonchild]

Note, HPKP will also use this file. That's unrelated to HSTS and isn't vulnerable to privacy issues, so you'll always have this file created for HPKP storage.

(So as for the title of this thread, that would be a no. There's no reason for the user to disable HPKP so this file's creation will always occur to permanently store domain states unless in private browsing mode).

[joe04]

Unstable just updated so now have yesterday's HSTS commit. I can confirm that github no longer puts HSTS entries in the .txt. So thanks for resolving that.

I'd also like to discuss HPKP.

There's no reason for the user to disable HPKP so this file's creation will always occur to permanently store domain states unless in private browsing mode.

First, HPKP already should be disabled with the default setting:
security.cert_pinning.enforcement_level = 0
Which is the disabled value in the enum. (Thanks @Tobin for the xref link; it is indeed a better code search tool.)

Second, the HPKP entry that Github places in the .txt file does not persist. The .txt is cleared every time I exit the browser. I've seen it happen several times already.

So, from your quote, if HPKP is enabled you expect to see those keys persist in the file? Makes sense if that is where they are pinned.
Also, just so I'm clear -- assuming HPKP enabled, are any of these keys stored in my profile key3 database? (or another .db file; I don't know anything specific about what's in these databases)

(And must say I'm grateful Github uses both HPKP and HSTS, which proved serendipitous.)

[joe04]

Poked around the code some more, and I think my prior post sums up HPKP behavior correctly, at least with respect to the .txt file.

As for .db files, per mozillazine they're totally unrelated to HPKP, which is restricted to the .txt file.