One Password to rule them all

I am notoriously bad at memorizing. If not, I might have gone to medical school and chosen a more lucrative career than Engineering... But as the number of online services I uses increases, so does the number of account username and password combinations. I try to standardize as much as I can on the same usernames(s) but some sites make this really hard by requiring strange and unusual conventions (name must be at least 8 characters long and include at least special character and number??? Whose name looks like that?) or by dictating that the username be whatever 10 digit number their database uses as the unique key for the account record. Same drama for the passwords, except that using a standard password everywhere has the added disadvantage that once the password is compromised, the attacker would have access to all my various online service accounts - if sHe could guess those bloody convoluted usernames... ;-)

Things got particularly bad for accounts, which I use very rarely and which have complicated account recovery procedures - typically hours spent in AVS and call-center limbo. I admit that I even committed the exemplary no-no of IT security 101: writing my username/passwd combinations on post-it notes! [Which is not as bad as it sounds, since our apartment is not a highly public place and if broken into, I would likely have bigger problems and hassles than changing a few account passwords.]

Before our recent move, I finally adopted a more reasonable strategy for password management and storage. I consolidated my post-it notes into Password Gorilla, which is a multi-platform application which uses the same secure storage file format as the Password Safe application. The original Password Safe application was designed by cryptographer and computer security expert Bruce Schneier - which hopefully should ensure that there are no obvious design-flaws in the encrypted storage format.

Since Password Gorilla has a built-in feature to easily auto generate a different random password for each entry it is really easy to choose unique and very strong passwords for each service. However then having reliably access to the database anywhere and at any time becomes crucial.

Using a format which is a quasi open-source standard, supported by many different applications on different platform, should increase the chance, that I would always be able to find an application somewhere to read and decode the password database, even if something really bad happened to my computer

A convenient way to keep both a backup copy of the database is to store it in the memory of my mobile phone and even better, to have access to passwords anytime on the road is to use an application which can open and decode the password file directly on the phone.

For a while, I have been using Android Password Safe - or rather a not yet released experimental version which allows to import/export an existing password database, which is absolutely essential for sharing the database between the phone and my main computer. However this has been the state for over a year now and it seems as if the author has abandoned the project.

I am glad to see that very recently a new version of a Password Safe compatible application has been released: PasswdSafe. It is a viewer only, which is perfectly fine for my use-case, where the master database is always on the computer at home and the phone is a read-only backup copy. Because it is read-only, the records are displayed nicely in a compact way, even with a quick way to show & hide the password itself.

Some additional features I would like to see is a timeout based auto-lock, which locks the database again after some time, if it is left open and a way to import/export databases into the phone's internal memory instead of reading them from the removable SD-card. Granted, all android phones can be "rooted", after which the user has unlimited access to the phone's internal memory as well through the USB serial-port, but put putting some additional effort before a potential attacker gets their hands on the password database can't hurt... Besides, half the battle is knowing when the database has been stolen - swapping an SD-card and/or quickly copying a file could be done in a few seconds, when the phone is left unattended.

Once a potential attacker has gained access to the password database, the weakest link to crack the database open is by guessing the master password. Since I need to be able to remember it, quite likely it has significantly less entropy than could be contained in a randomly chosen 128 or 256bit twofish key, used to encrypt the database.

But then, my accounts might not be worth the effort of even a systematic password cracking attack, in case somebody technically sophisticated enough manages to steal my phone - but if I were an anesthesiologist, this might be a different picture...

G1 to Nexus One: a review

By any measure, the new Nexus One is a very nice phone: large brilliant display, high-performance CPU core, high-res digital camera, solid low-profile body. With this kind of hardware spec, the Nexus One establishes itself as the current flagship among Android phones. To my liking, it does not have a physical keyboard, which makes for a much more slim and solid feeling body than the G1 for example. In that sense the Nexus One is what I had hoped for in my original review of the early G1.

In the about 1.5 years since the G1 came out, Android has come a long way. 3 major releases of the platform have added important missing features like an on-screen soft-keyboard and helped harden the platform based on experience in the field. At the same time, developers have contributed a wide range of expected and unexpected applications, and learned how to write them so that they don't drain the battery within minutes.

There are now half a dozen or so Android phones on the market and many more in the pipeline. In particular HTC, previously a pure windows mobile shop, seems to be confident enough in the future of Android to release it on their most advanced hardware, a move which would certainly upset their strategic OEM partner Microsoft.

With the success of Android, there also comes the increasing risk of fragmentation into a plethora of mutually incompatible vendor and carrier specific versions. Due to the permissive nature of the Apache open-source license, this cannot really be avoided. By putting out the Nexus One as a leading example of"Android done right, according to Google", Google has now one more way to coerce the members of the open handset alliance to follow its lead and not produce restricted, proprietary and limited versions of Android. In the end it might matter less how many unlocked Nexus Ones Google actually sells, but the fact that they are available might have some effects in keeping carriers and vendors honest.

Compared to the G1, the Nexus One feels very snappy, thanks to the faster CPU and increased memory. While the G1 had physical buttons for standard android operations like "home", "back" or "menu", the Nexus One has dedicated touch buttons at the bottom of the screen. The green & red call control buttons are now missing, which means that all phone operations must be done from the touch-screen. While on the G1, pressing the call button always was a shortcut to launch the dialer, this has to be done explicitly on a Nexus One, either from the app panel or a home-screen shortcut icon. Instead the Nexus One has a dedicated "search" button, which shows the crucial importance of search in "Android according to Google" (more so than making a call, apparently...). Without the physical buttons command buttons, there is now the need for a dedicated on/off and sleep/wakeup button, which is awkwardly placed at the top edge of the phone. Since I always unlock/lock the phone before/after any usage, the location of this button is unergonomic for how I typically hold the phone and is a bit of a hassle. The Nexus One still has the trackball, which I hardly use and which takes up significant real estate on the phone and introduces potential fracture points in the casing (the faceplate of my G1 had cracked along the trackball opening in less than a year). I would happily trade it for sleep/wakeup button on the faceplate or simple reduce the size of the phone by as much.

The physical design of the Nexus One is low key and unspectacular: a flat, sleek shape with rounded edges. But it feels nice and solid in the palm of my hand - how a palmtop computer should feel like. Fortunately gone is the ugly and awkward "Android chin" of earlier HTC devices. So far the only flaw in the case is the somewhat sharp edge of the protruding camera lens.

The charger/USB port has changed from mini-USB on the G1 to the new standard micro-USB on the Nexus One, which unfortunately means that existing G1 chargers and USB cables cannot be reused.

On the software side, Android 2.1 offers gmail support for multiple accounts and a contact applications which can sync to multiple sources (multiple google accounts, facebook, exchange). The home screen application, app tray, dialer and contacts applications have received a significant redesign and face lift, but otherwise the changes are rather minor compared to Android 1.6 released not too long ago.

Overall, I am very happy with the Nexus one as an everyday phone. It is a very capable high-end consumer smartphone and probably the first Android based phone that is clearly in the same league as the IPhone.

Nexus One: the good, the bad and the ugly

So it doesn't cure cancer, solve world hunger or even global climate change - but it's still a pretty nice phone!

At first glance, the large, crisp high-res display get's all the Uhs and Ahs, including how snappy the UI responds thanks to the 1Ghz Snapdragon chipset. With its speed and responsiveness, the phone is a pleasure to use! The form-factor is thin, sleek with ergonomically rounded corners and lies well in the palm of ones hand. The teflon coated plastic case gives it a nice high-end feeling texture. The biggest improvement in software features for my use case is the ability to sync multiple accounts for the contacts and the gmail app - now I can get notifications for email arriving on any of my gmail accounts.

My only serious gripe so far is with the placement of the on/off button, which I need to press each time before and after using the phone. Its location at the top edge, is very un-ergonomic for single handed use - i.e. fishing the phone out of the pocket with one hand, turn on the display, balance it on the palm while using the thumb to swipe the unlock pattern and do the basic navigation. I am also not too thrilled about the protruding camera lens and the trackball, which I hardly ever use, distracting from an otherwise very slick and smooth case.

The hardware specs are probably at this point the most impressive of any phone on the market and the Nexus One should be a serious cure for iPhone envy among consumer-smartphone users who for one reason or another don't want to get an iPhone.

Android Log Viewer

One of my latest favorite discoveries in the Android market is aLogcat, a must-have for Android developers and power users, who want to know more about what is going on on the device. It is named after the logcat command which can be run in the debug shell, typically via the adb tool from the Android SDK, which requires the device to be connected to a host PC through a USB cable.

aLogcat allows to display a log console on the device itself, color coded by levels with options to filter by levels or arbitrary substrings. By default the console updates continuously with new messages as they appear in the log, but it can also be frozen to allow scrolling back through the log history without interfering screen updates. Since logs can also be sent via email, it subsumes the functionality of earlier log collector apps.

Now that the number of devices, configurations and version of Android are exploding, it is less and less likely that a developer can reproduce a particular problem, since they may only occur in particular device configurations to which the developer does not have access to. Tools like aLogcat are often the only way how developers can remotely diagnose a problem, with the help of a user who can reproduce it and is willing to invest some time in getting it resolved.

Online Backup

Since we recently moved, my current backup system has become some what undone. I have not been able yet, to reactive my linux home-server, since neither its power input nor its TV signal output works in the new environment. But since backing up to an aging piece of low-cost hardware running an obsolete version of an OS, which I also happen to use for experimentation does not leave the kind of warm fuzzy feelings which one typically expects from a backup solution, maybe it was time again to look around for another solution.

From a maintainable and reliability point of view, it would be better to store the backups in the cloud, rather than on a single computer in the same room. On the other hand, sending the data out of the room opens up some serious privacy concerns

The solutions for online backups on mac are still a bit limited. There are some portable solutions using Amazon's S3 cloud storage service or the very open-protocol based rsync.net service, which could have supported an alternate target for my existing home-grown script. But since I wanted to primarily backup my media library (music, photos and videos), the storage cost added up to some real money very quickly.

In the end, I started using a commercial solution from CrashPlan, which has both a mac client and a matching online storage service (single datacenter located in the US). The basic client which supports both Mac and Linux is free (as in free beer) for personal use and there is a free trial for the online storage, which otherwise has a flat-rate pricing of about $50 per year.

The backup client runs continuously in the background and tries to be nice to both the CPU and network so that the computer should still be usable, even if there is a backup going on. In addition to the online service, CrashPlan can also do backups to attached hard-drives or in some peer-peer fashion to other computers running the same client.

So far the system has survived the baptism by fire of doing an online backup of my media-library over about 10 days of continuous backup activity, surviving a reboot and several network disruptions without a hitch.

Obviously the quality of backup is measured by how reliably the data could be restored after a disaster, but judging from the experience with the initial backup, the solution seems solid enough to give it a try for a while.

Customized Call Routing

I now have a cellphone plan, where all outgoing calls are metered and very expensive, except for unlimited calls to 3 favorite numbers, which are included in the plan. For our international calling, we are already using a discount carrier activated through a dial prefix, which also supports a local land-line dial-in access to be usable from mobile phones. By declaring the access number as one of my favorites, I can make unlimited calls from my mobile phone at the substantially lower rate of the discount carrier. The only problems is that making calls through the indirection of a voice-prompt menu is very cumbersome!

This is where Phonecard Express comes in. This highly customizeable application inserts itself almost transparently as a filter between the Android system dialer and the telephony subsystem. Whether a call is made from the dialer, the address book or any other intent, the call setup is intercepted and potentially routed through a calling card service. In addition to supporting multiple cards and their specific call setup sequences (access numbers, voice prompt, PIN, etc) Phonecard Express also supports various policies which control which calls are routed through which calling card account or dialed directly. For people who travel internationally and tend to store all numbers in the address book in the GSM style "+" notation, Phonecard Express supports logic to expand the number with a configured international call prefix prefix.

In my setup, I have exception rules for my other two favorite numbers as well as the voicemail access to use direct dialing. For all other cards, the call is automatically routed through discount carrier account. The integration is so seamless and transparent that it is almost scary and the only noticeable drawback over the standard call flow is the noticeable larger post dial delay, partially from loading another application during the call setup flow and from having to dial an access number and key in the number as DMT signals on AVS prompt before the call is really initiated. On the other hand, this is a small price to pay for saving an order of magnitude in per minute calling cost.

Phonecard Express is a great example for the flexibility of the Android platform, where 3rd party applications can very deeply integrated and partially replace default system functionality.

Virtual Phone, part II

I started using the new Google Voice service as my standard US phone number. Since they currently only support international calling (billed rate), but not international forwarding, the current setup is a bit suboptimal and roundabout: from Google Voice, calls are forwarded to my US based Skype online number, with my skype account itself being forwarded to my current cellphone. The only catch is that the post-dial-delay of this whole contraption is too long for me to pick up the call before it goes to voicemail and since the voicemail delay is not configurable there isn't much I can do. I once managed to catch a call today, by leaping at the answer button on the first ring - it was a wrong number...

At least I get an email notification right away, when somebody leaves a message. I could probably just as well turn off forwarding and just use it as a email based voicemail-box.