Re: [w3ctag/design-reviews] Storage Corruption Review explainer (#419)

Thanks for the early feedback.  Sorry for the delay responding.

The explainer could definitely do a better job explaining the use cases.  I think the main ones are:

1. Provide health monitoring for sites relying on browser storage.  The sites I talk to pay close attention to this kind of thing because storage problems can be sticky and costly to recover from for their users.
2. Provide a standard way for sites to be notified of problems so they can possibly write recovery mechanisms (delete and resync from server, etc).

Both of these become more important if we standardize what action the browser takes by default when storage corruption is encountered.  In many cases we want to auto-wipe the origin, but that is problematic if we don't have a way to tell sites it happened.  Some sites also want to set policies to opt-out of auto-wiping in which case they need some notification mechanism to take their own action.

In regards to throwing exceptions there are a number of reasons that is more difficult:

1. It would be a huge API surface area to try to standardize new exception behavior.  This would be a lot of work both for browsers but for sites to update to expect these exceptions, etc.
2. There are cases where corruption affects more storage subsystems than just the last one you called a method on.  If a shared database like sqlite or leveldb is corrupt then it might break IDB and cache_storage, etc.
3. There are cases where the browser can run into storage corruption while performing background operations like quota computation, service worker updates, etc.  There is no method to throw from in this case.

All that being said, its unclear the way forward on this currently.  One of the pieces of feedback I got at TPAC was that Reporting API and ReportingObserver don't work quite as I thought.  Some folks would prefer to build custom notification API surface on StorageManager while others would like to see us improve Reporting API/ReportingObserver.

At this point I got the impression from TPAC that there is some agreement on use cases, but lack of clarity on API shape.  Unfortunately this is also not my highest priority, so I may be slow to update the explainer and reshape the proposal.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/419#issuecomment-537066070