I propose we rename it the "Web Storage And Messaging" API.
For me it is awesome to use PushState and LocalStorage in a client side app and all the while the user thinks they are using a "traditional" server side app.
(ok they're for cookies but you get the idea)
The use of the storage mutex to avoid race conditions is currently considered by certain implementors to be too high a performance burden, to the point where allowing data corruption is considered preferable. Alternatives that do not require a user-agent-wide per-origin script lock are eagerly sought after. If reviewers have any suggestions, they are urged to send them to the addresses given in the previous section.
More details regarding this issue are available in these e-mails (as well as numerous others):
So as long as you don't need transactions/locks across the shared state, this might work. Of course, transactions/locks are often necessary.
Note that the way Chromium implements localStorage, it uses a disk backing store of sqlite, a caching layer (a std::map) in the browser process, and a caching layer (also a std::map) in the renderer processes (where WebKit runs, and may handle 1-X tabs per process). Changes are propagated via IPC, but as the API does not provide any locking guarantees beyond the optional storage mutex, which Chromium does not implement, there are obviously race conditions.
This probably explains the issues the author of that post encountered with Chrome.
In my opinion this is a bug that should be fixed,
 http://godoc.org/github.com/gorilla/securecookie (Go)
Could you use sessionStorage to hold a temporary key for decrypting whatever is localStorage?
Doesn't seem to work in Chrome on iOS?
I was intending this to be a "nice to have if it works", rather than essential to my app. But do people really use multiple tabs on a single site that much on mobile devices?