I'm using K-M76-RC2 and this file lists a huge amount of sites I've visited.

Browser clean up becomes a little compromised while this list remains intact.

Apparently the HSTS supercookies (fingerprinting) are now stored in a simple separate text file, instead of sqlite:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2919581
https://forum.palemoon.org/viewtopic.php?t=14486

Actually the different location is a huge step forward, if that file can now be blocked by simple write-protection (hope it works??)



Edited 1 time(s). Last edit at 01/06/2018 10:13PM by siria.

It works for sure.
I've done it for ages and nothing was written to that file.
By doing so you disable a potential security layer at the expense of privacy. It's a personal choice.

In KM-Goanna you can set

network.stricttransportsecurity.enabled

to false to achieve the same result.



Edited 1 time(s). Last edit at 01/07/2018 01:38AM by Yogi.

About to block supercookies IMHO,

dom.sms.requestStatusReport false
dom.server-events.enabled false

http://kmeleonbrowser.org/forum/read.php?19,144468

Also to completely bypass this kind of issues:

dom.storage.enabled false
dom.storage.default_quota 0

https://www.heise.de/forum/heise-online/News-Kommentare/Frankreich-laesst-Google-buessen/Google-Co-im-Firefox-loeschen/thread-1264641/#posting_7080470

Quote
siria
Actually the different location is a huge step forward, if that file can now be blocked by simple write-protection (hope it works??)

Nice advice, I have protected it as you suggested, thank you @siria.
Would KMeleon have an option for supercookies at privacy options?



Edited 6 time(s). Last edit at 01/07/2018 07:28PM by J.G..

Quote
siria
Apparently the HSTS supercookies (fingerprinting) are now stored in a simple separate text file, instead of sqlite:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2919581
https://forum.palemoon.org/viewtopic.php?t=14486

Actually the different location is a huge step forward, if that file can now be blocked by simple write-protection (hope it works??)

Sorry for replying so late. After reading your post twice I'm afraid that you misunderstood something and since no one replied since...

That's not a (new) different location for fingerprinting, just another way to misuse (this time) the HTTP Strict Transport Security implementation for tracking/identifying.

As for fingerprinting, it's almost impossible to completely circumvent - even if you switch browsers. It's only a matter of expense and effort for the operator of the server you connect to. Generally, operators are trying to avoid unprofitable expenses...



Edited 1 time(s). Last edit at 01/07/2018 08:44PM by Yogi.

Quote
Yogi

Quote
siria
Apparently the HSTS supercookies (fingerprinting) are now stored in a simple separate text file, instead of sqlite:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2919581
https://forum.palemoon.org/viewtopic.php?t=14486

Actually the different location is a huge step forward, if that file can now be blocked by simple write-protection (hope it works??)

Sorry for replying so late. After reading your post twice I'm afraid that you misunderstood something and since no one replied since...

That's not a (new) different location for fingerprinting, just another way to misuse (this time) the HTTP Strict Transport Security implementation for tracking.

Read it a third time...?

@JG:
there sure a lots of ways and prefs to tinker with, for blocking lots of different stuff (supercookies is just a general term for all sorts of private-stuff-tracking)
DOM-storage is often abused, but sometimes necessary for the purpose it was actually invented :cool: Guess some google-services (docs?) need them, but not sure. That's why my macros priv3buttons and permdefs contains a toggle.

Best way to avoid supercookies (not fingerprinting) would be a private mode browsing implemented in K-Meleon.
Wonder if workarounds with a second profile folder and tinkering with policies at OS level is the best solution for the average user.

Quote
Yogi
Best way to avoid supercookies (not fingerprinting) would be a private mode browsing implemented in K-Meleon.
Wonder if workarounds with a second profile folder and tinkering with policies at OS level is the best solution for the average user.

+1

Thanks for info, I'll either erase the file and set the new one to read only, or
set it for custom delete in ccleaner.

I found sitesecurityservicestate.txt when I was using Agent Ransack's text search for urls within the entire K-M folder to see how well K-M cleaned up web traces.

Chrome (theworldbrowser) is bad for storing traces in many different files and now I see that zoom prefs are stored in the main prefs file on a per site basis.

Just a little confused on what steps to do. Maybe this is 'overkill' but I did this step first.

Clear the contents of the 'SiteSecurityServiceState.txt' file located in the K-Meleon folder and then I set it to 'Read-only'.

Also, as Yogi posted:

"In KM-Goanna you can set - network.stricttransportsecurity.enabled

to false to achieve the same result."

I did both ... is this OK or 'overkill' ???


Also J.G. posted right below Yogi's post:

About to block supercookies IMHO,

dom.sms.requestStatusReport false
dom.server-events.enabled false

Also to completely bypass this kind of issues:

dom.storage.enabled false
dom.storage.default_quota 0

... should those steps also be done, I checked my settings and they are currently 'true' and the 'dom.storage.default_quota' has the number '5120' and not '0'.

... also I found this information:

user_pref("network.stricttransportsecurity.enabled", false);
user_pref("network.stricttransportsecurity.preloadlist", false);

... should these be set as indicated?

thanks,



Edited 1 time(s). Last edit at 01/10/2018 10:47AM by callahan.

callahan

WOW, that is a lot of prefs. Thanks for putting all together in one place.

If I can, I will test and report. Best outcome is some macro for users which may help make correct settings depending on what exactly the user wishes to accomplish.

Hanlon’s razor is an eponymous adage named after Robert J. Hanlon that states: “Never attribute to malice that which is adequately explained by stupidity.”

JamesD

JamesD ... OK, thanks for checking all this out. Maybe a 'guide' or a future fix of some sorts would be in order.

There may be other people like me just not sure what to do or 'how much' to do.

Maybe just marking the file as 'Read-only' would be enough ... maybe several steps or 'fixes' should be done ... just not sure on my part.

callahan

Also wondering: does anyone know if KM keeps this file active in RAM during a session, like prefs.js? If yes, a protected disc-file wouldn't help much people with extremely long browser sessions, but instead the pref-toggle much better. This is also much more flexible, could be toggled on only when needed for a short time.

Quote
callahan

Also, as Yogi posted:

"In KM-Goanna you can set - network.stricttransportsecurity.enabled

to false to achieve the same result."

I did both ... is this OK or 'overkill' ???

Basically the same result. Main reason for posting that pref was to show which feature you kill by write-protecting that text file.

Quote
callahan

... also I found this information:

user_pref("network.stricttransportsecurity.enabled", false);
user_pref("network.stricttransportsecurity.preloadlist", false);

... should these be set as indicated?

thanks,

The respective features, the two prefs you mentioned above stand for, will be crippled if set to false but you will still have some entries in SiteSecurityServiceState.txt.
For a test you can visit the below sites:
support.mozilla.org
support.cdn.mozilla.net

If you want to keep SiteSecurityServiceState.txt at 0 Bytes you will have to write-protect it.
No farther changes in about:config needed.

Quote
siria
Also wondering: does anyone know if KM keeps this file active in RAM during a session, like prefs.js? If yes, a protected disc-file wouldn't help much people with extremely long browser sessions...

If remote servers can read the RAM then you have a much bigger problem than the issue we are talking about (cookies, passwords, e.t.c.).