Copy-Protection Paranoia: Garmin's Mobile XT Maps

Having just shared with you a case study of an excellent product/support combo, it’s now my unfortunate duty to pass along an inevitable counter-example. Remember Garmin’s Mobile 20 Bluetooth GPS add-on for smartphones, which I told you about a month back? Well, after several weeks of beating my head against the wall, I’ve finally figured out what I need to do to get it to work with my T-Mobile Dash…that is if I decide to bother getting it to work with my T-Mobile Dash…and if the California Senate obliges my ideal-location aspirations.

After receiving the shipment from Amazon, I cracked open the product packaging and was surprised to find inside a 2005-copyright edition of the Mobile XT software-and-maps suite…already stored on a 2 GByte Sandisk miniSD card (a card form factor which, you may have already noted, my phone doesn’t support). An email to Garmin delivered an upgraded 2008 version of the software to my door…but once again housed on a flash memory module, albeit this time of the requisite 2 GByte Sandisk microSD variety. What’s the problem? My T-Mobile Dash only has one microSD slot (which, by the way, is not SDHC-compliant in the Windows Mobile 5 O/S generation)…and that slot is already occupied by a 2 GByte Kingston microSD card containing installed programs and music tracks.

What was I to do? I popped the Garmin-supplied card into my memory card reader for perusal, and discovered a few interesting factoids:

• The multi-folder-and-file image was slightly over 1 GByte in size, and
• It contained functionally redundant software builds for the three smartphone-plus-O/S combos that the Garmin Mobile 20 supports: Microsoft’s Windows Mobile, Nokia’s Symbian, and Palm.

Unfortunately, it wasn’t clear which folders and files on the card were unique to a particular smartphone series versus commonly accessed. But fortunately, I was only using around a half-GByte of my existing 2 GByte microSD card at the time. So, I decided to copy the entire image off the Garmin-supplied card to my MacBook’s HDD, then from there onto my existing microSD card (fortunately redux, there wasn’t any folder-off-root name overlap between the two cards).

This workaround seemed to do the trick, at least at first. When I popped the microSD card back in the phone, I automatically got a prompt query as to my interest in installing Mobile XT. The first install attempt locked up the phone; I (based on past experience) deduced a conflict with my Facade-synthesized home screen and, after temporarily resetting to a Windows default home screen alternative, the install completed the second time around. The software automatically found the Bluetooth-broadcasting GPS receiver, and I was also able to Bluetooth-pair the phone and Garmin gear for hands-free speakerphone purposes. But every time I launched the program, I got an error message indicating "Can’t Unlock Maps for Garmin Device with Unit ID xxxxxxxxxx".

Creating a MyGarmin account and registering the product online didn’t help. But when I got a technical support contact on the phone, I figured out what was going on. The software build contains a unique card ID-specific encrypted file which precludes map access from any other storage location. Yes, you’ve got it right…during the Mobile XT production flow, Garmin merges a card-specific file onto each unit. Granted, it’s a novel means of leveraging flash memory’s just-in-time manufacturing customization flexibility, but it comes with several substantial downsides:

• What about folks like me with only one available card slot on our phones? Too bad. We need to transition to the Garmin-supplied card, and oh by the way, that means re-installing any programs or data files we’d already configured.
• On that note, what happens if the Garmin-supplied card somehow gets corrupted? Again, too bad. Since the software’s intimately and uniquely tied to the card’s embedded ID structures, there’s no backup plan.
• And what happens when the Garmin-supplied 2 GByte card fills up with additional programs (hopefully with non-overlapping folder and file names!) and data you’ve installed? Once again, too bad, even if your phone supports larger-than-2 GByte card capacities. This limitation is particularly ironic considering that the Garmin card contains functionally redundant Palm, Symbian and Windows Mobile software builds, two of the three of which are doing nothing more than taking up wasted space in any particular customer’s situation.

Dear Garmin, I don’t underestimate the lucrative potential of maps (and maps upgrades). I therefore don’t underestimate the copyright-infringing appeal of illicit copying of those maps. And I certainly don’t dismiss your right to ‘do what it takes’ to prevent such dishonesty. But I’d like to offer up an alternative tack on the challenge, one that I’d wager is not only more customer-palatable but also simpler (and therefore lower-cost) from the standpoint of your logistics.

It occurs to me that phones contain unique IMEI codes. It also occurs to me that cellular data connectivity is at the functional nexus of the three mobile phone families you’ve focused your attention on with the Mobile 20. So why not supply a generic software image on a CD (in potential combination with a sticker embossed with a unique code), and make post-install IMEI-based online registration through the phone the primary means by which you combat piracy?

For the rare (I’d wager) customer without a cellular data plan, you can offer a backup approach involving MyGarmin registration of the IMEI and an unlock code response from your server that the customer subsequently enters into Mobile XT to fully enable its various functions. And, like other companies such as Adobe, you can also provide a license transfer mechanism by which you encompass scenarios such as a customer migrating from one phone (and therefore one IMEI) to another, or a customer selling his/her Garmin gear (and therefore transferring his/her software rights) to someone else.

What loophole am I overlooking, readers (including Garmin reps)?