![[topcap]](/images/floating_sidebar_topcap.png){kind=small}
![[bottomcap]](/images/floating_sidebar_bottomcap.png){kind=small}
Given all the noise that was made about cookies and programs that look for “spy cookies”, the silence about DOM storage is a little surprising. DOM storage allows web sites to store all kinds of information in a persistent manner on your computer, much like cookies but with a greater capacity and efficiency. Another way that web sites store information about you is Adobe’s Flash local storage; this seems to be a highly popular option (e.g., youtube stores statistics about you that way), and it’s better known. Web applications such as pandora.com will even deny you access if you turn it off at the Flash management page. If you’re curious, see the contents in “~/.macromedia/Flash_Player/#SharedObjects/”, but most of it is not human readable.
I wonder why DOM storage isn’t used much after being available for a whole year; I haven’t been able to find any web site or web application making use of it so far, besides a proof of concept for taking notes. Yet, it probably will be (ab)used, given enough time. There is no user interface in Firefox for viewing this information, deleting it, or managing it in a meaningful way. All you can do is turn it on or off by going to the “about:config” URL, typing “storage” in the filter and set it to true or false. Compare this to what you can do about cookies… I’m not suggesting that anyone worry about it, but I think that we should have more control over what is stored and how, and the curious or paranoid should be able to view and audit the contents without needing the tricks below. Flash local storage should also be auditable, but I haven’t found a way to do it easily.
Auditing DOM storage. To find out what information web sites store on your computer using DOM storage (if any), you need to find where your Firefox profile is stored. In Linux, this would be “~/.mozilla/firefox/”. You should find a file named “webappsstore.sqlite”. To view the contents in human readable form, install sqlite3; in Ubuntu you can use Synaptic to search for sqlite3 and get it installed. Then, the command:
echo 'select * from webappsstore;' | sqlite3 webappsstore.sqlite
will print contents such as (warning, there could potentially be a lot of data stored):
cerias.purdue.edu|test|asdfasdf|0|homes.cerias.purdue.edu
Other SQL commands can be used to delete specific entries or change them, or even add new ones. If you are a programmer, you should know better than to trust these values! They are not any more secure than cookies.
del.icio.us »
January 17th, 2008 at 9:25 am
I’ve got one from CNN.com recording some “user_topics” in an array. I went back to CNN.com today and prodded some things, but received nothing new in the webappsstore.
January 17th, 2008 at 11:06 am
There’s two directories, not one. This works on a Mac. YMMV.
#!/bin/tcsh
cd “${HOME}/Library/Preferences/Macromedia/Flash Player/”
foreach d ( macromedia.com/support/flashplayer/sys/* \#SharedObjects/*/* )
rm -rf “$d” && touch “$d” && chmod 400 “$d”
end
January 17th, 2008 at 12:59 pm
Thanks Adam. Storage is organized differently in Ubuntu; the “support/flashplayer/sys” directory seems to have only access control settings, probably from the Flash management widget, and not the data. The Ubuntu version of your script is:
#!/bin/tcsh
foreach d ( ~/.macromedia/Flash_Player/\#SharedObjects/*/* )
rm -rf “$d” && touch “$d” && chmod 400 “$d”
end
and it does indeed seem to “neuter” the Flash local storage without preventing Flash applications from playing. Thanks for the tip.
January 24th, 2008 at 2:56 pm
You can try SQLite Database Browser instead of installing sqlite3 to view the webappsstore.sqlite file. It allows you to browse the database as well as query it.
Unfortunately, I didn’t find any juicy data in my file. Like RK, I have only one entry from cnn.com. I deleted that record, then revisited cnn.com, and saw I had a new record created by the site.
Is there some type of limit or restriction on writing to DOM storage?
- Julie
January 25th, 2008 at 9:12 am
Thanks RK and Julie. The limit in Firefox seems to be 5 MB (http://kb.mozillazine.org/Dom.storage.default_quota)
February 12th, 2008 at 10:01 am
[...] Super Cookies February 12, 2008 — Julie Pascal has a nice short post on Firefox’s “super cookies” and the information contained inside the browser’s DOM storage. He does a nice job [...]
February 27th, 2008 at 10:44 am
“I wonder why DOM storage isn’t used much after being available for a whole year;”
Isn’t this only available in FF? I believe IE uses “userData” (1MB storage) for local storage. Not sure about other browsers, but it seems like they have their own schemes for doing local storage, all of which are disparate.
Other than perhaps for “intranet-based” applications, utilizing local storage does not sound too efficient or reliable to me. Does anyone really need to store 1MB or even up to 5MB of persistent data client side for any useful purpose? I’ve read a lot of AJAX sites touting the usefulness, but I just do not buy their arguments…which usually amount to “pass everything off to the client and let JS handle it.” Rubbish.
February 27th, 2008 at 12:35 pm
It’s a standard proposed by the “Web Hypertext Application Technology Working Group” (WHATWG) but apparently Microsoft isn’t part of it, if one is to believe the relevant Wikipedia article. I haven’t looked at the equivalent IE feature, thanks for mentioning it.
There are applications using Flash storage, so this is currently just a way of doing the same thing independently of Flash. I believe that in the future someone will think of a use for all that storage.
February 28th, 2008 at 2:31 pm
I note that IE’s userData contents is stored within index.dat files, and that there is no mechanism for auditing userData contents within IE. They are binary files. UserData storage can only be enabled or disabled in each security zone.