Storage Corruption Review explainer

[wanderview]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: Storage Corruption Review
• Specification URL: None yet
• Explainer (containing user needs and example code)¹: https://github.com/wanderview/storage-corruption-reporting/blob/master/explainer.md
• GitHub issues (if you prefer feedback filed there): https://github.com/wanderview/storage-corruption-reporting/issues
• Tests: None yet
• Primary contacts (and their relationship to the specification): @wanderview

Further details:

• Relevant time constraints or deadlines: [please provide]
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles
• The group where the work on this specification is: Planning to discuss at WebApps WG at TPAC.

We recommend the explainer to be in Markdown. On top of the usual information expected in the explainer, it is strongly recommended to add:

• Links to major pieces of multi-stakeholder review or discussion of this specification:
• Links to major unresolved issues or opposition with this specification:

You should also know that...

[please tell us anything you think is relevant to this review]

We'd prefer the TAG provide feedback as (please select one):

• open issues in our GitHub repo for each point of feedback
• open a single issue in our GitHub repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

---

Please preview the issue and check that the links work before submitting. In particular, if anything links to a URL which requires authentication (e.g. Google document), please make sure anyone with the link can access the document.

¹ For background, see our explanation of how to write a good explainer.

[cynthia]

We discussed this during the Tokyo F2F and could not understand the user (content developer, presumably) benefits of this - in particular because it feels like isn't much actionable work by having this information.

We noticed that in the alternatives there is a mention about throwing, which we do agree is a lot of work but makes it a bit more actionable. We're not quite sure how the flow would work when it comes to the current design.

What are the other implementor's thoughts on this?

[wanderview]

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.

[torgo]

We discussed briefly on the call today and agreed to put this review on ice (close this issue) for now. Please let us know when we should look at it again and we can re-open. Thanks!