I think the way to read it is that, if any one of them is cleared (which happens involuntarily sometimes) it comes back, but if all are cleared at the same time then the data does go away.
A user might have their browsers set to clear cookies on close, but not other saved data.. in this way most sessions are closed. This works around that case.
If a user clears all app data for a site/domain then it will be cleared. If you want to work around this, you could utilize resources/assets from other domains in conjunction but it will be more complicated. I find that most of such cases are abused for unscrupulous tracking.
Then that’s inconsistent with the beginning of their readme:
> For example, clearing cookies is a common user action, even for non-technical users. And browsers will unceremoniously delete IndexedDB, LocalStorage, and/or SessionStorage without warning under storage pressure.
> ImmortalDB is resilient in the face of such events.
I guess that’s a good thing. I was worried about the next browser supercookie being made with a library like this.
>Its goal is to identify users after they've removed standard cookies and other privacy data such as Flash cookies (LSOs), HTML5 storage, SilverLight storage, and others.
AKA
>Its goal is to identify users after they've taken actions to not be identified
I don't think they're being inconsistent - intentionally clearing cookies is common, but clearing app storage less so. And the browser may purge app storage to reclaim space, but that leaves cookies. It's unlikely that both things will overlap unless the user deliberately clears both cookies and storage.
