[whatwg] Web Storage: apparent contradiction in spec

[Brady Eidson]

On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:

> On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson <beidson at apple.com>  
> wrote:
> On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:
>
>> It is important that all local state be treated as a cache. 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. Better user agents will have better  
>> garbage collection algorithms.
>>
>> It would be better to remove section 4.3.
>
> I disagree.
>
> One key advantage of LocalStorage and Databases over cookies is that  
> they *do* have a predictable, persistent lifetime, and the browser  
> is *not* allowed to prune them at will.
>
> User agents are perfectly allowed to not allow new items to go into  
> LocalStorage or Database Storage once some quota is met, or if the  
> user has disabled it for that domain, or disabled it altogether, or  
> if the disk is filling up, or any other number of circumstances.
>
> But once the data is stored, it should be considered user data - as  
> "sacred" as a user's file on the file system.
>
> What happens when your computer blows up?

You lose the data the same way you lose your local file data.

> When you switch browsers?

Unfortunately the same thing that happens with your bookmarks,  
preferences, history, etc - unless the new browser knows how to import  
the old data.

No one would ever claim a browser should be able to arbitrarily prune  
a user's bookmarks "just because you might lose them when switching  
browsers."  If someone would claim that, I would raise this same  
objection.

> What about when you re-install your OS?

Same thing as with local files - if you didn't backup your hard disk,  
you lose them.  If you do backup your hard disk and restore files  
after you re-install your OS, you get your localstorage, databases,  
and hell - even your Flash cookies back, just like your files.

> What about mobile devices where 5mb is actually a lot of space?

These mobile devices are perfectly allowed to restrict the amount of  
data they agree to store with respect to their limited capacity.

> What happens when a malicious site fills up all of your localStorage  
> space?

This is why per-security-origin quotas exist.  For the counter  
argument of "what about a site that switches subdomains to subvert the  
per-origin quota?", fortunately HTML5 doesn't disallow browsers from  
limiting per top-level domain or via some other extra limitation.

> You're saying the UAs should not be free to have heuristics about  
> what to delete?

Yes.

> What do they do then?

They should be free to have whatever heuristics they'd like when  
choosing what to store.  But once it's stored, it should be persistent.

When a user's hard drive on a desktop machine fills up, should the  
operating system be able to decide "Oh crap, I'm running out of space,  
and I have no other caches or temporary data to delete.  So I'll just  
go ahead and start deleting the user's files without asking?"

LocalStorage is quite clearly modeled after Flash's LocalStorage -  
what does Flash do?  It has all sorts of controls in place to limit  
what data is stored.  But once the data *is* stored, does it ever  
arbitrarily decide to delete it?

> Note this exact point has been discussed on this list before, and  
> IIRC the outcome was that localStorage should be treated like  
> cookies: we'll try to keep them around, but the app should be  
> resilient to them going away.

This exact point has been discussed on this list more than once, and  
I've only ever seen it die out with no consensus.  If the discussion  
took place and it *was* decided that "User Agents should arbitrarily  
be able to decide to delete LocalStorage or database data without the  
user pre-clearing that action," then I'm afraid I missed it and I am  
raising my objection now.

~Brady

>
> J

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