Web Storage Durability

W3C Editor's Draft

This version
https://github.com/slightlyoff/StorageDurability/tree/master/spec/index.html
Latest editor's draft
https://github.com/slightlyoff/StorageDurability/tree/master/spec/index.html
Previous version
http://www.w3.org/TR/background-synchronization/
Revision history
https://github.com/slightlyoff/StorageDurability/commits/master
Participate
Discuss on public-webapps@w3.org (Web Applications Working Group)
File bugs
Editors
Alex Russell, Google, <>
Josh Karlin, Google, <>

Copyright © 2014 W3C© (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

Abstract

This specification describes a method that enables web applications to request that storage for their origin be considered "durable".

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document was published by the TODO Working Group as an Editor's Draft. If you wish to make comments regarding this document, please send them to public-TODO@w3.org (subscribe, archives). All feedback is welcome.

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

Introduction

About this Document

All diagrams, examples, notes, are non-normative, as well as sections explicitly marked as non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification.

Any point, at which a conforming UA must make decisions about the state or reaction to the state of the conceptual model, is captured as algorithm. The algorithms are defined in terms of processing equivalence. The processing equivalence is a constraint imposed on the algorithm implementors, requiring the output of the both UA-implemented and the specified algorithm to be exactly the same for all inputs.

Dependencies

This document relies on the following specifications:

Motivations

Web Applications traditionally assume that local storage is ephemeral and can be erased at any time, e.g. through the pervasive "cache clearing" mechanism in browsers.

Many applications desire more durable storage in order to avoid being lumped in with "regular" web pages when caches and data are cleared by user agents.

Several mechanisms have been proposed or deployed to date to effect storage durabiltiy, notably HTML5 Peristent FileSystem storage and the "unlimitedStorage" permission in Chrome Extensions. These systems either suffer being storage-type specific, not widely supported, or both.

We propose a new, origin-wide permission which make a stronger assertion about the durability of granted quota, akin to the Persistent Storage system already found in Filesystems. This API does not remove the ability for UA's to provide controls for clearing this storage, but it does opt origins which are granted Durable Storage into a different, less-likely-to-be-cleared "bucket". These buckets and user controls over them are UA-specific. At an API level, all quota granted to such origins is reported to be "persistent".

Concepts

TODO

Security Considerations

TODO

Storage Considerations

Appendix A: Algorithms

Underscored functions and attributes are UA-internal properties.

Registration

TODO

Acknowledgements

Thanks go to ....

The authors would also like to thank Jeffery Yasskin for his scripts and formatting tools which have been essential in the production of this specification.