While I appreciate the work done I feel this is conceptually problematic and is somewhat nefarious in nature, just like "evercookie" that it's based on. > clea

While I appreciate the work done I feel this is conceptually problematic and is somewhat nefarious in nature, just like "evercookie" that it's based on. > 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. When a user (especially a non-technical one) clears cookies, their sole objective is to remove their identity and "start fresh". That's the expected outcome and this library violates that expectation. Also, the reason the browser "unceremoniously deletes" some storage areas is because they are not meant to hold 100% persistent data. So in both cases, the "right" thing to do is respect the end goal of the action and not restore it. Furthermore, this library should not be used for sensitive data but likely will. This is because sensitive data should not be stored in local storage but rather in cookies [0] as they have better security options with "httponly" mitigating leaks via XSS and scope narrowing with Domain and Path. Local Storage is available to any script on the domain including any 3rd party script in the page. > Strikes an equitable balance between reliability and respect for the user. That's a fancy way of saying "Doesn't fully respect the user". [0] https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#Local_Storage https://www.owasp.org/index.php/HTML5_Security_Cheat_Sheet#L...