I'd just like to note that we still have https://bugzilla.mozilla.org/show_bug.cgi?id=1383656 open to figure out what is the best thing we can do with regards to making size-correlation-based attacks difficult. When navigator.storage was initially developed a low-effort-best-guess algorithm was put in ( https://bugzilla.mozilla.org/show_bug.cgi?id=1290481), but we never got around to figuring out what the best available one is.
-tom On Wed, Jun 20, 2018 at 12:55 PM, Andrew Sutherland < asutherl...@asutherland.org> wrote: > As of Firefox 63 we're hoping to turn navigator.storage > (StorageManager[1]) on by default for Firefox for Android (Fennec). It is > controlled by pref "dom.storageManager.enabled" and provides both the > storage.estimate() and storage.persist() API's[2]. > > We shipped navigator.storage for Desktop in Firefox 57 in > https://bugzilla.mozilla.org/show_bug.cgi?id=1399038. We did not enable > it for Android, probably over concerns about filling up mobile storage > because navigator.storage.persist() exempts an origin from QuotaManager > eviction and there is no UI on Fennec to show how much data various origins > are using and clear data on a per-origin basis. (The permission, however, > can be revoked when viewing a page on the origin.) > > The previous Intent to Ship for storage.estimate() can be found at > https://groups.google.com/d/msg/mozilla.dev.platform/-stfRvw > wEHU/J5P1mzlHAwAJ > > In https://bugzilla.mozilla.org/show_bug.cgi?id=1457973 we plan to enable > the pref for Android, potentially with mitigation. The minimal mitigating > actions I've proposed are: > > - Have navigator.storage.persist() resolve with false without prompting > the user, similar to how an internal error or user disapproval would be > treated. We would enable actual prompting and the actual permission once > there is UI in place to help users manage origin storage. > > - Potentially use a lower per-group cap than the 2 GiB currently used, at > least as reported by storage.estimate(). https://developer.mozilla.org/ > en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_ > eviction_criteria#Storage_limits covers our existing logic which was a > reasonable first-pass at capping usage, but is not great as an advisory > value for sites that might proactively engage in speculative precaching. > There are almost certainly smarter ways to handle this if anyone has time > to think about this and/or gather data! > > Your thoughts and other low-effort alternatives are appreciated! > > Andrew > > 1: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager > 2: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/persist > https://developer.mozilla.org/en-US/docs/Web/API/StorageManager/estimate > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
