You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seemed folks were generally agreeable to the use case of providing transparency. There are issues with using Reporting API, however. We discussed maybe exposing some reporting API surface of StorageManager instead.
Separately, though, @mikewest suggested we should try to improve Reporting API to support this reporting use case.
The text was updated successfully, but these errors were encountered:
I mentioned it in the other issue, but the use case that was compelling to me was not so much reporting, but being able to tell your bucket is corrupted and having control over how that's handled.
Reporting might be useful too, but it seems strictly less interesting. However, if when the user navigates to an origin and we detect the bucket for that origin is corrupted, what are the issues with using reporting infrastructure to report this?
Forked from #74.
I proposed a storage corruption proposal at TPAC:
https://github.com/wanderview/storage-corruption-reporting/blob/master/explainer.md
It seemed folks were generally agreeable to the use case of providing transparency. There are issues with using Reporting API, however. We discussed maybe exposing some reporting API surface of StorageManager instead.
Separately, though, @mikewest suggested we should try to improve Reporting API to support this reporting use case.
The text was updated successfully, but these errors were encountered: