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.
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
// 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.)
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).
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.
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:
- 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.
- 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.
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.
Marcel Popescu (January 30, 2007 at 4:00 am)
Ok… so what’s to stop a script from creating random keys (using GUIDs, for example) and saving 100K of random data in each until it fills out the entire storage?
michael schurter (January 30, 2007 at 9:31 am)
At first I thought supporting TLDs with globalStorage[‘org’] seemed a bit pointless until I realized the school I work for uses a .local TLD. Persistent client-side cache available to all internal web applications? I like it. :)
@Marcel – It could only fill the allotted space for its own domain which in the base of “shared” domains like LiveJournal could be a problem.
I foresee the UI for user’s clearing their persistent storage to be extremely confusing as well since it may only have a TLD and random data to display.
I would imagine this technology is going to find lots of abuses at first… but whats new?
zimbatm (January 30, 2007 at 9:33 am)
Some critics :)
* DOM Storage is a misleading name : my first guess was that I could store DOM nodes.
* What real-world problems does “DOM Storage” solve ? : Reading the article, it didn’t struck me why I would like yet another technology (event if it were cross-browser compatible). A better interface for cookies could easily be built, storage space is an RFC limitation but it’s not necessarily bad and I’m not sure exactly what kind of security it brings over cookies.
* Storage scope is dangerous : TLD and root storage is useless, except to introduce a new kind of “cookie bug”. Please raise the user’s awareness (by building appropriate notification interfaces) before introducing yet another privacy leak.
* Storage scope is not useful (in the case of sharing authentication) : If you have multiple sites with one login, it does not mean that they are on the same domain. Plus who would want to authenticate a TLD ?
Dao (January 30, 2007 at 11:57 am)
> DOM Storage is a misleading name
The correct term is “Client-side session and persistent storage”, but that’s a bit long. Anyway, the documentation shouldn’t be in the DOM category.
> A better interface for cookies could easily be built, storage space is an RFC limitation but itâ€™s not necessarily bad and Iâ€™m not sure exactly what kind of security it brings over cookies.
Cookies are sent to the server, storage data is not (unless explicitly sent by a script).
Brennan Stehling (January 30, 2007 at 3:30 pm)
The TLD and Global scope could be useful, but I would really prefer a way to define a group of hostnames which would be authorized so you can have a small network of sites which can share data. And making that updateable would be useful as well.
The real-world scenario would be an acquisition such as flickr.com becoming a part of the Yahoo.com properties. When the data can be automatically shared to flickr.com after logging into my.yahoo.com would be a natural way to implement SSO as well as carry along some user settings beyond the username which could be useful from the client-side. One setting I would start using right away is an indicator for work/public versus personal computers. I may even implement location oriented profiles attached to the same user account.
Dan Veditz (January 30, 2007 at 8:08 pm)
Firefox does not implement the public storage location (”) nor storage for top-level domains.
MÃ¡r (February 17, 2007 at 5:39 pm)
Hmmm…. no path limiters, no expiration parameters, no secure/SSL limiters …. why!?!
Also: at first sight the TLD and “” (public) scopes both seem good for about two things only:
1) serving as a dumb public graffiti wall (anybody can read/write/modify ~5MB section of *my* hard drive)
Maybe I’m just too thick to “get it”, but this whole concept seems kind of poorly thought out…
> “Firefox does not implement the public storage location (‘â€™) nor storage for top-level domains.”
That sounds like the responsible thing to do. Go Firefox!
Anonymous (February 28, 2007 at 3:58 am)
You can use DOM storage securely on livejournal:
globalStorage[‘yourusername.livejournal.com’] = foo
You can’t access ‘yourusername.livejournal.com’ from ‘livejournal.com’ or from ‘otherusername.livejournal.com’.
Andrew Wilson (March 2, 2007 at 4:58 am)
No-one would store credit card details/SS numbers/passwords in the Client storage area. They don’t store them in cookies so why would they store them in Client Storage?
> … into an easily guessable DOM Storage key, for *everybody* to access from any site …
Sites would only have acces to keys that matched their domain.
SpliFF (March 18, 2007 at 7:22 pm)
Actually it’s worth adding that many members of WHATWG are working hard on really useful and fair proposals. It’s just some of their members who are abusing it to push commercial agendas.