The first thing that I tasked myself with, when I hopped on board with Mozilla, was to learn everything that I could about the new DOM Storage functionality provided in the HTML 5 specification. Interestingly, it’s actually very impressive.

The brief summary: DOM Storage is a way to store meaningful amounts of client-side data in a persistent and secure manner.

I’ve written up a thorough piece of documentation on DOM Storage, and it can be found on the DevMo Wiki.

If you hadn’t guessed already, DOM Storage is most similar, in nature, to HTTP Cookies. I’m going to already assume that you know how Cookies work, so with that in mind, here is how DOM Storage compares.

Storage Space

It is implied that, with DOM Storage, you have considerably more storage space than the typical user agent limitations imposed upon Cookies. However, the amount that is provided is not defined in the specification, nor is it meaningfully broadcast by the user agent.

If you look at the Mozilla source code we can see that 5120KB is the default storage size for an entire domain. This gives you considerably more space to work with than a typical 2KB cookie.

However, the size of this storage area can be customized by the user (so a 5MB storage area is not guaranteed, nor is it implied) and the user agent (Opera, for example, may only provide 3MB – but only time will tell.)

Storage / Retrieval

Where as in cookies you have to encode your key/value pairs into a string, along with other information (such as expiration and path), DOM Storage is a breath of fresh air. It provide a clean, JavaScript-like API for accessing and mutating key/value pairs. For example:

// Save a value
sessionStorage[ 'name' ] = "John";
// Display a value
alert( sessionStorage[ 'name' ] );
=> 'John'

This is absolutely fantastic, in comparison to Cookies. Note that, like with cookies, you can only store strings of data as a value. Additionally, no form of object serialization is provided by the browser, making some storage tasks non-trivial.

At this point, I’d be happy with one of two solutions: 1) For the user agent to take care of object (de)serialization for us, making it completely seamless or 2) To provide us with a really good, really fast, JSON (de)serializer. Honestly, I’d prefer the second solution, simply because it could be used in so many other situations. (And if I’ve heard right, one is definitely in the works by multiple browser vendors.)

Security

Cookies provide you with the ability to limit the accessibility of your key/value pairs to a certain domain, and even a certain path within that domain. DOM Storage works similarly, but only allows you to restrict access to domain (or TLD, or even public!) or session.

The data stored in a DOM Storage area is much more “public” than what’s provided by cookies. For example, let’s say you wanted to use DOM Storage on a public site like LiveJournal. There would be no way for you to hide your data from other users — other than to choose a key that is completely private and un-reproducible; since there is no “path” limiter for DOM Storage.

Additionally, unlike in cookies, where you’re immediately provided with all available key/value pairs for your particular domain (and path), in DOM Storage you must request a key by its specific name (you can’t iterate through all available keys).

In short: If you are only using DOM Storage within a single domain (and you control that domain), then you have nothing to worry about – your data is very safe. In any other context you must choose a secure key name that cannot be duplicated by other clients on other sites (unless, of course, that’s your goal).

Scope

DOM Storage provides you with a greater variety of scope for a piece of data, than for that of Cookies. For example, if I wanted to store a piece of data on this domain I could store it with the sessionStorage, globalStorage[‘ejohn.org’], globalStorage[‘org’], or globalStorage[”] DOM Storage areas. Here is how the restrictions break down:

• sessionStorage is limited to the current browser session, only. No other client can access this data.
• globalStorage[‘ejohn.org’] All pages on my web site have access to this area.
• globalStorage[‘org’] All web sites with the TLD of ‘org’ can access this area (including, for example, mozilla.org).
• globalStorage[”] All pages on all sites can access this area.

I, personally, think that we’re going to see the most interesting results come from sessionStorage and globalStorage[”]. sessionStorage for its practicality (which I’ll discuss in a minute) and globalStorage[”] for its potential deviousness.

Duration

In DOM Storage it is not possible to specify an expiration period for any of your data. All expiration rules are left up to the user. In the case of Mozilla, most of those rules are inherited from the Cookie-related expiration rules. Because of this you can probably expect most of your DOM Storage data to last at least for a meaningful amount of time.

The one storage area that is particularly interesting (and where expiration does not apply) is that of sessionStorage. sessionStorage is seemingly useless at first blush – it only stores data within the context of a single session. However, there are two, very important, qualifiers to that:

1. Data is persistent across page refreshes. This is nice because you can now help to protect against accidental page refreshes, by temporarily caching a user’s unsaved data.
2. Data is persistent across browser crashes. This is up to the user agent, but in the case of Firefox if you browser crashes, and you restore your previous session, then your sessionStorage area will be restored. (Well, that’ll be the case once Firefox actually implements this feature).

This isn’t to say that either of these features aren’t possible using cookies, but the similar solution wouldn’t be nearly as elegant.

Summary

In all, I’m really looking forward to digging in to DOM Storage – I think it has a lot of potential. Currently, the state of affairs is pretty slim (Firefox is the only browser that has an implementation, and even then, sessionStorage isn’t terribly useful yet.) – but the future is bright.

As I mentioned before, if you’re interested in some basic examples and documentation on the subject, feel free to read through the DOM Storage documentation that I wrote.

Update: Here’s the original bug report that detailed its implementation in Gecko.