[whatwg] Web Storage: apparent contradiction in spec

On Wed, Aug 26, 2009 at 4:01 PM, Linus Upson <linus at google.com> wrote:

> 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.
>
> There are apps that create files in hidden places such as:
>
> C:\Documents and Settings\linus\Local Settings\Application
> Data\Google\Chrome\User Data
>
> 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.
>

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.

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.
>

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.

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:
>
> 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.
>
> 2b. Start up some web hosting accounts. Host your attack code here. If they
> aren't free, use stolen credit cards.
>
> 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.
>
> 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.
>

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.

In practice I don't foresee either of these happening unless doing so allows
attackers monetary gain.

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.
>

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.

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.

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.
>

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?

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.

PK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090826/2a98223d/attachment.htm>

Received on Wednesday, 26 August 2009 16:21:45 UTC