Is there any plan for involving the user in storage allocation decisions for
IndexedDB? [1]
For comparison, the WebStorage API [2] doesn't have any special support for
the user to make allocation choices. My understanding is that browsers have
a fixed storage limit per origin -- in Chromium, 5Mb per origin. The
problem with this model is that it is both too permissive and too
restrictive.
1) It is too restrictive because a user might want to grant a web app a
large quantity of storage -- perhaps gigabytes. (See use cases below.)
2) It is too permissive because it enforces no limit on the amount of space
a web app can use: A web app from example.com can create an unlimited
number of puppet subdomains: aaa.example.com, bbb.example.com, etc. It can
use aaa.example.com's 5Mb allocation by loading a script from
aaa.example.com in an iframe and communicating with it using postMessage().
Both WebStorage and and IndexedDB have sections titled "Blocking third-party
storage" which permit browsers to disallow access to local storage from
iframes. This could *potentially* address (2), although the specs frame
this as a privacy issue rather than a resource allocation issue. However,
if browsers opted to block local storage access in iframes, this would
reduce composability of web apps, because WebStorage/IndexedDB provide no
other way for one site to delegate access to its storage to another site.
Furthermore, leaving this unspecified dilutes the value of having a spec,
because there would be no behaviour that all web apps can depend on.
My proposal:
Add a requestQuota() interface to IndexedDB that allows a web app to ask for
an amount of storage.
The form of the request affects how it can be displayed to the user:
* Suppose this is a Javascript method call, e.g.
indexedDB.requestQuota(size_in_megabytes)
The request could be displayed as an info bar, which would be
displayed asynchronously, i.e. without the user clicking.
* Alternatively, the request could be attached to a DOM element
(e.g. an <input> element), which would be displayed as a button.
Clicking the button opens a dialog.
The dialog would display the amount of storage that the web app has
requested. The user can change the amount of storage, or grant the request
without change. The dialog might also display how much storage is currently
available on the user's device.
A site's quota would be zero by default, otherwise a web app can multiply
any non-zero limit by the number of domains is can invent, as described
above.
A quota would be an upper limit on the space a site can use, but it would
not be a guarantee that the space is available.
Use cases:
* An e-mail web app requests an amount of storage that is large enough to
store all your current e-mail, plus your e-mail for the next year at
projected rates. As this runs out, it can request more.
* A backup web app requests an amount that is large enough to store your
data.
Mark
[1] http://www.w3.org/TR/IndexedDB/
[2] http://dev.w3.org/html5/webstorage/
