- From: Andrew Sutherland <notifications@github.com>
- Date: Wed, 16 Oct 2024 08:18:23 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/431/2417141965@github.com>
Also related is the [management section of the storage spec](https://storage.spec.whatwg.org/#management) which says: > Whenever a [storage bucket](https://storage.spec.whatwg.org/#storage-bucket) is cleared by the user agent, it must be cleared in its entirety. User agents should avoid clearing [storage buckets](https://storage.spec.whatwg.org/#storage-bucket) while script that is able to access them is running, unless instructed otherwise by the user. Quoting https://github.com/w3c/IndexedDB/issues/431#issuecomment-2416017372 > One wrinkle I see in adopting this approach is the challenge of differentiating between sites that _currently don't handle these errors_ and sites that _don't intend to handle these errors_. I presume that we don't want to tell sites to "handle these errors by so-and-so milestone after which we'll wipe all your data if this error occurs". From my perspective, the dominant concern is site breakage and that it's hard for the browser to tell if a site is broken or not so it's safest to assume if we experience corruption and the site is not currently actively opted in to trying to handle it itself that we have to assume the site is broken. The only way to provide some kind of "deal with this in the future if you want" would be to do something like back-up the origin into a magic bucket, but this creates new privacy complications. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/431#issuecomment-2417141965 You are receiving this because you are subscribed to this thread. Message ID: <w3c/IndexedDB/issues/431/2417141965@github.com>
Received on Wednesday, 16 October 2024 15:18:27 UTC