Having gone through easily 50 registration screens in the last few days, reinstalling applications on my new box got me to once again thinking about registration codes in applications.

Somebody last week asked me as I provided them with a software key with Html Help Builder - what's this - this isn't a 'real' key. They were so conditioned to see the eye-crossing GUID style 40 character key code they actually mentioned something. In most of my commercial applications I use a pretty simple registration scheme that's based on a single passkey that activates an application for a user. So the shareware version is not 'activated' and when the passkey is provided the application becomes registered with additional functionality unlocked (or as in the case of Html Help Builder some nag screens and rendering removed).

The key provided is a relatively easy to remember keyword that can be typed into a registration box and it's the same for every user.

Now you might say that's overly simplistic after all it's so easy to duplicate - you just tell somebody else the password and off they go. When I created this key mechanism I gave some thought to creating a typical long unique key and identifying user with that, but really unless you are going to build a sophisticated server mechanism to validate users by phoning home a short keyword is just as good as 40 figure Guid.

If I use a GUID or GUID like value as a registration key and each user gets his own unique GUID I'm not really improving the safety of my key - all I've really done is create a more complex key that's harder to enter for the user and I now have thousands of valid albeit more complex entries that activate the application. Assuming for a second there's no phoning home of any kind you're not gaining anything by a longer key other than annoyed customers. Oh, yeah you can generate keys based on user name, and crc them or otherwise make the key mean somthing, but all that's going to do is create a support nightmare for people calling us up and asking us to retrieve their key for them (or possibly generate them online after the order's been looked up). While I still get those calls or emails, they are very rare (given our user base especially) and when they do come they are easily handled with an automated email that includes download info and registration information.

As far as I can see there's no benefit to customer fitted Id - only downsides. If there's ever any question of validity of a registration that information can be looked up from customer registration information that I have available - the registration key doesn't do anything to help in that scenario. So unless you are building an application that actually checks these registration keys (ie. phone home and spy on your customers <s>) a longer and more complex key buys very little.

So when does a more complex registration key make sense? Seems to me it only makes sense in shrink wrap scenarios where customers walk out with a piece of software that's not directly registered with the software vendor (or whoever is tracking the licenses in the first place). And even then a long ass key is not going to help - a longer key can be copied as easily as a short one so the whole excercise strikes me as moot for anything but truly big vendor software that sell millions of copies. If there's no phoning home long or short key doesn't make squat of a difference for identification or for copy protection. A key is a key and it can be copied.

So my motto has been let's keep this as simple as possible to our customers as well us to myself in terms of support. While I am concerned about people using my software unauthorized I trust that most people are honest enough to pay for it if they use it and it's simply not worth to try and trap those folks that are trying to beat the system and get something for nothing. Not worth the effort as those people generally would not have paid anyway. The occasional password change with version updates also can discourage some of this.

Installation and keeping track of keys is a major nightmare in general. I use RoboForm and I keep all of my registration keys stored away in an encrypted text file. It's not elegant but it works. I can keep track of keys and they're all in one place.

But really it seems to me that it would be awfully nice if Windows had some sort of standard registration service built in natively. The service could provide key generation in various ways and maybe more importantly provide a unified store were registration information is stored and can be accessed - possibly with some sort of master password. All registrations (that chose to implement it at least) would end up there and it could be backed up and restored - so rather than even retyping password information the API would let you just pick the installation item and then register.

That way users would always see the same UI for storing registration information, and developers could use a common mechanism to generate, validate keys and store them on the system. It would also require only putting in keys once, and after that - when moving to a new machine - picking the application that was previously registered.

Ah one can dream. In the meantime I get cross-eyed from typing and retyping 40 character Guid keys. Grrrr...