In a follow-up to my previous post on DOM Storage, here’s an attempt to answer some of the questions posed in the comments, and elsewhere.
Whatâ€™s to stop a script from filling an entire storage area with random data?
As best as I can tell with the implementation in Firefox, every time you save data to a storage area, not only is the name of the storage area saved (e.g. “org” or “ejohn.org”) but so is the domain name of the original script. This domain name is what has the 5MB limitation imposed upon it.
This means that a single script could put 2MB of data in globalStorage['org'] and another 3MB in globalStorage['ejohn.org'], but attempting to put any more data in will cause an error to occur.
I may be wrong on this point; but if that’s the case, then it will be very hard to stop scripts from filling up “common” areas with nonsense data (and which seems like something that was considered as a fundamental design decision).
(Update: This is, currently, a moot point in Firefox as it does not enable any of the TLD or public storage areas, for fear of an issue like this happening.)
Storing data to globalStorage['localdomain']
I forgot to mention that all LAN addresses receive a TLD of ‘localdomain’. For example, if your computer is named ‘anthrax’, you could store data in the following stores: globalStorage['anthrax.localdomain'], globalStorage['localdomain'], and globalStorage[''].
This means that you can, in fact, store data “globally” across all pages of an intranet.
What’s with the name “DOM Storage”?
I’ve been having trouble pinpointing this one – but I agree, the name is particularly deceptive. What’s especially confusing is that “DOM Storage” isn’t the official name for this particular feature, “Client-side session and persistent storage” is.
As it happens, Mozilla’s internal name of this features is “DOMStorage” (the names “Storage”, “mozStorage”, and “sessionStorage” were all already in use), I’m beginning to suspect that this naming confusion has stemmed from this, original, feature-naming. (Note: This has been confirmed.)
In reality, the storage area doesn’t really have much to do with the Document Object Model – it really only attaches to the WindowHTML Object. The only time it actually interacts with the DOM, as we know it, is to trigger a “storage” event on the document body.
The storage event
I forgot to mention this in my last post, but this is a rather interesting sub-feature of DOM Storage. Whenever a key/value is changed, added, or removed within a storage area that you have permission to access, a ‘storage’ event is triggered, originating from the HTML document body and bubbling its way up.
The only piece of event metadata that is passed along in the event object is the name of the domain that the changed-key is within – and nothing else. (Providing any additional information would serve to be a security risk)
Update: Firefox does currently support this, and you can view a test case here.
No data from DOM Storage areas is automatically passed to the server. This differs from cookies, which serve as a two-way form of synchronous communication between a server and a browser.
You could work around this limitation with an XMLHttpRequest, POSTing the contents of your relevant storage areas.
As I mentioned before, Firefox has the only known implementation of DOM Storage available to any browser. However, there are still some serious limitations with it.
- sessionStorage – Does not restore data across browser crash/restore.
- globalStorage['org'] – Storing data to a single TLD fails
- globalStorage[''] – Storing data to a public area fails
Update: Neil Deakin has gotten back to me and mentioned that the lack of TLD or public storage areas was intentional. When implementing the specification he felt that there was, quite simply, too much of a security risk in leaving those public areas open. I suspect that since Firefox is the first browser to make an attempt an implementation, much of this will trickle back to the specification.
We’re still in the rocky first moments of this feature, but once it starts to pick up some solid adoption (especially amongst other browsers), I suspect that we’ll see the level of quality really start to take off.