<div class="gmail_quote">On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson <span dir="ltr"><<a href="mailto:linus@google.com">linus@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>The analogy was made comparing a user agent that purges local storage to an OS throwing out files without explicit user action. This is misleading since most files arrive on your computer's disk via explicit user action. You copy files to your disk by downloading them from the internet, copying from a network drive, from a floppy, your camera, etc. You put them on your disk and you are responsible for removing them to reclaim space.</div>

<div><br></div><div>There are apps that create files in hidden places such as:</div><div><br></div><div>C:\Documents and Settings\linus\Local Settings\Application Data\Google\Chrome\User Data</div><div><br></div><div>If those apps do not manage their space carefully, users get annoyed. If such an app filled the user's disk they would have no idea what consumed the space or how to reclaim it. They didn't put the files there. How are they supposed to know to remove them? Most users have no idea that Local Settings exists (it is hidden), much less how to correctly manage any files they find.</div>
</blockquote><div><br></div><div>This seems like an argument for ensuring web apps have as much ability to take reasonable steps to control their space usage as local apps do, not an argument that the UA should be able to discard those files.  After all, you are not arguing that Windows should be able to throw away those non-user-visible files in Local Storage.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div>
<div>Without automatic space management the local storage consumed will grow without bound. I'm concerned that even without an intentional DOS attack users are going to be unhappy about their shrinking disks and not know what to do about it. The problem is worse on phones.</div>
</blockquote><div><br></div><div>I don't think anyone is suggesting UAs should not have the ability to control the total space usage, e.g. by presetting per-app and global quotas.  That's not the same as saying that the UA can throw away data after the fact.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div></div>
<div>Things get worse still if a griefer wants to make a point about the importance of keeping web browsers logically stateless. Here's how such an attack could be carried out:</div><div><br></div><div>
2a. Acquire a bunch of unrelated domains from a bunch of registrars using stolen credit cards. Skip this step if UAs don't group subdomains under the same storage quota. For extra credit pick names that are similar to legitimate sites that use local storage.</div>

<div><br></div><div>2b. Start up some web hosting accounts. Host your attack code here. If they aren't free, use stolen credit cards.</div><div><br></div><div>2c. Buy ads from a network that subsyndicates from a network that subsyndicates from a major ad network that allows 3rd party ad serving. There are lots to choose from. No money? Stolen credit cards. Serve the ads from your previously acquired hosting accounts.</div>

<div><br></div><div>2d. Giggle. The user will be faced with the choice of writing off the space, deleting everything including their precious data, or carefully picking though tens of thousands of entries to find the few domains that hold precious content. User gets really unhappy if the attack managed to fill the disk.</div>
</blockquote><div><br></div><div><div>I'm not sure why this is more compelling for a griefer than the existing attack (along similar lines) they can already make against the cookie store to blow away 100% of the user's cookies, and keep doing it, such that the user can never log in anywhere.  In fact, to some degree that's a testimony that treating things "like cookies" doesn't mean users will be free from griefing.</div>
<div><br></div><div>In practice I don't foresee either of these happening unless doing so allows attackers monetary gain.</div><div><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>Chrome's Incognito mode creates a temporary, in-memory profile. Local storage operations will work, but nothing will be saved after the Incognito window is closed. Safari takes a different approach and causes local storage operations to fail when in Private Browsing mode. Some sites won't work in Private Browsing. I don't recall what Firefox or IE do. Pick your poison.</div>
</blockquote><div><br></div><div>This is a problem that has to be solved regardless, and it doesn't seem like a bad one.  If the purpose of section 6.1 is to state that UAs must give users the ability to see and clean up their Local Storage data (which seems to me like a good idea but outside the scope of what HTML5 should be specifying), then users have the ability to manually delete this data anyway, and live with the consequences.  Chrome's behavior is akin to a user manually clearing his Local Storage data, and Safari's is akin to an app hitting its quota.  Apps have to be able to deal with both anyway, perhaps with a (possibly large) reduction in functionality.</div>
<div><br></div><div>While that may sound like an argument for your position (since I am saying that apps need to deal with disappearing Local Storage data), the critical difference is that the user is in control of this, either by cleaning up the data manually or by electing to use a private browsing mode.  Thus I don't think it justifies some UA behavior when the user is _not_ in explicit control.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>If the spec requires UAs to maintain local storage as 'precious' it will be the first such feature in HTML 5. Everything else in the spec is treated as volatile.</div>
</blockquote><div><br></div><div>To use a very poor analogy, if one thinks of Local Storage like a "hard drive" where the JS execution context is "RAM", authors expect that their scripts won't fail because variables suddenly lose state.  VMs are allowed to garbage-collect, but not to collect live data.  In this (admittedly awkward) sense, RAM is not "volatile", why should the hard drive be?</div>
<div><br></div><div>It seems like your main concerns are around the potential damage to users by poorly-written or malicious applications that store a lot of data.  I don't see why quota policies don't address this sufficiently.  That is, the spec can allow the UA to set whatever quotas it likes, and provide users with whatever UI it wants to expand them, but failure to write due to hitting quota should behave in a well-defined way, apps should be able to determine that they are using a lot of storage space and clean up somewhat, and data successfully stored won't be thrown away without explicit user action.</div>
<div><br></div><div>PK</div></div>