#1129: Incubation: `CrashReportStorage` API

Visit on Github.

Opened Aug 1, 2025

Explainer

https://github.com/WICG/crash-reporting/blob/gh-pages/crashReport-explainer.md

The explainer

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/wicg/crash-reporting
  • Primary contacts:
    • Dominic Farolino (@domfarolino), Google, software engineer
  • Organization/project driving the design: Google Chrome
  • This work is being funded by: Google Chrome
  • Incubation and standards groups that have discussed the design:
    • WICG
  • Standards group(s) that you expect to discuss and/or adopt this work when it's ready: Web Performance Working Group

Feedback so far

You should also know that...

The spec PR has been published at https://github.com/WICG/crash-reporting/pull/37.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1129

Discussions

Log in to see TAG-private discussions.

Discussed Aug 11, 2025 (See Github)

skipping

Comment by @yoavweiss Aug 20, 2025 (See Github)

Could the fetchLater API be used as an alternative to this proposal, enabling applications to send state information in parallel to crash reports? If not, it might be worthwhile to add the the "considered alternatives" section

Discussed Aug 25, 2025 (See Github)

Christian: I lost my script, sorry.

Lola: I sent you a link it is in the chat.

Christian: it is a small API, it sets context in case a crash happens. It is somehow a storage. The piece of the API seems fine and validated by JEffrey. This is not the entire review of the overall API but this smaller piece seems fine so I sugegst we go with the validated comment.

Lola: is this smaller part of the crash report API?

Christian: yes

Lola: does it mean we agree with that?

Christian: yes, validated. If agreed by you we can close it.

Lola: it looks like Jeffrey reviewed it as well.

Christian: yes.

Comment by @christianliebel Aug 28, 2025 (See Github)

@domfarolino Thanks for your proposal. We understand this is the "storage" part of a larger effort called Crash Reporting API. The CrashReportStorage API would allow authors to provide additional context to be added to a crash report, should the site crash later.

Please note that the following review focuses on the CrashReportStorage API in the context of the Crash Reporting API. Specifically, this is not a review of the Crash Reporting API as a whole.

The API surface is minimal and fulfills the requirements of your use case. As your proposal deviates quite a bit from usual storage APIs (not asynchronous, write-only), we would like to ask you to reconsider the API's name. For example, CrashReportContext may work to meet developers' expectations.

If developers forget to remove a key after a critical operation, the information will stick around for the rest of the storage's lifetime, which is "TBD," but probably more ephemeral than sessionStorage. As the information will remain allocated in memory, we ask you to define storage limits or eviction criteria more clearly.

The security and privacy self-review questionnaire is incomplete. We do not expect issues, though, as authors can already send crash reporting context to backend services using alternative ways. We would appreciate it if you could add them (for example, fetchLater() as suggested by @yoavweiss) to your "Alternatives considered" section and explain why your API is still needed.

The question of which documents can add crash report context (e.g., in a micro-frontend scenario with multiple same-origin iframes loaded) is unanswered, but it seems quite critical to produce helpful crash reports.

All in all, we're closing this early review as validated and welcome another review once the proposal is more polished.