You Got Your License In My Keychain!

The One In Which Paul Talks Out His Hat (metaphorically, since he and hats don’t get along).

During an entertaining aside in Andy Ihnatko‘s keynote at this weekend’s Voices That Matter conference, I was reminded of a thought I’d had a while ago: Why don’t Mac desktop applications store their license info in the Keychain?

Complaining about restoring license keys should be just as trite of a humor topic as little bags of peanuts on flights, but it still holds true. Go to restore a machine, or move to a new one with a clean install, and you can write off at least an afternoon launching and entering at least two text fields per application.

Maybe I’m the only one who feels quite comfortable with syncing to MobileMe–I actually consider it the feature that keeps me coming back. (I do know there are people who have frustrating issues, and I truly feel for them, but I continue to believe they are in the minority.) Given that setup, here’s how I’d see setting up a new laptop:

  1. Configure my MobileMe account and sync down the data, setting up my Mail accounts, Address Book and Calendar–and Keychain.
  2. Launch a new copy of my licensed application.
  3. There is no Step Three. Go on your merry way.

I’m not expert enough to suggest that it would improve security of your key, but it sure would discourage casual tweaking more than the plist or hidden file schemes you’d need to develop on your own. Also, separation of license key from a preferences file (hopefully developers are already doing this) allows a user to delete the preferences and start fresh without having to worry about relicensing.

I understand that Keychain development can be convoluted, but is that reason enough to not make the user’s life a little bit easier and your support burden of finding a lost license a little less frequent?

As I said at the top, I realize I’m talking out of my…hat here. I don’t have experience doing this (yet), so I am interested in hearing reasoned arguments. Until and unless this is proven untenable, simply consider it a feature request for your next release.

  • Ilja

    Most likely because Keychain has an ugly, hard to use API dating back to System 8. I can understand why programmers prefer Preferences/NSUserDefaults.

  • http://twitter.com/fetchguy Jim Matthews

    We see a lot of corrupt keychains in our tech support. I would not want to be in a position where my app would not work until the user fixed a broken keychain.

  • http://www.karelia.com/ Dan Wood

    It would be really annoying for the user to have to enter their keychain password just to launch an application. I’d rather the licensing check be as unobtrusive as possible. It’s no problem for the user when they know that confidential information is going to need to be accessed (such as login information for an upload that’s about to start) but just to launch? No thanks….

  • http://www.karelia.com/ Dan Wood

    It would be really annoying for the user to have to enter their keychain password just to launch an application. I’d rather the licensing check be as unobtrusive as possible. It’s no problem for the user when they know that confidential information is going to need to be accessed (such as login information for an upload that’s about to start) but just to launch? No thanks….

  • Graham at Fuzzy Aliens

    First, the elephant in the room. License management code is _not_ an affordance. It’s not even _supposed_ to make the product easier to use, it’s supposed to make it _harder_. The whole point of licensing code is to reduce accessibility to the app to those people with strong motivation to get the app to run properly: users with financial skin in the game and crackers. Making license handling more automatic is like making safes easier to open.

    Ok, with that out of the way, let me answer the question you actually asked :-). License code (at least, the working license code) relies on some cryptography mechanism to ensure that the file was actually created by the developer or vendor, just like the Mac app store licensing works. That’s fine, but the specific abilities of the keychain don’t support the operations needed to do licensing, so from the functional perspective there’s nothing to gain from using the Keychain.

    So what about the easier syncing? Two things: going back to my first paragraph, the goal of a license is to restrict the number of computers that can run the software. Second thing: even with file-based licensing, syncing is possible: DropBox, MobileMe, or sneaker net solutions like email.

    And then there’s the potentially reduced usability. Most users leave their keychain password synchronised with their account password and have it unlock automatically, and these users aren’t affected. But for users with other configurations, every time their keychain locks the software can’t access its license without intervention.

    I would therefore conclude that while storing a license in the keychain is possible, it’s more work for the developer with no material benefit for either developer (the true “customer” of license management code) nor user.

    Graham.

  • http://corporationunknown.com/ Paul Goracke

    Excellent points. I had forgotten about locked keychains, but a crash took out my login keychain not long ago and all the authorization requests after restoring it were definitely UAC-level frustration.

    Isn’t a signed binary supposed to alleviate that necessity, though?

    As for keychain corruption…I’d like to put that on Apple, as “if you want users and developers to rely on this, make it bulletproof (and easier to code) because people are getting scared away.” But other than the mentioned incident, I haven’t had these problems (as a user–I’ve not yet developed to it). I don’t deny it exists; it just hasn’t beaten itself into my awareness.

  • http://profiles.google.com/honestpuck Tony Williams

    Apart from the problems of the terrible API and corrupt keychains, if you put the license in my keychain then only one user on the Mac is licensed and to put it in the system keychain requires an admin verification, does it not? I don’t like an application that does that.