Open Bug 1305665 Opened 8 years ago Updated 1 year ago

Consider removing origin groups for storage usage

Categories

(Core :: Storage: Quota Manager, defect, P3)

defect

Tracking

()

People

(Reporter: annevk, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: dev-doc-needed)

Currently we couple various domains together such as en.wikipedia.org and jp.wikipedia.org because they share a common public suffix (wikipedia.org) and give them a combined storage quota.

We do this to protect the user from someone creating many subdomains and filling the storage quota in each.

The alternative is creating many domains, which requires more cash and is therefore a less likely attack.

However, grouping subdomains together also makes it harder for larger sites to make use of storage, unless they register themselves as public suffix.

Since we have a maximum for storage and we use LRU to clear entries, should we really concern ourselves with attacks? Sure, if the user gets their storage attack once their next visit to favorite sites might go a little slower, but such attacks will also get flagged and banned (by malware protection and such) and have only a little bit of impact.

On the flipside, requiring legitimate use cases to go through the public suffix registry is onerous and some cannot even do that as it would mean their cookies would no longer be shared either, so they'd lose centralized login (this is the case for Wikipedia I believe).

I therefore think we should get rid of this limitation and just have a global quota and a per-origin quota.
Priority: -- → P3
Here's a concrete idea to improve LRU to make attacks harder: We introduce a two-step process when freeing up storage. First, we remove data older than X (e.g., six months or a year). Second, we remove data that was used the least amount of time. We calculate amount of time by subtracting first time something was stored from the last time storage was touched.

This way recent data that was used for a long time will likely not be removed and old data that was used for a long time back then will still go away.

Jan might be able to come up with a slightly more ambitious algorithm where we instead calculate a weight for each origin based on recency and time used.
Blocks: 1064466
Blocks: 1374970
Component: DOM → DOM: Quota Manager

This was effectively done by the enablement of LSNG, which raised the group quota from 5MB to 10GB, and applied the 5MB quota at the origin level instead. This rolled out in Firefox 92, https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/92.

Details in bug 1064466 comment #40.

Severity: normal → S3

(In reply to Timo Tijhof from comment #2)

This was effectively done by the enablement of LSNG, which raised the group quota from 5MB to 10GB, and applied the 5MB quota at the origin level instead. This rolled out in Firefox 92, https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/92.

To elaborate on this since there is some ambiguity: The problem of a group limit impacting LocalStorage has been mooted by those changes. It is now unlikely that LocalStorage on multiple origins under a single site/group will cause quota problems for each other because it would take at least 1,000 origins maxing out their quota usage.

However, the group limit continues to exist and it continues to potentially impact the interaction of origins under the same site/group. (And in fact an origin saturating the group limit for its site could in fact cause problems for LocalStorage usage for other origins under the same site/group.

For doc purposes, note that when we remove the group limit, there will likely be a paragraph discussed here that should be removed.

You need to log in before you can comment on or make changes to this bug.