Re: [IndexedDB] Granting storage quotas

On Tue, Apr 20, 2010 at 3:19 PM, Jeremy Orlow <jorlow@chromium.org> wrote:
> This way of thinking is incompatible with offline web apps.  If I'm offline
> and I "send" and email, it needs to stay queued up to send until I'm
> reconnected to the internet.
>
> Anyone wanting to debate whether or not the UA should be free to clean up
> "persistent storage" without asking the user should read
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/thread.html#22289 and
> the various other threads it spawned first and only re-start things if they
> have new information to add.

Indeed.

Per the other thread, a relatively simple approach that keeps popping
up, and which Michael raised here as well, is the idea of splitting up
storage into just two basic categories:
transient/purgable/cache/short-term and long-term/"permanent".

These two categories represent, I believe, the most useful
distinction, because these are categories that we can then translate
directly into differing UA behaviors.

Transient storage doesn't need a user's direct input to be used.  Much
like cookies, by default sites can use transient storage silently and
as much as they want.  However, the UA is free to put whatever limits
it desires on total transient storage available, and have whatever
cache eviction policies it wants in order to cull space when things
start to get full.

The only thing we may want to provide to the app is a way to query
"probably available space".  This would tell the app approximately how
much space the UA estimates the app can use before risking running
into problems.  It is only an estimate, however.  This sort of
information is necessary for an app to be able to distinguish between
a desktop browser with a full-sized hard drive, a mobile browser with
limited space, and a device with no long-term storage.  It also allows
direct interaction with user preferences, so that a user may choose
between the easily-understandable options of "Lots of Space", "Limited
Space", and "No Space" as the default grant to webapps.

Permanent storage *does* need a user's direct input.  This should
*not* be through a script-originated modal dialog.  The best way to
trigger something through user input is to use the markup designed to
capture user input - <input>s!  There are various ways that this sort
of thing can be usefully exposed.  For things like LocalStorage and
IndexedDatabase, the user would interact with a specialized <input>
that would create an appropriate storage space and fire some event.
For things like FileWriter, we could instead expose an ordinary Save
File dialog which would act similarly.  The common thread is just that
the user directly activates something on their own, and *only then* is
presented with a dialog of some kind to decide on the specific
options.  This is the place where requesting quotas can be useful.

Apps can be built to use both kinds of storage seamlessly this way.
An email app, frex, can by default save drafts in temporary storage
(no need to ask the user, but subject to eviction), but if the user
grants it file access, it can instead save them into a directory
structure on the hard drive.

This sort of approach also addresses the issues brought up in the OP.
An app needing a large grant can just ask the user to click on an
<input type=storage quota=1G> button, which is relatively safe.
Simultaneously, an evil app can't really exploit any holes in the
grant procedure, because the only storage it gets automatically is
implicitly both transient and subject to UA automatic controls.  Worst
case, a UA doesn't do anything special and the evil site just clobbers
all the other temporary storage.  Best case, the UA uses an
intelligent eviction algorithm that makes more established data more
resistant to eviction.

Making this sort of distinction means, of course, that *all* currently
specified storage types are transient.

~TJ

Received on Tuesday, 20 April 2010 22:58:51 UTC