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.
Wladimir Palant (January 31, 2007 at 5:22 am)
Have a look at http://www.xulplanet.com/ndeakin/article/359?show=c for the reason why it is called “DOM” Storage.
Wladimir Palant (January 31, 2007 at 5:24 am)
PS: You probably didn’t mean to link to your admin area for the ‘storage’ event…
pd (January 31, 2007 at 7:22 am)
1. Why would anyone want to store data for a whole TLD?
2. Someone think up a decent name
Neil Deakin (January 31, 2007 at 10:01 am)
Firing of storage events is in fact implemented. See http://xulplanet.com/ndeakin/tests/sessions/global-event.html for a test.
Also, globalStorage[”] and globalStorage[‘.tld’] were intentionally not implemented as I didn’t feel it was useful enough to warrant the potential additional security/privacy issues.
John Resig (January 31, 2007 at 10:24 am)
@Wladimir – Thanks for the link, I’ve updated the post with it – and good catch on the bad URL, that’s resolved too.
@pd – IE already has a storage implementation – I think I’ll run through it in another post. For now, you can read about it here:
@Neil – Thanks for your comments, I’ve updated the article to represent this. Do you think there’s going to be an effort to build/define a specification that doesn’t fall into these security/privacy traps?
Kevin H (January 31, 2007 at 5:05 pm)
I’ve seen “DOM Storage” catching on in the wild. Unless a concerted effort is made ( such as changing the MDC article and your previous blog post ), I think the moniker will just have to be something we live with.
Seamus (January 31, 2007 at 9:33 pm)
I was wondering if there will be a way to limit the scope to a particular window/tab instances? While debugging the error logs for a web app at a former job, we always would test by opening two windows/tabs to the same multi-paged form and change the inputs at an earlier step.
Although I am certain there are other ways to overcome this issue, I would rather see a simpler API for it.
Dao (February 1, 2007 at 4:26 am)
Hm … If you say Client-side Storage belongs to the Window object, and the Window object belongs to the DOM (which I’d say it does, even though it’s not part of that spec), then “DOM Storage” isn’t too wrong.
Vasile Brindus (February 6, 2007 at 3:38 pm)
Are you sure storing data to globalStorage[â€™localdomainâ€™] really works? I tried it in Firefox 184.108.40.206 and I get:
Exception “[Exception… “Security error” code: “1000” nsresult: “0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)” location: …..
globalStorage[â€™computername.localdomainâ€™] isn’t working, either. Do I miss anything?
John Resig (February 6, 2007 at 7:30 pm)
@Vasile – It’s very possible that it doesn’t work. Only minor parts of the specification have been implemented, and are in Firefox 2.0. I suspect that we’ll end up seeing a full implementation come Firefox 3.0.
Chris Double (February 12, 2007 at 2:21 pm)
There is a current bug that prevents DOM storage from working for localhost which is why you are seeing the security error:
I work around the problem of testing on my local machine by putting a dummy entry (eg, test.adomainname.com) in my hosts file pointing to 127.0.0.1 and this works fine.
Glen (March 14, 2007 at 5:05 pm)
Another simple workaround for testing on your local machine is to use the IP for localhost directly (i.e. http://127.0.0.1)
Vasyazns (March 17, 2007 at 2:03 am)
A test, sorry.
april may (May 29, 2007 at 8:12 am)
……stop these hacking bastard would be my first comment…..
my second comment is thank for your information about globalstorage…
i used to get the same error as vasile, but localhost (actually ‘dude’) so dude.localdomain did the job for me…..
i Hate these guys fooling around just to put anarchy in others structured work…
Justin Wyllie (August 23, 2007 at 11:31 am)
Is it possible to use domstorage in a Firefox application running from a file on the local computer? What would the domain name be?