[whatwg] Web Storage: apparent contradiction in spec

[Ian Hickson]

On Tue, 25 Aug 2009, Jens Alfke wrote:
>
> I've just noticed an apparent self-contradiction in the Web Storage spec (24
> August draft).
> 
> Section 4.3 states:
> > Data stored in local storage areas should be considered potentially
> > user-critical. It is expected that Web applications will use the local
> > storage areas for storing user-written documents.
> 
> Section 6.1 states:
> > User agents should present the persistent storage feature to the user in a
> > way that does not distinguish them from HTTP session cookies.
> 
> These statements are contradictory, because cookies don't store user-critical
> data such as documents. The user model of cookies is that they're conveniences
> (at best) for keeping you logged into a site or remembering preferences like
> font-size, so deleting them is no more than an inconvenience. If local storage
> is presented to the user as being cookies, then a user may delete it without
> understanding the consequences.
> 
> Potential result: "I was having trouble logging into FooDocs.com, so my friend
> suggested I delete the cookies for that site. After that I could log in, but
> now the document I was working on this morning has lost all the changes I
> made! How do I get them back?"
> 
> I suggest that the sub-section "Treating persistent storage as cookies" of
> section 6.1 be removed.

We can't treat cookies and persistent storage differently, because 
otherwise we'll expose users to cookie resurrection attacks. Maintaining 
the user's expectations of privacy is critical.

So I've removed the text that says that local storage could be 
user-critical.


On Tue, 25 Aug 2009, Brady Eidson wrote:
> 
> 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.

I haven't changed this.


On Tue, 25 Aug 2009, Brady Eidson wrote:
> 
> LocalStorage is quite clearly modeled after Flash's LocalStorage

Actually I don't think I'd heard of Flash's LocalStorage at the time that 
localStorage (then globalStorage) was first specced.


On Wed, 26 Aug 2009, Michael Nordman wrote:
> 
> * Can an individual <key,value> pair for an origin be removed from local 
> storage while leaving other local data in place?
> 
> * Can an individual Database be deleted for an origin while leaving 
> other local data in place?
> 
> * Can an individual Manifest be deleted for an origin while leaving 
> other local data in place?
> 
> * Or should an origin's data be subject to all-or-none eviction.
> 
> I would prefer to see the spec clarify questions along those lines. That 
> would be useful.

The spec leaves all of this up to the UA. It discourages unprompted 
eviction, but at the end of the day, as has been pointed out, there are 
limits to what can be guaranteed.


On Wed, 26 Aug 2009, Peter Kasting wrote:
> 
> That's not the proposed mandate.  The proposed mandate is "thou shalt 
> not discard successfully-written data without explicit user action", 
> which seems implementable to me.  Note that this doesn't make claims 
> like "the hard drive will not fail", and it doesn't claim that the UA is 
> required to allow the app to write whatever data it wants in the first 
> place.

That's more or less what the spec says, but it uses "should" which allows 
UAs to violate this in "extreme" cases (like abuse being detected, or 
running out of disk space, or whatnot).


On Wed, 26 Aug 2009, Michael Nordman wrote:
> 
> What seems inevitable are vista-like prompts to allow something (or 
> prods to delete something) seemingly unrelated to a user's interaction 
> with a site... please, oh please, lets avoid making that part of the web 
> platform. I'm assuming that UA will have out-of-band mechanisms to 
> 'bless' certain sites which should not be subject to automated eviction. 
> If push comes to shove, the system could suggest cleaning up one of 
> these 'blessed' sites if inactivity for an extended period was noticed. 
> But for the overwhelming number of sites in a users browsing history, 
> its a different matter.
> 
> If the storage APIs are just available for use, no questions asked.... 
> making the storage just go away, no questions asked, is symmetrical.
> 
> Blessing involves asking questions... making it go away does too.

UAs can do this, yes.


On Wed, 26 Aug 2009, Jens Alfke wrote:
> 
> If this is out-of-spec and browser-dependent, there won't be a good way 
> for an app to request that blessing; it'll be something the user has to 
> know to do, otherwise their data can get lost. That seems dangerous. In 
> most systems user data loss is just about the worst-case scenario of 
> what could go wrong, and you try to prevent it at all costs.

In-band systems can be abused, out-of-band systems can be hard to 
discover. I don't know which is worse. We had <bb type=makeapp> for a 
while (an in-band system), but we removed it due to implementor feedback.


> My suggestion to have separate 'important' and 'cache' local storage 
> areas would provide such a mechanism in a standard way. The first time 
> an app tried to put stuff in the 'important' area, you'd be asked for 
> approval. And 'important' stores wouldn't be deleted without your 
> consent.

No need for two cache systems for this -- just have one, and the user 
decides if it's important or not.


Various people suggested adding a Storage object for temporary ("cached") 
data, which the UA could automatically purge. I expect in a future version 
we'll add expiry dates to keys, and when we do that, we could add a flag 
to the effect of "this can be deleted". I think this would be better than 
a whole separate object. I also think we should wait on this and see how 
localStorage is used before adding yet more features.

It's worth noting, also, that this solution wouldn't actually remove the 
issue of pages filling up the disk (maliciously or otherwise) and the user 
needing to be prompted for a solution -- expiring old data or something 
else.


On Wed, 26 Aug 2009, Linus Upson wrote:
> 
> I'm not opposed to web apps manipulating files on the user's computer, 
> but the user should be in explicit control. I'd support <input 
> type="open"> and <input type="save"> that worked similarly to <input 
> type="file">. User agents are already registering for file types so that 
> double clicking a file with a certain extension can be automatically 
> sent to an URL, perhaps residing in an AppCache.

<input type=file> is the "open" case already.

We could add type=save in a future version once we have shown the File API 
to be a success.


> In addition, I'd like to see the pop-up dialogs for the location API 
> removed. I find the "Can I know where you are?" dialogs on the iPhone 
> very annoying. Mistakes were made. Perhaps we can find a way to make 
> <input type="location"> work well instead.

The geolocation model is asynchronous, which gets around this neatly (the 
UI can slide in and the user can ignore it until he's ready to give his 
location).


On Thu, 27 Aug 2009, Linus Upson wrote:
>
> I'm not saying that UAs shouldn't provide file-like lifetime semantics 
> for storage. I'm just saying the user should decide, not the web page.
> 
> Here's one way such a thing could be achieved:
> 
> <input type="storage" src="button.png" quota="20GB" />
> 
> When the user clicks the button they see a dialog that mail.google.com 
> would like to use 20GB of storage. You have 50GB of free space. [Yes] 
> [No]. Script can't cause the dialog to appear, only a user action. There 
> would also be some affordance in that dialog to allow the user to manage 
> persistent storage from other domains. A small "Other sites are using 
> 2GB of storage" link perhaps. AppCache, LocalStrorage, and all other 
> persistent bits for that domain would live within this quota. UAs would 
> take this user action as a strong signal that the data is valuable and 
> would act accordingly.
> 
> If web sites use LocalStorage, AppCache, et. al. without the user 
> clicking on and accepting a storage input button, then the UA would be 
> free to garbage collect as it sees fit. Good UAs would do a good job of 
> not throwing away things that are important to the user, just as they do 
> today with cookies.

This is an interesting idea. I think it's something we should consider 
once we've seen how localStorage is used in practice. It might not be 
needed enough to justify a language extension; or it might be that we find 
some better asynchronous out-of-band UI.


On Thu, 27 Aug 2009, Schuyler Duveen wrote:
>
> There should also be a way to ask for more quota (from the user) without 
> losing user data.
> 
> The API via a form element is a little odd--generally forms are for
> submitting information to the site.  Historically, all of these kinds of
> things are done via javascript:
> * cookies
> * opensearch additions
> * extension additions
> 
> This would also have the benefit of allowing a Worker() to request quota 
> without something on the page.

The problem with JS being able to trigger the prompt is it makes it much 
easier to abuse it ("while (notGotQuota) askForQuota()").

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'