[whatwg] Web Storage: apparent contradiction in spec

Jeremy Orlow jorlow at chromium.org
Tue Aug 25 15:51:58 PDT 2009


On Tue, Aug 25, 2009 at 3:19 PM, Aaron Boodman <aa at google.com> wrote:

> On Tue, Aug 25, 2009 at 2:44 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
> > Ok, well I guess we should go ahead and have this discussion now.  :-)
>  Does
> > anyone outside of Apple and Google have an opinion on the matter (since I
> > think it's pretty clear where we both stand).
>
> FWIW, I tend to agree more with the Apple argument :). I agree that
> the multiple malicious subdomains thing is unfortunate. Maybe the
> quotas should be per eTLD instead of -- or in addition to --
> per-origin? Malicious developers could then use multiple eTLDs, but at
> that point there is a real cost.


This could be helpful.  I suppose UAs could do this today, even.


> Extensions are an example of an application that is less cloud-based.
> It would be unfortunate and weird for extension developers to have to
> worry about their storage getting tossed because the UA is running out
> of disk space.


Extensions are pretty far out of scope of the spec (at least for now),
right?  (Within Chrome, we can of course special case this.)


> It seems more like if that happens the UA should direct the user to UI
> to free up some storage. If quotas were enforced at the eTLD level,
> wouldn't this be really rare?


It would be on the desktop, but it probably won't be rare on mobile phones
(and maybe even netbooks).


On Tue, Aug 25, 2009 at 3:09 PM, Jens Alfke <snej at google.com> wrote:

> Interesting comments. Linus and Jeremy appear to be coming at this from a
> pure "cloud" perspective, where any important or persistent data is kept on
> a remote server and the browser, so local storage can be treated as merely a
> cache. That's definitely a valid position, but from my perspective, much of
> the impetus for having local storage is to be able to support *other* application
> models, where important data is stored locally. If browsers are free to
> dispose HTML5 local storage without the user's informed consent, such
> applications become dangerously unreliable.
> For example, Linus wrote:
>
> User agents need to be free to garbage collect any local state. If they
> can't then attackers (or the merely lazy) will be able to fill up the user's
> disk. We can't expect web sites or users to do the chore of taking out the
> garbage.
>
>
> Replace "user agent" -> "operating system" and "local state" -> "user
> files", and you have an argument that, when the hard disk in my MacBook gets
> too full, the OS should be free to start randomly deleting my local files to
> make room. This would be a really bad idea.
>

Well, it's certainly different from what we're used to.  I'm not convinced
it's wrong though.  The web has gotten by pretty well with such a model so
far.


> Similar analogies —
> • If the SD card in my Wii fills up, should the system automatically start
> deleting saved games?
> • If my iPhone's Flash disk gets full, should it start deleting photos?
> What if I haven't synced those photos to my iTunes yet?
>
> In each of those cases, what the device actually does is warns you about
> the lack of free space, and lets you choose what to get rid of.
>

It's worth noting that today, OSs do a pretty poor job of helping you with
this task.  (I don't see any reason why the spec will prohibit UAs from
creating a good UI for this, though.)


> Local storage is different from cloud storage. The HTML5 storage API can be
> used for both, so it shouldn't be limited to what's convenient for just one
> of them.
>

I still don't understand what use local storage has outside of 'cloud
storage'.  Even in the extensions use case (which I think is out of scope
for this spec), there's no reason you can't sync user preferences and such
to the cloud.

The only tricky thing I see here is enabling offline use of websites.  And I
don't think "keep local storage forever" is a very good solution, though I
agree it is _a_ solution for this use case.

By the way, in case it's not clear, my position is not that UAs should take
deleting user information lightly, my position is 1) this behavior should be
left up to the UA and 2) when possible, developers should keep information
in the cloud not local storage.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090825/159406a1/attachment-0002.htm>


More information about the whatwg mailing list