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
