reminder: investigate IDB [solved: dom.serviceWorkers.enabled]

[Thorin-Oakenpants]

SOLVED: some sites use service workers to spawn their IDB entries

[grauenwolfe]

default:

• https+++www.youtube.com^firstPartyDomain=youtube.com > cache > caches.sqlite
• moz-extension+++id-string > idb > .sqlite file & folder with 5 items named; 8, 9, 13, 14, 16 – (fairly sure this is uBo's filter lists)

permanent:

• chrome > idb > .sqlite file & empty folder
• moz-safe-about+home^firstPartyDomain=about.id-string.mozilla > idb > .sqlite file & empty folder

temporary:

• never has anything in it

So what is the final verdict with extensions, specifically uBo and having to enable IDB, dom storage, etc? Did I understand correctly that IDB must be enabled now to let uBo do it's thing properly?

Also, about:cache always shows 0 entries, even after YouTube, or any other site that creates a folder in /storage, so I'm a little confused about that. I do occasionally get cache entries from certain Mozilla pages, wyciwyg, and uBo's filter lists. I must have something off then if you, @Thorin-Oakenpants are not getting anything at all. I get very little but still, that's more than nothing. I don't even know how much I should care or even worry about it anymore. Every countermeasure seems break something else...

PS - If there's any possible danger in listing those file/folder names verbatim please let me know. No idea if they are UUID or generic or whatever.

[earthlng]

turned off OCSP (security.OCSP.require)

FYI: that pref doesn't "turn off" OCSP, it only disables hard-fail.

re: youtube - you maybe don't get the IDB stuff because of some of your uBlock filters and/or rules. I think you once said you're using the full "Youtube: Pure Video Experience" - I use only parts of it and I've also seen the IDB files/folders when I open YT in a non-private window.

@grauenwolfe about:cache is currently broken due to first-party-isolation afaik

[Atavic]

I have crap there.

[grauenwolfe]

If I'm understanding the bug report correctly, it looks like FPI = true is hiding cache entries even though they are still actually being collected? And here I am thinking that at last I had completely disabled any caching...

I've noticed that changing browser.cache.use_new_backend_temp = false instantly causes cache entries to become visible (after refreshing about:cache) even with FPI = true. I don't know what this means ultimately other than Mozilla's caching implementation is one of the most convoluted systems I've dealt with.

If anyone likes to check:

1. set browser.cache.use_new_backend_temp = false
2. load a few websites
3. refresh about:cache and viola - cache entries are there
4. set browser.cache.use_new_backend_temp = true
5. refresh about:cache and now they've all disappeared

What do you guys see when you load about:cache? Here's mine with these settings:

• privacy.firstparty.isolate = true
• browser.cache.use_new_backend_temp = false

And now with these settings:

• privacy.firstparty.isolate = true
• browser.cache.use_new_backend_temp = true

And finally, shouldn't the disk section's entries be all "0"? Yes, it clearly states "Storage disk location: none, only stored in memory" but I'd be more comfortable if it showed all "0" just like the appcache section does. I don't get it. I have every cache option disabled except in memory only.

[crssi]

I have no time, at the moment, to do some tests. :(

But what about

user_pref("privacy.firstparty.isolate.restrict_opener_access", true);

Does this preference block the cache cleaning?

Otherwise out of ghacksuser.js default I have additionally

user_pref("browser.cache.memory.enable", false);
user_pref("privacy.firstparty.isolate", false);

The privacy.firstparty.isolate = false is for a reason that, otherwise cookies are not cleaned by "Cookies Exterminator" or any other WE that deals with those.
"Cookies Exterminator" I use until "Cookie AutoDelete" is not able to remove local storage.

It might be a bit slower rendering (or its a placebo effect only), but I have 0 cache and got effectively rid of ETAG cookieless tracking/fingerprinting too.

Ohh, nice report @grauenwolfe.

This is about:cache here after a few hour usage:

[earthlng]

@grauenwolfe

And finally, shouldn't the disk section's entries be all "0"?

If that bothers you, you can set browser.cache.disk.capacity to 0.

[Forsaked]

Was the PB mode active?

[earthlng]

I wish I could get HTTP header modify whatever to do as it says

It only allows modifying request headers and afaik some of the cache-dependent request headers are impossible to remove because they're probably added by FF after extensions had their hands on the headers. You need something that allows removing the Etag from the response headers.

[Atavic]

Don't you use the js like your master does?

ESR with minor changes here.

[crssi]

OMG, I was in tiers laughing, even before way before you mentioned me. :)