(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
Link to entry on the feature dashboard