How to do it though? I have a GPS receiver, but there’s no way I’m carrying it around with me and cabling it up to my computer nightly (unless I go trekking in the Himalayas). My iPhone is 2G only, so it has only Skyhook data which I’m already capturing as part of my daily iPhone data scrape. I don’t really use the Maps app all that much though, so there’s not much opportunity to passively capture location bookmarks. I do use the browser a lot though, at least daily. That’s where Google Latitude comes into this scheme. It also uses SkyHook technology, but displays it on your PC in a manner that’s visual and easily capture-able.

This guy mentioned writing a curl script to capture his Google Latitude data (the service doesn’t seem to provide much by way of logging data for your), but was pretty sparse on the details. I was inspired to try it, and went for the easier option of using OSX’s Automator app. It took about 10 minutes to setup.

I’ll go into the details of how I set things up below, but keep in mind you can easily adapt the basic method to suit your purposes and your tools at hand. You could write a curl script and just save the lat and longitude as text, or expand the script to generate prettier data (like a full PDF, generated perhaps via OpenOffice from the saved web page). You could construct a YahooPipe. Regardless of the tools used, you could e-mail yourself the data as well. Endless possibilities.

Here’s my approach:

1. Sign up for the free service from Google here. You’ll need a Google account. You don’t have to share any of the location data with your friends, but do click to add the Latitude badge to your iGoogle homepage. This is the URL you’ll save regularly as your location record.
2. Check your browser’s options as necessary to store your Google name and password, so you can automatically call up the URL via a script without the need to manually enter anything.
3. Surf to google.com/latitude on your smartphone’s browser. Many models are supported. You’ll eventually get logged into the service. A location data point has now been created which you can view on your PC.
4. iPhone doesn’t let you store a browser homepage (so far as I know), so I set up a Homepage Button (there’s an option for one just below the Create Bookmark button) to the page for easy, repeated logins to Google Location. I can hit it whenever I need a data point, then go about surfing the web. If your phone’s browser does allow for a homepage, you could set it up to go to Google Latitude every time, so you can passively capture a location data point. (Here’s again where it would be nice to be able to create a cron job on the iPhone that worked even from sleep mode.)
5. Back on your PC, surf to www.google.com/ig#max54. If everything worked, you should see a nice big map of your iPhone’s last location. If you had to enter username or password, save these details as appropriate for autologin next time. If you don’t like the map quite so big, trim off the “#max54″ bit.
6. Now all you need to do is set up a mechanism to automatically call up and save this URL’s contents daily. I used OSX’s Automator application for that. I also have DEVONagent on my MacBook, so I get a few extra actions to make this process very simple — get the URL, display it, save it as a PDF. You could do much the same though with just the Safari Actions, though perhaps not with the easy option to convert to a PDF. My Automator workflow then looks like this:
7. Now schedule your workflow/script/what-have-you to execute daily. If you’re using Automator, you can save your workflow directly to iCal as a plugin and set it up to run at a specified time daily — that’s what I did. Again, depending on the tools at hand, you could use cron, launchtabd, etc.
8. I copy daily all my life data to NAS-like storage, so I next just tweaked script to make sure to grab the locations PDFs as well each day and that was it.

Done. Daily record of where I am in the world. Probably wouldn’t stand up in court as an alibi against murder, but good enough for the IRS. Well, maybe not them either. Good enough for jogging my bio memory then.

An interesting NPR Talk of the Nation discussion on the dark side of permanent data in aggregate is here.

Moral of the story: Keep your lifelogging data private!

I came up with the following list:

• SMS text messages
• Call history
• Photos
• Browser history and bookmarks
• Map bookmarks (for me this just means Skyhook-derived locations, as my iPhone is 2G only and has no GPS hardware)
• Notes
• MP3 track history

That’s a pretty good sized list, though one could argue for getting even more data off. Anyway, it’s a good start, and I set about writing a script to capture all this. The script itself is pretty simple, though it took quite a bit of Googling to figure out where stuff is stored and how to convert it into something that’s human readable.

Prep

I’ll share the script in just a second, but first you’ll have to do a bit of setup to get it to run. All that follows assumes your iPhone is jailbroken. Mine is running OS version 3.0, though this would likely work in other versions with just slight modifications to the path names.

1. If your iPhone doesn’t already have a static IP address on your home or work Wi-Fi network, assign it one. On your iPhone, under Settings>Wi-Fi, note the IP addresses listed for IP Address, Subnet Mask, Router, and DNS under the DHCP tab. Enter these instead under the Static tab, substituting in a fixed IP address which you know to be free on the network (high numbers are a safe bet).
2. Setup ssh public key authentication on your iPhone. This basically entails copying a public key from the machine on which you will run the capture script over to the iPhone, so that you can log in without a manually entering password each time (which then means you can run the script automatically via cron or some other method). The process, a simple one, is covered here. Don’t enter a passphrase if you have to create the public key from scratch.
3. Install an rsync package from some provide such as Cydia.
4. Test that you can indeed log into your iPhone using its fixed IP and that no password is required.
5. Test that you can run rsync once logged in.

The Script

Ok, now the script. I’m running it on a MacBook, but you could get this to run from a Linux box easily, or even a Windows box if you install Cygwin.

Mine look like this, but you might want to tweak it some to suit your purposes (for example, you might want to copy off voicemail messages as well — mine are stored on my mobile company’s server):



#! /bin/sh

# Declare a couple of variables.
iPhoneIP="[Enter the static IP you assigned above.]"
NASIP="[Enter your NAS/central storage IP address.]"

#Go to the proper storage folder on my MacBook. (You'll need to make this directory first.)
cd /Users/[Enter your user name.]/iPhone_data/

#Copy off SMS DB.
scp root@$iPhoneIP:/var/mobile/Library/SMS/sms.db `date +%b%d%Y`_sms.db

#Copy off call log DB.
scp root@$iPhoneIP:/var/mobile/Library/CallHistory/call_history.db `date +%b%d%Y`_call_history.db

#Copy off photos (just the one's not already copied).
rsync -a root@$iPhoneIP:/private/var/mobile/Media/DCIM/100APPLE/ /Users/[Enter your user name here.]/Pictures/iPhone_Photos/

#Copy browser history and bookmarks.
scp root@$iPhoneIP:/private/var/mobile/Library/Safari/Bookmarks.plist `date +%b%d%Y`_BrowserBookmarks.plist
scp root@$iPhoneIP:/private/var/mobile/Library/Safari/History.plist `date +%b%d%Y`_BrowserHistory.plist

#Copy map bookmarks (SkyHook location data).
scp root@$iPhoneIP:/var/mobile/Library/Maps/Bookmarks.plist `date +%b%d%Y`_MapBookmarks.plist#Copy notes DB.
scp root@$iPhoneIP:/var/mobile/Library/Notes/notes.db `date +%b%d%Y`_notes.db

#Copy MP3 tracks history.
scp root@$iPhoneIP:/private/var/mobile/Media/Podcasts/MobileDB/TrackData.plist `date +%b%d%Y`_TrackData.plist

#Covert SQLite DB files to (human readable) CVS.
sqlite3 -csv -separator ',' `date +%b%d%Y`_sms.db "select * from message;" >> `date +%b%d%Y`_iPhone_SMSs.csv
sqlite3 -csv -separator ',' `date +%b%d%Y`_call_history.db "select * from call;" >> `date +%b%d%Y`_iPhone_Call_History.csv
sqlite3 -csv -separator ',' `date +%b%d%Y`_notes.db "select data from note_bodies" >> `date +%b%d%Y`_Notes.csv

#Convert .plist files to (Human Readable) XML and rename them with the proper file extension.
plutil -convert xml1 `date +%b%d%Y`_BrowserBookmarks.plist
plutil -convert xml1 `date +%b%d%Y`_BrowserHistory.plist
plutil -convert xml1 `date +%b%d%Y`_MapBookmarks.plist
plutil -convert xml1 `date +%b%d%Y`_TrackData.plist

mv `date +%b%d%Y`_BrowserBookmarks.plist `date +%b%d%Y`_BrowserBookmarks.xml
mv `date +%b%d%Y`_BrowserHistory.plist `date +%b%d%Y`_BrowserHistory.xml
mv `date +%b%d%Y`_MapBookmarks.plist `date +%b%d%Y`_MapBookmarks.xml
mv `date +%b%d%Y`_TrackData.plist `date +%b%d%Y`_TrackData.xml

#Copy captured data to central/NAS storage.
echo >> [Enter your pathname.]/capture_daily_files_out.txt
echo "Capturing iPhone data . . . " >> [Enter your pathname]/capture_daily_files_out.txt
rsync -av * [Enter your username.]@$NASIP:/Volumes/LifeData/Phone/iPhone/ >> [Enter your pathname.]/capture_daily_files_out.txt

Notes

Not too difficult right?

Note that I use rsync to handle the photos because I want to only get the photos shot since the last time that the script was run. These are copied to the usual place on the Mac for photos (the “Pictures” shortcut), and they get copied to central storage via another script that grabs daily lifelogging data of my MacBook. (I’ll share that one next post.)

For the browser history, browser bookmarks, SMS log, etc., I use scp to capture the whole file and name it with a timestamp. This will result in a lot of duplication, but I figure that this sort of data is easily wiped from the phone unintentionally. These files are pretty small in the grand scheme, and I prefer the duplication to syncing an empty file to a full one on central storage. (I could also query each DB by the current date and pull out just these records, but there may be some days when the script doesn’t run — when I’m not home — and I could then potentially miss some records.)

Help with converting the SQlite and .plist files came from here and here. Help with getting the .plist files readable came from here.

Testing It

You’ll have to test the script a few time to make sure it’s working. Note that the iPhone has got to be awake for this (a caveat I’ll address below). You might want to set Auto-Lock to “Never” (Settings>General) until you’re sure it’s all working right.

Scheduling It (Making It Execute Automatically)

I used cron (basically you just add a one execute line to to your user’s crontab file using the command crontab -e), but you could also turn the script into an Apple command and trigger it from iCalander. You can use launchd as well. A quick Google search will help you with any of these options.

Caveats

Like I said the iPhone has got to be awake for the copy to happen. I dug for tricks to wake up the phone automatically just before the script is to run, but there seems to be no way to do that (cron, though it’s there, doesn’t work when the phone’s asleep).

I’ll experiment for now with just setting an alarm to go off daily just prior the script run time. Lame, but it seems to be the only way for now.

The lack of cron-like functionality also stymied my effort to get the phone to automatically record a location bookmark on a daily basis. (Part of the drudgery of paying taxes as an expatriate involves counting up days spend in various countries. It would be convenient to log that automatically, even if it is only Skyhook accurate. I’ll have to work on another method for that.)

Random Thoughts in Closing

I’ve just been running this script for a few days, but so far I really like it. It will pay benefits in my grand scheme to auto-summarize my daily activities. It’s myriad of life data is key for this. (It’s the closest thing we have in real life to the Star Trek tricorder.)

I’ve also found it convenient to have all my current iPhone data on my Mac and have it automatically (well, almost) updated. No more wiring it up and copying off the photo I want to post, etc.

Last thought for this post: In figuring out how to capture all this life data, I found it remarkable, especially as a former student of a couple of grad level computer forensics courses, how often Google led me to various computer forensics sites. iPhone data (or smartphone data in general), it would seem, is the new weapon of choice against cheating spouses and embezzling employees every where.

Perhaps I should be running a smartphone forensics firm instead of writing this blog.

• I want it to be as passive as possible. When I’m home and near my wi-fi router I want all lifelog-relevant data to be automatically siphoned off my laptops and mobile devices and copied to my central storage. This will mean, for me, the use of rsync scripts tee-ed off by cron jobs.
• I want summation of all this centralized data to be as automatic as possible as well. For this, I plan to have DevonThink regularly and automatically index the slew files on central storage, and then, probably using some OSX Automator routines, build for me upon request a daily digest of what I did on any given day:
  • Where was I (based on iPhone SkyHook data, e-mail headers, etc.)?
  • With whom did I correspond via e-mail, SMS, chat, and to whom did I speak to by phone? What was said?
  • What photos, videos, and voice memos did I create?
  • What did I view on the web?
  • What podcasts did I listen to?
  • What video and audio content did I consume via Boxee, etc.?
  • What ideas did I come up with?
  • What did I spend money on?

  This kind of record will be very useful for me professionally. I’m a remote worker and this system will give me the ability to furnish my employer with a great deal of detail about my work activities should they request it.  Moreover, this kind of system, I’m sure, will one day be a great boon to me in terms of triggering bio memories that have faded over the long haul.

• I want mechanisms for easily publishing the non-private bits of my my autogenerated daily digest to social networking sites. This is again going to involve some DevonThink automation, as well as, perhaps, a web service like Posterious (which I’m only now learning about.

Plank one above is very nearly finished, and the nitty-gritty details of my implementation will be the subject of my next post.

Bell devotes quite a lot of pages in his book to quantifying how cheap it’s gotten and how it’s only going to get cheaper. Ray Kurtzweil will happily tell you its going to get exponentially cheaper and help us achieve singularity in our lifetime.

Still, it’s not free. You’re going to have to trade or barter something for it.

It’s likely to be worth some outlay though to be able to conveniently centralize your life data. If you’re like me, you already have a masses of binary data, but it’s spread across multiple devices. Insights about your life could come quickly, if you could only corral it all into one place, start processing it (with passes for optical character recognition, pattern recognition, speech-to-textand so on), and come up with a means to index and search it all (a “Google” for your life data, in other words).

As part of my day job, I install and maintain large-ish (~200 TBs), high performance RAIDs (Redundant Array of Inexpensive Disks), so I know something about storage, though I won’t claim to be an expert. I don’t need anything like a RAID that’s that large, but I knew even building a small one (4 TBs was my goal to start my “LifeDataHopper”) could get expensive when you factor in a host machine that has a decent motherboard, a good PCIe RAID control card, a SATA disk enclosure/back plane, 1+ TB drives, etc.

So I started this weekend just Googling for much cheaper, software-only RAID solutions. In keeping with my mantra to repurpose what hardware I can, I even toyed with the idea of using a subnotebook PC I have lying around as a host, buying a cheap USB hub, attaching what external USB hard drives I already have, and striping them all at RAID5. Linux makes it simple to make a disk array out of basically any storage devices it detects (it doesn’t care if they’re from the same manufacturer or even if they’re the same capacity). You can then keep growing the RAID by adding additional drives and rebuilding. For example, here’s a how-to from a guy who made RAID out of a bunch of USB thumbdrives.

Cool, but the problem with using USB as the connection method is that it’s read/write times are too damn slow, as many people point out here. You’d at least need a lot of USB controllers on your motherboard, and even then USB2 isn’t such a fast protocol.

On the other hand, if you happen to have a machine lying around with multiple SATA controllers on the motherboard, a software RAID might be a good solution to get your life data storage going.

I didn’t have a machine with specs like that, or one with a spare PCIe slot for a decent RAID control card, so I started thinking about a wireless NAS (Network Attached Storage) solutions. There are lots of these out there — basically they’re boxes that hold two to four SATA drives, can stripe them into a RAID via onboard hardware , attach to a home network router via 1Ge or Wi-Fi, and let PCs and mobile devices on that same network access the storage.

By this point, I was tired of Googling things and headed for Pantip (sometimes you’ve just got to get outside and make a life to log), Bangkok’s largest electronics bazaar to just see what I could find. Mostly by chance, I stumbled upon this solution, a RAID enclosure with onboard hardware for striping and building a RAID from up to four SATA drives. There’s no network interface, but there is a slew of connections option (USB 2.0, Firewire 400/800, and eSATA) for connecting it up to a host PC. I put four 1 TB drives in it (though I could have gone for 1.5 TB or even 2 TB drives), attached it to the Windows box I have attached to my TV and home theater system (my Boxee media server). Setup was easy (though Googling was involved to get Windows to recognize a >2 TB partition).

The reviews for this unit are largely good, but there are some complaints too (as there is with all hardware). I’m not too worried though. I plan as well for off site backups of my life data to AmazonS3 for a secondary level of redundancy. That’ll have to be a topic for a future post though.

So, for less that 500 USD (and prices on imports here are inflated somewhat — you can likely get something like this going for cheaper in North America or Europe), I now have 2.72 TBs of usable life data storage (the rest is lost to RAID5 level redundancy, but this means that so long as I don’t lose more than one drive of the four simultaneously, my data is reasonably safe).

Now, let the consolidation of my life data begin!

The good news is that lifelogging, probably with a lot of help from Bell’s book, seems to be reaching a critical mass. When starting this blog, I first had a look around the blogosphere. (No fun writing about something if there are thousands of others out there doing the same.) There weren’t many blogs on the subject (and I try to link to them as I find them), but, interestingly, those that I did find all began within the last couple of months.

Lifeblogging, it would seem, is just emerging into the collective consciousness.

And where there’s a trend, there are products right on the heels of it. Many life-logging related products are now coming onto market. Just yesterday it was announced that Bell’s perhaps coolest lifelogging gadget, his SenseCam (or at least an adaptation of it), will soon be purchasable (for less than I bought my first digital camera).

Earlier I outlined what sorts of data streams I want to start capturing into a lifelogging system, but what are to be the major components of that system?

Even before I ask that question though, I have to ask myself a simpler one: How much have you got to spend on this venture? And the answer is not a lot. In building the system, I intend to stick to a few ground rules in order to not break the bank:

• Where possible, I intend to use hardware I already have and can re-purpose.
• When I have to buy hardware, it won’t be expensive and bleeding edge. It will just be good enough to get the job done (without jeopardizing the ever growing data corpus).
• Where possible, I intend to use Open Source solutions over commercial ones.
• Where possible, but within reason and within the limits of my skills, solutions will be DIY (do it yourself). This may mean I need to build a Linux box to do a special something, or write a quick batch script to do another special something. That’s about as complex as it will get though. I’m not a programmer, just a technical support guy in the post production industry.

Like all culture-shifting technologies, lifelogging comes with upsides and downsides. The upsides are:

* Better memory about our lives; literally photographic memory

* Evidence when we’re falsely accused

* Capturing of amazing events

* Evidence against criminals and sociopaths when we witness crimes

* Ability to share our memories, strengthen personal bonds

* Leaving our lives for posterity

* Self examination (Wow, I’m spending all my time working!)

But the downsides are:

* Potential privacy abuse

* Potential accidental abuse of other people’s privacy

* Self incrimination

* Behavior change (will people act differently when everything is recorded and shared?)

History shows, however, that most people will gladly give up their privacy and take on a few other risks in order to enhance social sharing.

Read his full post here.

Well, a point made more than once in that same book is that it’s tough to say what data will be important in the future, and it’s cheap to store it anyway, so capture and save basically everything you can. The authors’ examples on this point are quite practical: Who can say for sure what the IRS might demand in an audit?

I think it goes deeper than that. Just based on my experiences so far of scanning and converting to search-able text five or six years worth of financial data, it’s become clear that every receipt, every scrap of paper, might have future utility in jogging memories, in helping me and my progeny reconstruct your life, my whereabouts, my thoughts, my emotional frame of mind, and so on. Just scan it, or other wise capture it. Just throw it all into the hopper. The software for organizing all this data, for finding connections between all those disparate data points, will only get better.

Now you can make all this data as private or public as you wish, but think about things for a moment from the perspective of a future historian. If that historian is attempting to reconstruct the life of an average citizen of, say, Amsterdam in 1580, he or she probably has remarkably little data to work with: a few city records of birth, marriage, death, taxes paid, property purchased, and so on. Perhaps, but more than likely not, the subject left behind a journal and some correspondences. That would be about it.

Vast swaths of that subject’s life experience are simply unrecoverable. It’s as though they never happened.

Contrast this with what the historian could glean about a day in the life of an average person today from an industrialized part of the world who bothered to deliberately capture even a small portion of the data on the list below. From even just the relatively small amount of data I’ve started to centralize from my finances, e-mail correspondence, journal entries (yes, I keep one, on and off), photos, etc., I could pick any day in my life in, say, 2004, and recover a startlingly complete picture of my activities and interior thoughts (where I was: what I ate; who I was with, called, wrote, and electronically chatted with; what was said during some of those conversation; what I was thinking about; what my emotional state was at the time; and so on).

OK, but what’s a good sort of minimal checklist? I’m going to start one here. I anticipate that I’ll come back here often and append items to the list. I’ve loosely organize things based on their ease of capture. If a data stream is already in binary form, and it’s simply a matter of centralizing it, I’ve listed it first.

Some of these datastreams are only going to get easier to capture with the advent of commercial products like wearable cameras and wearable/implantable biometric sensors.

Textual Data

• E-mail.
• Electronic chat sessions.
• Calander entries.
• Finance data in Quicken and similar formats.
• Scanned financial records (bank statements, receipts, tax filings, etc. — everything in that big, ugling filing cabinet in your home office).
• Scanned medical records (hospital billing records, insurance correspondence, etc.).
• Scanned journals.
• Scanned correspondence.

Visual Data

• Digital photos.
• Digtal videos.
• Webcam feeds (yours and those maintained by other but which might which help paint a fuller picture of your surroundings).
• Surveillance video of you in public spaces (if you could only access that data!).
• Digitized video tapes.
• Scanned photos and slides.

Audio Data

• Conversations via VOIP (Voice Over Internet Protocol) services like Skype.
• Taped dictation, journal, or correspondence.

Biometric Data

• Output from heart rate monitors and other similar devices worn during workouts.

Spatial Data

• GPS (Global Positioning System) data collected from various mobile devices.

(On the subject of spatial data, I was thinking today how cool it would be to write a script to strip location data out of e-mail headers based on the domain name of the smtp server.)

Personal Digital Forensics Data

(What metadata could you start capturing from all the computers and mobile devices that you now use?)

• Web browser history.
• OS logs (detailing application startup and stop times, etc.).

Public Digital Forensics Data
(What data did you leave behind as part of your interactions with the Internet.)

There’s something scary about it all too. Presumably one of your end goals is to throw out all that tree pulp (while thanking the trees for the lives they gave for nothing). Throwing away things, especially by way of a shredder, is certainly irrevocable. You just can’t get that stuff back!

So you first have to make sure you don’t physically throw away any scraps of paper that you might physically need one day, for an IRS audit (God forbid), or whatever.

Google won’t help much as an oracle or arbiter on this one. You’ll find debates over for how many years you should hold onto paper tax returns (like the IRS doesn’t already have their own copies). And you’ll find many people advocating that you keep a good deal more paper around than I feel necessary.

You’ll also find people advocating for a minimalist approach to paper. As you might have guessed, I’m for the minimalist approach.

Before I shredded that first 6-inch stack of paper, it helped me to read this article on the IRS’s rules about electronic storage systems. That it’s penned by an attorney helped turn that initial trepidation into glee as I watch those that first six-pounds of paper turn to hamster bedding. He answers the question of what financial papers to keep with this:

Obviously, there are some documents that should be kept in original form. Promissory notes are one thing that comes to mind. Generally, you need the original promissory note to cancel a mortgage once the note has been paid off. But, in Louisiana at least, you can even get the mortgage canceled if the note is lost. It’s not easy, but it can be done. In short, it’s okay to err on the side of caution but do yourself a favor and be practical. Keeping paper just because some vaguely imagined legal authority might ask you for ‘an original’ is not the way to organize your life.

I’ve also double checked with my tax accountant, and she basically agrees with the sentiment.

I’m neither and lawyer nor an accountant, so I can’t provide anything like professional advise in the sphere of tax law (for my own country or for any other from which a future reader may hail). However, the basic rule of thumb in my house is that if it’s not associated with some purchase above six figures and if it’s not notarized or specially emblazoned with some sort of 3D hologram marking it as the original document, it winds up as hamster bedding.

I want to make something like a Grand and Elegant Repository of All Life Data (GERALD). I want all the disparate bits of all digital data related to life — all the photos, the music, the videos, the journals, the financial records, the e-mails, the chats, the web surfing trails — that reside on so many different machines and portable devices shoved inside GERALD.

I want all the life data that still resides in analog form, shoved inside GERALD.

And I want to share within these pages my strategies for making this GERALD, and I want to answer here all the questions that come up when making a GERALD. Some will be technical and mundane but necessary: What’s cheapest way to build an ever extensible RAID?

Some will, hopefully, be exciting and more theoretical: Will your data survive endlessly in the form of an avatar to which your progeny can pose questions and receive accurate answers back based on the terabytes or petabytes of data you’ve amassed?

In short, I want to help people make their own GERALDs (that’s the last time I’m using that acronym in this blod) and then share with other what they find within it.

I think it’s an important undertaking for everyone. It’s important to make even the simplest of starts on it, to just start keeping the data around, all of it, even that which seems trivial now, in a safe, private place. Future technologies will provide myriad ways to connect up all the data that you’ve managed to save, to find the surprising patterns within it, to tell you and your progeny on what day it was that you first met your wife, saw the ocean, and so on. But you have to at least make the start. You have to save and protect your life data.