Re: [IndexedDB] Granting storage quotas

This seems like a pretty interesting proposal.  I'm surprised it hasn't seen
any serious discussion.


That said, I think it'd be even more interesting if you add the concept of
"volatile" databases.  Basically these would consist of space the browser
will try to allocate and keep around but which have no guarantees of
persistence.  I.e. if the UA sees that the users hard disk is filling up,
later sees the site has been identified as bad (i.e. malware), hasn't been
used in a long time, etc, it's allowed to delete that space without any user
prompts.

Space explicitly requested would still be treated as mission critical (as it
is now...there was a long discussion about this on whatwg 6ish months ago),
but sites with more casual uses for space (for example caching--which was a
use case for the original SQL storage in gears) would not need to prompt.

I'd see volatility as a per-database setting.  For example, a mail client
could request space for drafts and emails it considers important and then
liberally download the rest of the users inbox.  Similarly, an image hosting
site could let users "upload" items even when offline but also be able to
aggressively cache images the user might want to see while offline.

J

On Tue, Apr 13, 2010 at 3:09 AM, Mark Seaborn <mseaborn@chromium.org> wrote:

> 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/IndexedDBprovide 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/
>
>