- From: Mark Seaborn <mseaborn@chromium.org>
- Date: Tue, 13 Apr 2010 11:09:14 +0100
- To: public-webapps@w3.org
- Message-ID: <s2ye1cf9ca11004130309p258cd393ica7fc110fbcdc8e2@mail.gmail.com>
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/
Received on Tuesday, 13 April 2010 10:09:49 UTC