<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 25, 2009, at 2:16 PM, Jeremy Orlow wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div class="gmail_quote">On Tue, Aug 25, 2009 at 2:09 PM, Brady Eidson <span dir="ltr"><<a href="mailto:beidson@apple.com">beidson@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word"><div class="im"><div>On Aug 25, 2009, at 1:38 PM, Linus Upson wrote:</div></div><div><div><div class="im"><br><blockquote type="cite">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.<div>
<br></div><div>It would be better to remove section 4.3.</div></blockquote><div><br></div></div>I disagree. <div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>But once the data is stored, it should be considered user data - as "sacred" as a user's file on the file system.</div></div></div></div></blockquote><div><br></div><div>What happens when your computer blows up? </div></div></blockquote><div><br></div><div>You lose the data the same way you lose your local file data.</div><br><blockquote type="cite"><div class="gmail_quote"><div>When you switch browsers? </div></div></blockquote><div><br></div><div>Unfortunately the same thing that happens with your bookmarks, preferences, history, etc - unless the new browser knows how to import the old data. </div><div><br></div><div>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.</div><br><blockquote type="cite"><div class="gmail_quote"><div>What about when you re-install your OS? </div></div></blockquote><div><br></div>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.<br><div><br></div><blockquote type="cite"><div class="gmail_quote">
<div>What about mobile devices where 5mb is actually a lot of space? </div></div></blockquote><div><br></div><div>These mobile devices are perfectly allowed to restrict the amount of data they agree to store with respect to their limited capacity.</div><br><blockquote type="cite"><div class="gmail_quote"><div>What happens when a malicious site fills up all of your localStorage space? </div></div></blockquote><div><br></div><div>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.</div><br><blockquote type="cite"><div class="gmail_quote"><div>You're saying the UAs should not be free to have heuristics about what to delete? </div></div></blockquote><div><br></div><div>Yes. </div><br><blockquote type="cite"><div class="gmail_quote"><div>What do they do then?</div></div></blockquote><div><br></div>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.</div><div><br></div><div>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?"</div><div><br></div><div>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?</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote">
<div>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.</div></div></blockquote><div><br></div>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.</div><div><br></div><div>~Brady</div><div><br></div><div><blockquote type="cite"><div class="gmail_quote">
<div><br></div><div>J</div></div>
</blockquote></div><br></body></html>