I was inspired to think about the problem of impersonation on the web, when I read Caterina Fake’s comment on Twitter, bemoaning the fact that somebody was able to impersonate her in a comment on GigaOm. Because they used an email associated with her by Gravatar, the comment gained an element of authenticity because her avatar picture appeared by it.

My initial reaction, like Caterina’s, was to assume there is something wrong in the Gravatar model. Why should somebody be able to masquerade as me simply by guessing the email address I associated with Gravatar? But Matt Mullenweg of Automattic, which owns Gravatar, explained concisely that the fundamental problem of impersonation cannot be prevented by their service. An impersonator could just as easily have associated a new email, “[email protected]” with Gravatar, and uploaded a copy of her avatar.

A Hopeless Situation?

I am convinced by Matt’s claim that Gravatar is not in a position to prevent impersonation. However, it’s possible to imagine ways in which Gravatar could promote authenticity. Gravatar already allows me to create an account through which I claim email addresses and can control which avatars should appear for these addresses. In addition, it allows me to confirm that account’s association with certain services such as Blogger.com, Facebook, Twitter, etc. This, combined with the fact that use of Gravatar is already widespread on the web, makes it a great candidate for serving as an arbiter of trust in arbitrary contexts on the web.

Web sites that make use of Gravatar’s services are currently able to fetch an image associated with a particular email address, by manipulating (hashing) the user’s email address in such a way that the email address is no longer discernable, but Gravatar can easily look up the associated avatar image.

There are steps that Gravatar could take to make possible the “authentication” of specific Gravatar appearances on the web. It would be exhausting to elaborate on the variety of ways this might be done, and many of the options that spring to mind also bring to mind many pitfalls and annoyances, not to mention significant service demands on Gravatar. Maybe the authentication would require hosting sites to present authentication keys, or maybe users would just whitelist particular comment URLs. Let’s not get bogged down in details: the details are for companies like Gravatar to take on if they choose to meet the challenge.

In a world where Gravatar offered some form of per-use authentication, a site like GigaOm could show a trust icon next to commenters’ avatars, or maybe it would be integrated into the avatar as a form check-mark badge or something. Click on the trust icon and it might take you to a Gravatar page where a curious reader could gauge authenticity with Gravatar’s help:

The Gravatar being shown at <link to e.g. a comment url> was verified by Daniel Jalkut, a registered Gravatar user. Daniel is known to be associated with Twitter ID “danielpunkass”, and controls the web site domain http://www.red-sweater.com. For more information, view his profile here.

The current Gravatar user profiles already lean strongly towards identity confirmation. Some clever techniques for authenticating comments would not eliminate impersonation, but would allow identity-concerned users such as Caterina a means of participating in web conversations while proactively confirming their own identities.

Apple has approved FlexTime for the Mac App Store, where it is now available for purchase. As with my other App Store offerings, Black Ink and MarsEdit, customers are invited to purchase through Apple’s store or through my own. All of my apps are functionally identical, except for in the areas of license management and software update, where Apple’s integrated processes take the place of my home-grown stuff.

The review process for FlexTime was quite long, but I have to hand it to Apple’s reviewers. They found a really bogus bug in the application that would have been embarrassing had it passed their scrutiny and reached the public. It was an issue I introduced in the process of modernizing the code for the store. This is the way I imagined the review process working at my most optimistic, so I’m glad to see that it can work out that way.

My friends at Voices That Matter are putting on another iPhone Developer’s Conference in Seattle, this April 9-10. I have had a great time speaking and attending these conferences in Boston and Philadelphia. I won’t be able to attend, because the travel would be a bit hard for me coming right on the heels of my speaking engagement at NSConference in the UK.

If you’re thinking of going to Seattle, be sure to sign up before February 25 to get discount pricing. They also gave me a coupon code to share, “SEABLOG”, that will get you an additional $100 off the discount rate, for a total price of only $395.

One of the challenges existing Mac developers face with the Mac App Store (MAS) is whatever copy protection you have been using up until now has to be thrown out in favor of a protection scheme based on Apple’s App Store “receipts,” a tiny cryptographically signed file they place inside purchased applications that let your app confirm the authenticity of an application upon launching (and at any other time).

This leads to a conundrum if you continue to sell software directly, or offer preview beta releases for direct download. How can you offer access to these releases for customers who purchased through the MAS and thus do not have the “Registration Code” that direct-purchase customers receive? Apple provides no means of determining the identities of, or contact information for, authorized MAS customers. But even though I don’t know who these customers are, I want to treat them as first-class customers in every regard.

For me, I decided that the compromise is to provide, for those MAS customers who want it, full access to the direct-download versions of my software. Today, any customer who buys a MAS edition of my applications will find that, after running that edition at least once, they are automatically authorized to run direct-download versions of the app from that time forward.

A Recipe for Mass Authorization

How did I achieve this bit of wizardry? And more importantly, how can you, or other developers whose apps you love, achieve the same thing? There are three major code-level changes that I needed to make. I’ll discuss those changes, and some of the potentially non-obvious considerations to keep in mind while making them.

1. The MAS edition must stash its receipt somewhere obvious for the direct-download edition to find it. Because both editions of my app share a common Application Support folder, I chose to store them here. Inside the Application Support folder, I create a subfolder called “App Store Receipts” that contains the pertinent receipt files for this app.

   Why a folder? Because a customer may sync or copy their App Support folder across various Macs, I chose to store each receipt keyed by the computer’s GUID, which is derived from its wired ethernet MAC address. Developers who have implemented app store authentication will be familiar with this value.

2. The direct-download version must, in the event it is not already authorized by a standard registration code, look for secondary validation in the form of a receipt in the aforementioned location. If it finds a receipt, the same type of validation is performed on the receipt as would be performed in the MAS edition.

   You will want to apply some lenience when interpreting the validity of the receipt. For example, you probably want a receipt authorizing version “3.0” to also be considered valid for “3.0.1” or “3.0.1b1”. Similarly, if you use separate bundle IDs for your MAS and direct-download editions, you will want to consider the MAS bundle ID as valid for the direct-download version.

3. If you used a different bundle ID for your MAS and direct-download editions, then for the sake of the users sanity and yours, you probably want to implement some kind of transparent migration of preferences from one edition to the other. You don’t want customers to have to go in and reset all their preferences when they switch, and it can be annoying as a developer as well.

   I had some preference migration code around from when I transitioned MarsEdit and Black Ink from their previous companies’ bundle IDs to mine. I reused that transition code, with a bit of careful but appropriate logic: if the other bundle ID was modified more recently than mine, then import it and replace my defaults. The same logic is applied in each edition so that whatever version you run, you’ll feel as though you’ve picked up all the latest preferences from the last time you used the app.

With these changes in place, I have the flexibility to offer direct-download versions of my software to any MAS customer who asks for it, or for customers who I request the assistance of in testing a pre-release bug fix. In most cases, I can just ask the customer to run the app. In the worst-case scenario, when a receipt has not yet been “stashed,” I have only to ask the customer to run the MAS edition once before trying the newer release.

Pitfalls and Downsides

This solution isn’t perfect. In particular, it brings MAS customers into the fold for direct-download software, but does nothing to soothe the existing and new direct-purchase customers who wish for access to the benefits of the MAS: sharing reviews, mass-updating purchased software, etc.

Worse, it leads to a potentially confusing situation where a customer may be running version 3.0 of an application that they direct-downloaded before Apple had approved it. When Apple does approve it and it goes live on the MAS, they are notified inside the App Store about the available update, but when it does update, it will update the previously installed MAS version, and not the direct-downloaded one. To benefit from the Red Sweater compromise, customers need to embrace the mental model that MAS and direct-download versions of the application are fundamentally different, and need to be managed and stored separately from one another.

I believe that the people this compromise serves are in general a more technically astute type of customer who will be able to embrace this difference, or will understand it with little explanation on my part. The less technical customers are not liable to be on the lookout for beta releases or “day of” releases of new software, and will happily wait until the MAS notifies them of a standard, Apple reviewed update.