Intent to Experiment: Durable Storage

[Owen]

(Note this feature was previously approved in an Intent to Ship but we have decided to run an origin trial first to gain extra developer feedback before going ahead, hence this new intent)

Contact emails

jsb...@chromium.org sligh...@chromium.org dmu...@chromium.org

Spec

https://storage.spec.whatwg.org/ - the navigator.storage.persist() and persisted() methods

TAG review issue: https://github.com/w3ctag/spec-reviews/issues/85

Note that discussions with Mozilla have been productive; Anne is writing the spec, and implementation is starting soon. Microsoft orally noted that tackling this issue was not a high priority for them.

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. For privacy reasons, the data is still cleared if the user invokes “clear browsing data”.

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 (for example) 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

Goals for experimentation

There are planned UI changes to accompany this feature but we’d like to have developers start using it to give us feedback without blocking on that. For example, the persist() method doesn’t prompt in Chrome; granting the permission is based entirely on user agent heuristics. The methods also return simple booleans reflecting the final state rather than a more complex prompt/denied/granted num, which “should” be all developers need, but we may be overlooking use cases.

Additionally we would like to gradually try different heuristics for when to allow developers to request durable storage and get feedback from developers on these heuristics.

Experimental timeline

The experiment is intended to run in Chrome 52, 53 and 54 in all channels.

Any risks when the experiment finishes?

If sites told users their data would be available offline but we remove support for this API there is a risk that the user will be surprised at the storage being lost. This is not perceived to be a big risk though since we do anticipate shipping the semantics even if the syntax changes somewhat, and since the origin trials system is designed to only encourage testing of experimental features in prototypes.

Ongoing technical constraints

None - this is implemented as a permission that influences the eviction logic, not a separate storage bucket that would e.g. require data migration.

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

Not supported on Android WebView because durable storage is only granted to sites that have sufficient ‘site engagement’ (not supported in WebView), have been bookmarked, or have been added to home screen.

OWP launch tracking bug

http://crbug.com/502373

Link to entry on the feature dashboard

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

[Owen]

cc jsbell, slightlyoff, dmurph

[Jason Chase]

We’ve reached the branch point for M54, so here’s an update on the Persistent Storage feature usage in the origin trial. We (the origin trials team), have been periodically capturing the usage stats. Similar to Chrome Status, the numbers represent the percentages of Chrome page loads.

Peak usage: <= 0.0001% (weekly usage)

Average usage: <= 0.0001% (average of weekly usage)

Thanks,

Jason

[dk...@google.com]

Thanks for posting these numbers, Jason! We've worked with a few developers who incorporated this into smaller personal apps, and Docs reviewed the API (but did not implement). The general feedback we received was:

• A need for additional granting heuristics (site engagement, add to homescreen, push notifications)
• Decided on a plan for revoking the permission automatically (if site data is cleared twice in a row)
• Somewhat elevated the priority of storage boxes/pressure events since some sites expressed a desire to use them in tandem

Overall, we gained a good amount of insights and we're planning to ship the API in M55 with a lot more confidence!