[whatwg] Persistent storage is critically flawed.

[Daniel Veditz]

Ian Hickson wrote:
> Note that the problems you raise also exist (and have long existed) with 
> cookies; at least the storage APIs default to a safe state in the general 
> case instead of defaulting to an unsafe state.

In what way do the storage API's default to a "safe state"? What "unsafe
state" is the alternative? You've lost me.

Compared to cookies storage seems less safe: the default cookie access
is to the setting host only, a case that does not even exist with global
storage. To publish a cookie to a wider family of hosts the setting host
must explicitly set a domain on the cookie. (Ditto path, but that turns
out to be illusory protection due to the DOM same-origin policy).

Web-app developers aren't complaining they can't read cookies they need
from sub-domains, they're complaining when private cookies leak or when
they're fooled by a cookie injected at a higher domain (e.g. .co.uk
cookies).

Let me throw out two alternatives for providing "private" persistent
storage, neither of which complicates the API (though may complicate the
implementation).

The first piggy-backs on the domain vs host cookie concept as applied to
entire storage objects. Each host would have a private persistent
storage object that could only be accessed by that host; shared objects
would need to be explicitly named. There should be a difference in how
the two types are named
  a) using the cookie domain nomenclature to indicate the similar
  concepts "www.foo.com" could represent the host storage only
  accessible to that host, and a leading '.' in ".www.foo.com"
  would represent a shared storage area. You could argue that
  people will forget the dot as they do with cookie domains,
  but they only do with cookies because UA's let them get away
  with it.
  b) another choice would be to make globalStorage[''] magic and
  mean the private storage for the current host. No one is going
  to implement universally accessible storage (the spec even
  recommends against it), you could just take that out of the spec
  and reuse it for this. All other named areas would be shared
  as described by the spec.

The second alternative would be to have private and shared storage items
within a single storage area. I know you weren't keen on adding another
attribute like "secure", what if instead there was a convention such as
"keys which start with an underscore are private and can only be
accessed if the current host matches the storage area domain".

My personal preference is for 1b -- use globalStorage[''] as the
non-shared storage area.

-Dan Veditz