Consider raising hard 2 GiB limit on group/origin (sites shouldn't have to use navigator.storage.persist() which has other semantics to get more than 2GiB)
Categories
(Core :: Storage: Quota Manager, enhancement)
Tracking
()
People
(Reporter: asuth, Unassigned)
References
Details
Currently we enforce a hard 2 GiB limit on groups which also serves as the upper bound for origins. (Aside: Bug 1305665 covers getting rid of the concept of groups.)
I believe the choice to largely be a historical hand-waving choice of an upper bound to prevent runaway use of storage and not a permanent ideal decision.
While the longer term plan for storage caps is the granular use of multiple storage buckets, we should likely consider more immediate options. Note that all of our choices need to be aware that there are privacy/side-channel concerns about navigator.storage.estimate() exposing free disk space covered discussed in bug 1552848 and that the limitations of our current implementation (including not updating our concept of available disk space at runtime) are currently helpful in this regard.
Relevant docs:
- MDN's documentation of our storage limits
- Google web.dev's cross-browser summary on this.
Options:
- Just raise the cap to something higher, like 4 GiB.
- For side-channel concerns, this might mean we want to also change the effect quantization I document at https://bugzilla.mozilla.org/show_bug.cgi?id=1552848#c5 so the number of discrete values doesn't really change.
- Conditionally raise the cap based on the overall storage capacity of the drive in a very quantized fashion, like require that the pool of (used QM storage + free disk space) be at least 40G. nsIFile has free/available disk space checks, but not total disk size information.
- We could also see about adding support for being aware of the general disk size.
- We might also opt not to do this on android.
- Support a higher cap for sites that are top-level in a pinned tab as proxy for user interest in a site.
- Logistically, this would need to be a durable grant accomplished either via a bit in QM metadata and/or via the permission manager.
- Note that although bug 1422056 introduced support for partitioning permissions by OriginAttributes, it's controlled by pref and that pref is not flipped yet and bug 1641584 tracks enabling it in Nightly. So we'd need to be concerned about privacy leaks between containers if it's not possible to force the permission to use the OriginAttribute.
- Places is another potential source of intuiting site interaction, but I believe it explicitly is not aware of containers which makes it a real privacy problem.
|
||
Comment 2•3 years ago
|
||
We just raised the cap to 10GB for now.
Description
•