Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Intent to ship: navigator.storage on Firefox for Android (Fennec)

49 views
Skip to first unread message

Andrew Sutherland

unread,
Jun 20, 2018, 3:56:08 PM6/20/18
to dev-pl...@lists.mozilla.org
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/-stfRvwwEHU/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

Tom Ritter

unread,
Jun 20, 2018, 5:27:06 PM6/20/18
to Andrew Sutherland, Mozilla
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
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
0 new messages