IndexedDB is one kind of client-side storage which is used by all major browsers. A Mozilla security review (published in 2010 apparently before it was introduced in Firefox) says: Nevertheless it makes it easier to fingerprint your browser particularly if you visit specific sites regularly which make use of it. You can disable it in about:config by setting dom.indexedDB.enabled to false - but unfortunately this breaks several sites. (For example, I've noticed that parts of the New York Times home page are not displayed.) This is probably the reason why it is still enabled in the gHacks user.js. So how can we deal with this problem? AFAIK, there are 2 solutions: 1. There is the Disable IndexedDB add-on. Unfortunately, exceptions for specific sites are not possible (so you have to manually allow IndexedDB for them). Furthermore, we don't know if it will still be available for Firefox 57+ as it isn't a webextension. 2. In your Firefox profile is a folder called storage which in turn contains the three subfolders default, permanent and temporary. The permanent folder is obviously used by some add-ons and should probably not be touched. Now the trick is to delete everything which is in the default and temporary folders (you'll find most probably entries from various websites) and make those two folders read-only. Needless to say, that dom.indexedDB.enabled should be left set to true. I've tried the second solution and haven't run into any problems on sites which make use of IndexedDB. It seems that those sites still think that IndexedDB is available although they cannot write to those folders mentioned above. You might want to try out this trick and report your findings!
This is incorrect. The ghacks user.js has never had this preference, i.e indexedDB, enabled. I know because I am the author. You can still see v11 at https://www.ghacks.net/2015/08/18/a-comprehensive-list-of-firefox-privacy-and-security-settings/ and download the zip to check if you want. FYI: The ghacks user.js has been operating at github for the last five months - https://github.com/ghacksuserjs/ghacks-user.js As for a solution. First of all, the 3rd party cookie option limits 3rd party access to indexedDB (and more) see https://github.com/ghacksuserjs/ghacks-user.js/issues/159 . My suggestion for sites this is REALLY needed on (personally I have never found the need), is to use multiple profiles - for those who need some help, see our Wiki at https://github.com/ghacksuserjs/ghacks-user.js/wiki which has info on setting up and running concurrent profiles with both installed and portable Firefoxes
Thanks, so you surely know better. However, that site I linked to says in the "Changed" section: But indeed, I see that it's disabled here. As mentioned, one site that needs it is the New York Times - parts of that site are not displayed/loaded if indexedDB is disabled. And yes, different profiles are certainly another possibility - but a cumbersome, IMHO. But each to his own.
Ahh sorry about that. That change is incorrectly listed/worded, as the extension handled it. It was left disabled as you can see from the actual updated linked article and the downloaded associated files. My fault - rush job and all that to get it done in time for Martin. That extension is exactly the one you mention in the first post - however, it is not e10s compliant, and it cannot be made into a web extension AFAIK since WE cannot touch internals such as prefs - which is what that addon does - it simply toggles a pref. Yes, there are a lot of sites that this will cause some sort of breakage - that's to be expected. But its nothing that I personally can't do without. Multiple profiles is not that big a deal. Looking at it again, besides the 3rd party cookie setting (which you have not commented on), there is also site exceptions - as stated in the user.js. i.e urlbar info icon > right arrow > more information > permissions > maintain offline storage. Have you tried this? Its been a while, and permissions for indexed DB may have changed, but it should work. Set the pref to false but on the Times New York site you should see an extra icon in the urlbar after the info icon, which you can hover over and it will say "You have blocked data storage for this website" - click it and follow your nose.
Also FPI (first party isolation) should cover indexedDB. I'll have to check and get back to you on that, but I believe it's been covered (see https://bugzilla.mozilla.org/show_bug.cgi?id=744466 which is a duplicate of the resolved ticket but uses the words you are looking for , https://bugzilla.mozilla.org/show_bug.cgi?id=1264567 which are the tests). So you have a range of solutions: FPI, site exceptions (assuming your test at New York Times shows that site exception setting controls indexedDB), multiple profiles.
Thanks for your suggestions. Multiple profiles are out of question - I don't want to use a different profile just in order to load, e.g., the NYT website. Regarding site exceptions: Unfortunately, indexedDB is not controlled. Regarding First Party Isolation: I have to look into it. I don't know how it works and how to make use of it.
Thanks for the info on site exception not controlling indexedDB. FPI is essentially isolating everything based on the first party (domain) - also referred to as Origin Attributes, and was/is a Tor project/initiative that is part of the tor uplift. The way I understand it is that if you went to say NYT (New York Times) and the site also loaded 3rd party cookies/cache/dom storage/indexedDB/etc stuff for GA (google analytics), these would be "contained" as NYT's "stuff". If you then went to another site (let's say The Guardian) which also wanted to send you all the GA rubbish, then it would be a separate "container" or instance of it. No two instances/containers can talk to each other - they's isolated. So in effect, you can allow all cookies, all dom storage, indexedDB etc etc etc - and none of them could talk to each other. Not that you wouldn't want to block most of that crap anyway - but this way, you can allow the web to function with little to no breakage. It's still not perfect due to cross domain issues such as logins etc (eg google accounts on youtube and so on) https://www.torproject.org/projects/torbrowser/design/ - scroll down to 4.5. Cross-Origin Identifier Unlinkability It also goes beyond just that: see 2997 in the ghacks user.js and also this topic: https://github.com/ghacksuserjs/ghacks-user.js/issues/8 Edit: Maintain Offline Storage is definitely meant to control indexedDB - we're digging into this and if need be will land a ticket
Thanks for your info. Actually, I had read about FPI before and had also had a look at the torproject document. What I specifically meant: If site exceptions do not control indexedDB (as it seems to be a different kind of client-side storage), I'm not sure if FPI does (or if it's somewhere configurable). But I've seen your "Edit" and I'm looking forward for the results of your digging. EDIT: I set privacy.firstparty.isolate to true, and now I'm seeing in ~/.mozilla/firefox/profile/storage/default entries like: Code: https+++www.youtube.com^firstPartyDomain=youtube.com So this suggests that it is indeed controlled by FPI. On the other hand this doesn't protect against fingerprinting by the those sites. So I would prefer to avoid indexedDB as a principle, and the suggestion form my first post seems to work. Other types of local storage can be deleted (on a regular basis) by add-ons like uMatrix - hopefully still from FF v. 57 upwards.
