1629200 - Storage estimate doesn't return correct usage and quota after persistent storage is granted

Status: RESOLVED DUPLICATE of bug 1593646

(Core :: Storage: StorageManager, defect, P3)

Description

[Xiyuan Liu]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36

Steps to reproduce:

1. Grant persistent storage with navigator.storage.persist()
2. Check usage and quota with navigator.storage.estimate()

Actual results:

Quota is still 2048MB. Usage is always 0.

Expected results:

Quota should be 50% of disk space. Usage should report the actual usage.

Comment 1

[Xiyuan Liu]

UA: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:75.0) Gecko/20100101 Firefox/75.0

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Tom Tung [:tt, :ttung]]

(In reply to Xiyuan Liu from comment #0)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36

Steps to reproduce:

1. Grant persistent storage with navigator.storage.persist()
2. Check usage and quota with navigator.storage.estimate()

Actual results:

Quota is still 2048MB. Usage is always 0.

That's a known issue for the current storage API.
The reasons for this are:

• Firefox gives more quota to the persisted storage than the best-effort storage
• We want to keep usage and quota nebulous to avoid the attacks from malicious websites.

For navigator.storage.estimate (from my understanding) is that most web developers care about the diff for quota and usage rather than the exact value of usage.

Combine things above, we implement storage API v1 as it is and this issue might not be fixed in the near future.

Comment 4

[Jan Varga [:janv]]

Well, bug 1374970 is a bit different issue, it doesn't mention navigator.storage.persist() at all.
I think a discussion about this issue started in bug 1267941 comment 35 and it seems we took the easier option, returning zero usage when an origin is persisted.

In theory, we could return exact group usage in both cases (not persisted/persisted), but as :asuth mentioned in bug 1593646 comment 3, we probably want to address bug 1552848 first.

Comment 5

[Xiyuan Liu]

Thanks for the prompt response. I agree that the security issue should be the top priority. Please keep us update!

Comment 6

[Xiyuan Liu]

A side note, how does today's estimate API prevent us from leaking opaque response? The estimate seems to be pretty granular.

Comment 7

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

(In reply to Xiyuan Liu from comment #6)

A side note, how does today's estimate API prevent us from leaking opaque response? The estimate seems to be pretty granular.

Opaque responses have random padding associated with them at a granularity that attempts to limit the amount of entropy that can be gained from repeated fetches and storage of the opaque responses.

Comment 8

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 9

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is P3 (Backlog,) indicating it has been triaged, the bug's Severity is being updated to S3 (normal.)