Localstorage is a particularly useful part of HTML 5 which allows websites to store small amounts of data inside a user's browser in a place that is only accessible to that site. In many ways, it's an extension of the idea behind cookies.

While debugging a LIFDed web application, I tried to do something that should have been simple: dumping all of the data that a site has in localstorage. Unfortunately it wasn't all that straightforward.

Cookie persistence and localstorage

Before you do anything else, make sure that persistent cookies are enabled. In Firefox, that means:

Edit | Preferences | Privacy | History | Keep until: they expire

If you don't do this, then the localstorage database on disk will always be empty as I imagine the data is simply kept in a data structure in memory.

However, if you don't like the idea of persistent cookies for privacy reasons, you can still tell Firefox to clear cookies when it shut downs. Simply select "Clear history when Firefox closes" and then click the Settings button next to it. Localstorage will work as expected until the browser is closed.

Reading the contents of localstorage

While there is an addon for this (Foundstone HTML5 Local Storage Explorer), it's proprietary and there is an easy alternative if you're not scared of the command-line:

1. go into your Firefox profile directory (~/.mozilla/firefox/xxxxxx.default/)

2. open the database using sqlite3 (apt-get install sqlite3 on Debian):

   sqlite3 webappsstore.sqlite

3. dump everything that's in this database:

   .dump webappsstore2

4. or only show the strings from a given origin (e.g. http://127.0.0.1:8000):

   SELECT key, value FROM webappsstore2 WHERE scope = '1.0.0.721.:http:8000';

I got an unlocked GSM Galaxy Nexus (GT-I9250) phone from Amazon a few months ago and I've been wondering why it was still sitting on Android 4.0.2 (Icecream Sandwich). Looking at "Settings | About phone | System updates" told me that my "system was currently up to date" despite the fact that most of my friends had been running 4.0.4 for a while on their Galaxy Nexus.

It turns out that a colleague of mine, who managed to buy this phone just before Apple got it banned in the US, found the reason: it was set to get over-the-air (OTA) updates from Samsung, not Google. Samsung has been sitting on this one for a while, which isn't great given the random crash+reboots that seem to occur about once a week on 4.0.2

Finding who delivers updates to your phone

Apparently there is a text file somewhere on the phone that will tell you whether it is a Google-controlled or Samsung-controlled phone. If you know what file that is, please leave a comment, I couldn't find it. So I ended up temporarily installing this application (warning: contains gratuitous ads) and looking at the "Brand" field.

Another thing you can look for is whether or not your device is running a "yakju" firmware (see the "Product" field). If it's something like "yakjujp", then you're not with Google and updates may not be available yet.

Switching to the standard Google firmware

In order to get your updates from Google, you can switch to the vanilla "yakju" firmware.

I followed these painful Windows instructions while I really should have looked at these ones instead (and ignored most of the steps given how much easier this process is on Linux).

The whole procedure can be summarized like this:

1. Backup your phone.
2. Unlock the boot loader (which erases everything).
3. Reboot into fastboot (hold down Volume Up and Volume Down then press the power button).
4. Flash all of the different firmware images.
5. Reboot and reinstall/reconfigure apps.

In any case, a few hours later, I ended up with a fresh install of the 4.0.4 yakju firmware and an unlocked boot loader. The only thing I haven't been able to do yet is to re-enable full disk encryption. I'm not quite sure why my phone refuses to start the encryption process...