1652461 - Introduce DirectoryLock::ReportCorruption to trigger clearing of the storage bucket via nsIClearDataService on dynamic corruption

Status: NEW

(Core :: Storage: Quota Manager, enhancement)

Description

[Andrew Sutherland [:asuth] (he/him)]

In the event of corruption in an origin, spec and consensus among implementations is a storage bucket.

In discussion in the past we determined that the DirectoryLock is the appropriate place for a client to report encountering corruption, as opposed to reporting it via nsIQuotaManagerService or a new interface on quota::Client instances. Because all access that might discover corruption must already be holding a DirectoryLock and the DirectoryLock identifies the client and the bucket, as well as having direct access to the underlying data structures, this does seem like a good choice.

This came up most recently in https://bugzilla.mozilla.org/show_bug.cgi?id=1644780#c20 but is a meta problem.

This would of course want telemetry.

And given that I believe we're on board with https://github.com/wanderview/storage-corruption-reporting/blob/master/explainer.md we likely want to plan to log that we cleared the origin in QMv4 metadata for the origin.

Note that:

1. Clearing should involve nsIClearDataService for completeness/consistency rather than be strictly internal to QuotaManager.
2. We should consider whether special handling is appropriate for LocalStorage (NextGen). If LocalStorage is corrupt, we absolutely need to clear it, but for legacy and practical reasons, it might make sense to treat LocalStorage similar to cookies (in that it can be used for login persistence that's orthogonal to richer storage).
   • Probably the right course of action is to clear LocalStorage but to make sure that our telemetry indicates the source of the corruption. If we're seeing disproportionately higher rates of corruption from storage other than LocalStorage which results in clearing LocalStorage, we would want to revisit as it's more likely for the loss of LocalStorage to be visible to users.
   • The motivating assumption is that some sites, for example chat.mozilla.org, store login credentials in LocalStorage. Because we limit cookies set via document.cookie to a maximum of 7 days of storage (because of tracking concerns), this has potentially shifted the equilibrium of storage for cases like this from cookies (which would not be cleared per the storage spec currently) to using LocalStorage more.

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

Bug 1694935 should have handled the case of database corruption being detected at initialization time, so this should likely now be more about dynamically detected corruption, which likely depends on bug 1125157 being addressed.