StorageManager.estimate is misleading when persistence has been granted - returns group limit if restrictions were in place - always returns 2 GiB with sufficient free disk space
Categories
(Core :: Storage: Quota Manager, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox97 | --- | fixed |
People
(Reporter: lgrahl, Assigned: janv)
References
Details
Attachments
(1 file)
I tested the StorageManager
API and the estimate
method always seems to return 2 GiB regardless of how much more disk space is available. Now, I haven't artificially reduced the disk space to less than 2 GiB, so I can't say anything about that scenario.
However, when allocating data, e.g. by using IndexedDb, one can store much more than 2 GiB. I stopped my test after having stored 12 GiB of random data.
What are the plans here? Is a) estimate
currently a stub value, b) is this a bug, or c) are there plans to reduce the amount of storable data to 2 GiB?
Comment 1•5 years ago
|
||
The intent is that what estimate() reports is the limit that's enforced against which would be 2GB per policy (https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria), so this seems like it would be a bug. (Or a weird policy decision we should revisit, although exposing the actual free space limit does then create fingerprinting problems that I thought we were avoiding...)
Can you clarify if your origin has used navigator.storage.persist()
previously? This would be reflected by the presence of "Store Data in Persistent Storage" in the door-hangar panel that appears when clicking on the icons to the left of the URL in the URL bar where the lock icon and permissions icon appear (which is a 2x2 grid of circles and lines).
Also, based on the bug settings, can you confirm if this is on release?
Reporter | ||
Comment 2•5 years ago
|
||
When I was testing that, there didn't seem to be a difference whether that permission has been granted or not. But I might be wrong and it could be that I granted the permission previously and then withdrew it. Anyhow, tested with 70.0.1 now and I get a QuotaExceededError
as expected. When granting the persistent storage permission, the estimate is still 2 GiB but I can go beyond that limitation. That behaviour would be perfectly fine from my perspective if it's simply to avoid fingerprinting as long as it's documented. But can you elaborate on whether there is a restriction for the with persistent storage permission case?
Also, kudos to the team to not go the Google route (having the notification permission implicitly grant the persistent storage permission... and no other way in obtaining it deterministically... sigh... so frustrating!).
By the way, this is a small tool I wrote for the purpose of testing: storage-testing (source).
Comment 3•5 years ago
|
||
Neat tool! Thanks for linking it!
All restrictions are relaxed in the case where persist() is granted. Our behavior could certainly be improved here. We generally need to improve our quota management strategy, but the finger-printing risk in this specific case means we probably should not attempt a simple fix on this immediately. (Noting that it's a given that the ability to try and consume disk space until errors are experienced means that there are still the side-channel leaks we're concerned about in bug 1552848.)
Assignee | ||
Updated•3 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Depends on D130760
Comment 6•3 years ago
|
||
bugherder |
Description
•