W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: [IndexedDB] Granting storage quotas

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 28 Apr 2010 16:53:05 -0700
Message-ID: <m2wdd0fbad1004281653qd0bdc01cpf9bb7d88e7e08c05@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Michael Nordman <michaeln@google.com>, Dumitru Daniliuc <dumi@chromium.org>, Shawn Wilsher <sdwilsh@mozilla.com>, Nikunj Mehta <nikunj@o-micron.com>, Mike Clement <mikec@google.com>, public-webapps@w3.org
On Wed, Apr 28, 2010 at 4:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Apr 28, 2010 at 4:03 PM, Michael Nordman <michaeln@google.com> wrote:
>> We have in mind that the incentives for developers to not always utilize the
>> most permanent storage option are...
>> 1) Non-permanent storage is accessible w/o explicit user opt-in, so less
>> annoying UI.
>
> This is interesting. I think that we'll want to allow sites some
> amount of permanent storage without explicit user opt-in. Though we
> could allow much more for the "caching storage". This sounds like a
> very good idea.

The problems with allowing permanent no-user-ask storage have already
been hashed out.  It's impossible to do right - either you're too
lenient (amount per subdomain) and malicious sites can fill up your
permanent storage trivially by using iframes to subdomains, or you're
too strict (amount per domain, or disallowing storage in nested
browsing contexts) which kills a lot of legitimate and good use-cases.

Tying permanence to user opt-in, and specifically to proactive user
opt-in rather than a script-triggered dialog (modal or otherwise),
appears to be the only way to chart the appropriate course between
power and protection.


>> 2) Less of a burden to 'manage' the data if the user-agent will clean it up
>> for you.
>
> I'm not convinced this will be much of incentive. I think few sites
> are as interested in cleaning up the users hard drive as the user is.
> I can see many sites dropping data into the permanent storage and then
> caring very little when that is cleaned up. I'd imagine many ad
> networks would love it if it was never cleaned up.
>
> The incentive I had in mind was that if the UA decides it needs to
> purge data for a specific site, for example due to hitting some global
> quota, then we'd first clear out the data with the lowest level of
> permanence first. So it wouldn't make a difference if all data for a
> site is permanent, or if all of it is semi-permanent, in both cases
> it'd all get nuked.
>
> However if the site has some permanent and some semi-permanent, then
> we'd clear out the semi-permanent first and remeasure if we're up
> against the global quota still.
>
> But I also really like the idea of having less UI for semi-permanent.

Requiring a user to explicitly hit an <input> or similar to allocate
permanent storage should be enough to make sites use volatile storage
unless they really need permanence.

Expiring permanent storage automatically, though, means that I can
never be sure that my mail archives are actually secure on my
computer, even though I told Gmail to save it to my hard drive.  I can
never be sure that my draft emails are really saved, and won't
disappear.

I have no problem with a browser simply not *exposing* permanent
storage, and not allowing authors to request it.  But if any major
browser exposes a "permanent" storage that isn't actually permanent,
then we app developers no longer have a permanent storage to rely on.
It's simply gone, unless we put up a "Best viewed in anything but
Firefox" sticker.

On mobile platforms where storage is at a premium and it's much more
difficult for users to manipulate the filesystem, just don't allow
permanent storage.  But don't lie to the application and say you
support something that you explicitly don't.  Lying browsers cause
horrific confusion and bugs.  >_<

~TJ
Received on Wednesday, 28 April 2010 23:53:58 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:38 GMT