Intent to Implement: Durable Storage

[David Grogan]

Contact emails

dgr...@chromium.org, jsbell@chromium.org, sligh...@google.com

Spec

https://storage.spec.whatwg.org/

Summary

Allow origins to opt out of the browser's storage-eviction logic that is run when the user's storage space is running low.

Motivation

The web platform, as specified, doesn't require browsers to guarantee the lifetime of web storage (e.g. IndexedDB, WebSQL, Service Workers). In practice browsers implement storage on a "best-effort" basis: when an end-user's storage space runs low, they start deleting web storage. This means that there is no way for a music service to guarantee that the songs you saved for offline won't be deleted by the browser behind your back. To get around this shortcoming, developers either go native or use chrome apps and extensions with the "unlimitedStorage" permission.

Compatibility Risk

Low. Developers would already have to support users who deny this permission. If we decide to pull this from the platform the browser could act as if the user always denies permission.

Discussions with Mozilla have been productive; AnneVK is writing the spec. Microsoft orally noted that tackling this issue was not a high priority for them. Apple didn't engage on github (as far as I know) and we haven't yet reached out in person.

Ongoing technical constraints

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

At least 5. Consider this a solicitation for feasibility and implementation advice for Android WebView.

OWP launch tracking bug

http://crbug.com/502373

Link to entry on the feature dashboard

https://www.chromestatus.com/features/5715811364765696

Requesting approval to ship?

No

Discussion of the spec, down to whether the web needs this capability at all, should happen at https://github.com/whatwg/storage/issues.

[Alex Russell]

Very excited that this is moving forward. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Anne van Kesteren]

On Fri, Jun 19, 2015 at 10:07 PM, David Grogan <dgr...@chromium.org> wrote:
> Discussions with Mozilla have been productive; AnneVK is writing the spec.

The only bit of feedback I got was to replace persistentPermission()
with the Permissions API. If we can figure that out I think that'd be
sensible to change before shipping.


--
https://annevankesteren.nl/

[Alex Russell]

APIs should be stand-alone. It's fine to duplicate the request method with the Permissions API.

[Domenic Denicola]

Why are we even doing the permissions API then?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Jonas Sicking]

FWIW, last we talked about removing similar "check if I have
permission" functions (I think from push API) the holdup was that
Gecko still didn't have a permission API implementation.

That is currently in the works and so should no longer be a blocker.

/ Jonas

[Anne van Kesteren]

On Wed, Jul 15, 2015 at 3:18 PM, Alex Russell <sligh...@google.com> wrote:
> APIs should be stand-alone. It's fine to duplicate the request method with
> the Permissions API.

I agree with this. I looked at the API again and I think we actually
want to expose whether your default box is already persistent. I filed
https://github.com/whatwg/storage/issues/6 and
https://github.com/whatwg/storage/issues/7 to track this and would
appreciate feedback there.

I also filed an issue for restricting this to secure contexts
https://github.com/whatwg/storage/issues/5 which I think is
non-controversial. I'm mostly waiting for the secure context
definition to reach a more stable state.


--
https://annevankesteren.nl/