IndexedDB support

[wavexx]

Aside from #44, persistent information can also be stored in IndexedDB and should be treated equally.
Is it possible to do this in FF57?

[wavexx]

And, sadly, there is also the "caches" DOM API (https://developer.mozilla.org/en-US/docs/Web/API/CacheStorage). Although it's not directly related to "local storage", it allows to keep a persistent local map which is under JS control of the page, and thus it can be used to create another form of supercookie.

[phonphen]

you can use this extension
it work only up ff 57 b3

https://addons.mozilla.org/en-US/firefox/addon/storagerazor/

[ke-d]

@phonphen Yeah you can use that extension. The only caveat is that it deletes ALL localstorage and IndexedDB on browser restart. The APIs I'm waiting for is deleting localstorage and IndexedDB by hostname.

The API for deleting localstorage by hostname landed in FF 58+. IndexedDB hasn't landed yet.

[Joel889]

Regarding the addon "storagerazor", doesn't Firefox 56 already delete the storage folder on startup when ticking the "Clear Offline Data"?

[Thorin-Oakenpants]

@Joel889 That FF56+ fix excludes moz-extension* directories in storage\default. I clear Offline Website Data (i.e indexedDB) on close, and also manually with Ctrl-Shift-Del and nothing is lost off disk. But yes, clear OWD = indexedDB = fixed in 56 - this is the ticket 1047098

For relevant info:

• FF58+: API for deleting localstorage by host landed - 1388428 <== @mrdokenny , is this only by host, or by time as well?
• FF57+: clearing of IDB in browsingData API - 1333050 <== @mrdokenny - I do not know if this allows by host (or by time)??

[bonanza123]

@mrdokenny Are there any news regarding this feature?

Edit: just noticed that progress is probably covered in #44
Maybe this issue can be closed then?

[ke-d]

@bonanza123 This is the meta bug for clearing browsingData for a single site.

https://bugzilla.mozilla.org/show_bug.cgi?id=1340511

IDB doesn't have a bug listed for clearing by host I believe unlike localstorage.

[Joel889]

Forget Me Not (https://addons.mozilla.org/en-US/firefox/addon/forget_me_not/) is able to clear IndexedDB. I don't think it works on a per site basis, but it was able to clear all IndexedDB's, which is a good interim solution for me.

[ke-d]

@Joel889 The reason why I don't implement a clear all IndexedDB/localstorage on startup is that you can literally do the same thing in Clear all history when Firefox closes -> Settings

Offline Website Data deletes both Localstorage and IndexedDB (Edit: Also clears service workers too) from what I tested, and this works better than using extensions since they can only clean on startup.

[Joel889]

It works on demand too.

[Thorin-Oakenpants]

Offline Website Data deletes both Localstorage and IndexedDB (Edit: Also clears service workers too)

FYI: https://dxr.mozilla.org/mozilla-central/source/browser/modules/Sanitizer.jsm

• cookies option clears: cookies + deviceIds+ plugin data
• OWD clears : appCache+ localStorage+ serviceworkers cache+ QuotaManager (QM = IDB, asm-cache)

QuotaManager might include other some other stuff, I am not an expert :)

Edit: this is a work in progress I guess what with Storage Manager v2 etc. There are tickets about localStorage + IDB sharing QM, and QM being tied to cookies. Those sound good - when you delete a cookie it also deletes QM. Hopefully down the track it will cover all local persistent data will be tied together and you will only have to make one API call by host or time/range

[gwarser]

Intent to implement: Clear-Site-Data header

[muckfs]

Since there is no progress on API for this in a while, how about making a simple temporary workaround altering the global methods and properties to block them, e.g. window.indexedDB = {}. This should be easy to implement on per host basis, it will not fully replace existing APIs, but it's better than completely disabling indexedDB because it allows whitelists.

[wavexx]

On Sat, Aug 11 2018, muckfs wrote: Since there is no progress on API for this in a while, how about making a simple temporary workaround altering the global methods and properties to block them, e.g. window.indexedDB = {}. This should be easy to implement on per host basis, it will not fully replace existing APIs, but it's better than completely disabling indexedDB because it allows whitelists.

I tried this approach with an userscript, but indexedDB being a native method couldn't be overridden this way. I hope a webextension can.

[muckfs]

I tried this approach with an userscript, but indexedDB being a native method couldn't be overridden this way.

The following works for me:
Object.defineProperty(window, 'indexedDB', {value: {}})

[wavexx]

On Sun, Aug 12 2018, muckfs wrote: I tried this approach with an userscript, but indexedDB being a native method couldn't be overridden this way. The following works for me: Object.defineProperty(window, 'indexedDB', {value: {}})

How did you test it? I tried the above using Greasemonkey with @run-at document-start, and while it does run and appears to work within the body of the user-script you can still see that the page has still access to it (try with the console, or under a web-page you have access to).

[muckfs]

How did you test it? I tried the above using Greasemonkey with @run-at document-start, and while it does run and appears to work within the body of the user-script you can still see that the page has still access to it (try with the console, or under a web-page you have access to).

I tried using Violentmonkey with @run-at document-start and tested with console. Works unless Violentmonkey fails to inject the script because of CSP.

[wavexx]

On Tue, Aug 14 2018, muckfs wrote: I tried using Violentmonkey with @run-at document-start and tested with console. Works unless Violentmonkey fails to inject the script because of CSP.

On Chrome/Chromium? I'm testing this on FF 62b16. Furthermore, Violentmonkey on FF doesn't guarantee that @run-at document-start will actually be delivered before the page JS is ran, making this sort of userscripts essentially useless. I'm not familiar with Violentmonkey on Chrome, but I had to switch to Greasemonkey again, despite it's new limited interface, because of this.

[muckfs]

On Chrome/Chromium?

I'm on FF 60.1.0

Furthermore, Violentmonkey on FF doesn't guarantee that @run-at document-start will actually be delivered before the page JS is ran, making this sort of userscripts essentially useless

That's why i want this to be implemented as Cookie AutoDelete option if current API allows to always run something before page JS.

[wavexx]

On Tue, Aug 14 2018, muckfs wrote: On Chrome/Chromium? I'm on FF 60.1.0

Somehow, I cannot make it work. Not even using Violentmonkey. The underlying webpage always has full indexedDB access.

That's why i want this to be implemented as Cookie AutoDelete option if current API allows to always run something before page JS.

I would also be a proponent of entirely disabling indexedDB (unless whitelisted) for a domain if auto-deletion is not available. I see an increasing amount of websites that store a single row in a db for just for tracking purposes. I have only one website over several thousands I visited that I see is using indexedDB for non-tracking purposes. I'm currently disabling indexedDB via about:config in my "harneded" profile for this reason.

[gwarser]

Did you try setting

// @grant none

or using unsafeWindow?

[bonanza123]

@mrdokenny is it correct that it is currently possible (in general, no withing CAD) to delete site data of all sites (but not on a per-domain basis)? If so, I think it would be nice to have an option to clear all site data only upon close of the browser. The reason is that currently (AFAIK) Firefox can only delete all data (cookies + site data) upon close, but I want to keep the cookies and I am willing to sacrifice the stored site data for more privacy.

[helgasoft]

I see an increasing amount of websites that store a single row in a db for just for tracking purposes.

Yes, correct observation.
Here is code for all databases deletion:

indexedDB.databases().then((r) => { for (var i=0; i<r.length; i++) { 
      indexedDB.deleteDatabase(r[i].name); 
} });

Currently works only in Chrome. Firefox returns 'indexedDB.databases is not a function' - probably it has not been implemented yet.
It is important to point out that indexedDB data is always URL bound and secured. Script running in urlA cannot access or delete indexedDB databases created by urlB. It can only delete urlA databases.
This could be as a much welcomed addition to CAD, like 'Clear databases for this domain (Chrome only)'.

[wavexx]

On Tue, Apr 30 2019, helgasoft wrote: Currently works only in **Chrome**. Firefox returns '_indexedDB.databases is not a function_' - probably it has not been implemented yet. It is important to point out that indexedDB data is always URL bound and secured.

The tracking implications are _huge_ even if just 1st party access is allowed. It doesn't cost much to relay a 3rd party script server-side, and this is going to get more and more common in the following years.

[kennethtran93]

Closing as browsers have yet to implement this cleaning by hostname. When it does feel free to open a new issue and reference a number of closed issues relating to indexedDB, or just comment on this one.

[FliegendeWurst]

This is implemented in Firefox 77 (not yet released): https://bugzilla.mozilla.org/show_bug.cgi?id=1551301

[stevenxxiu]

Firefox 77 is released now.

I'm on a Chrome-based browser, but would love this to be implemented.

Quite a lot of websites add IndexedDB tracking, that I often clean manually.

[kennethtran93]

Thanks. We'll try to get that in along with cache and service workers.

[kennethtran93]

Need some testers over at #798. To download the zip file, follow the latest instructions given through github-actions bot