by Eston Bond
May 18, 2007
Recently, the blogosphere was set ablaze by what appeared to be death threats received by usability expert Kathy Sierra, in which she was portrayed in various explicit situations and sent explicit emails/comments from seemingly misogynistic users. Among those targeted was Chris Locke, an author of the popular e-marketing book Cluetrain Manifesto, also an "A-list" blogger himself. Meanwhile, Robert Scoble's wife Maryam also received similar threats from anonymous bloggers, adding fuel to a fire that stuck in Technorati's Top Ten searches for nearly two weeks after the scandal was made public on Sierra's blog.
While to many the issues seem like little more than overhyped blog drama, the issues highlighted in these threat cases showed just how large of a failure exists in the current methods used to increase user participation. The internet is still a land dominated by IP identification, a method easily bypassed by the use of free proxies, public terminals, or other privacy-protecting systems such as the EFF's Tor privacy network. Along with a proxy, a free email address from a service such as Gmail or Yahoo! Mail, and some malicious intent, virtually anyone can dish out explicit, violent threats to bloggers and other online authors while staying almost entirely untraceable.
The issue of trust brought up a large discussion between bloggers on how to solve the issue, and, as is the case with any large community, there seems to be little convergence on a single answer. Tech magnate Tim O'Reilly called for a code of conduct for bloggers, with one possible rule being the elimination altogether of anonymous comments on blogs. With systems such as WordPress, this would require users to actually register accounts on individual WordPress blogs, leading to an extra interactive hurdle in user participation and thus drastically cutting the chances of people commenting on a blogger's material. With the most common ways of "authenticating" yourself on a blog--a name, email, and possibly a URI (Uniform Resource Identifier)--I could easily assume the identity of someone else simply by typing in their name and email address, and unless there was email authentication of comments or other such things, I could easily get away with it.
How, then, should we solve such a massive identity problem? This is a vulnerability that goes well beyond the software; it is a flaw in the interaction processes we have built into blogs and other social media, and, now, with people already accustomed to the ability to quickly comment on posts, changing the system will be difficult and impossible to do in the short term. It certainly seems that the best way for us to maintain authenticity is with reputable login systems, but the current one-site-only login systems are generally too costly for the user for them to bother. Because of this, we are left at an interaction designer's impasse: do we restrict anonymous comments to a login system and gain a greater degree of authentication, or do we simply continue to allow anonymous comments and hope for the best? One must weigh a multitude of costs associated with each action.
The ideal solution to this problem would be a system that:
Allows for a simple login across sites. One of the biggest problems with authentication to individual blogs and other sites is that most solutions in use today require users to have accounts directly with those applications. Unless someone is an extremely avid reader of a specific blog, their chances of signing up for a commenter's account on the blog are near zero: it's simply not worth it, especially when the opportunity cost is the ability to comment freely using the name/email/URI combination on another blog that allows for such commenting. By establishing a system that allows use of that login information across a large amount of the blogosphere (as well as in other social media applications), the costs of registering an account using the universal authentication protocol decrease by the number of sites using the protocol. For example, if a user registers on your blog to comment on your blog, the five minutes taken to register is solely consumed on your blog; if the same user registers a universal ID they can use to log in to all of their favorite 100 or so blogs, the end cost is negligible.
Ties the user to something more identifiable than email. Email accounts have really been a dime a dozen since the late 1990s--anyone can get a free email address from tens of thousands of free email providers yearning for your web traffic. Anyone familiar with the Web these days knows that authentication-by-email is horribly insecure and really means nothing. In social media, the majority of us are content creators as well as content consumers: it would be logical, then, to be able to tie ourselves back to our own content. Of course, even this is still fairly insecure, as users could link to empty blogs or other such pages, although comments made by such users could be deleted and their IDs quickly blacklisted.
Requires a user interaction flow as simple as current login methods. Every increase in complexity for the user will increase interaction cost, which then decreases the number of users willing to participate. Logging into a new identity system needs to be as fast as or faster than the current name/email/URI authentication method used throughout most of the social web. Any increase in interaction cost has the potential to turn away contributors, so unless absolutely necessary, there should be no quantifiable increase in interaction cost.
Of course, no solution is perfect; if there were a perfect authentication solution, it would have been implemented long ago. Implementing anything new requires the introduction of issues of user adoption curves, QA testing, and other complexities that lead to the old adage of "If it ain't broke, don't fix it." For many, however, social media authentication is most certainly broken. The most easily implemented solution is already used by plenty of early adopters, and while some adoption exists, OpenID seems our only hope of solving this authenticity issue anytime soon. OpenID effectively solves the three interaction hurdles above while adding large value to a rather undeveloped part of social media software.
Recap: The Simple OpenID Model
For those unfamiliar with the decentralized OpenID, note that OpenID requires participation from both blog owners as well as blog commenters. Commenters must first get an OpenID, which ties their identity to a specific URI. In most cases, a URI is a permanent home for that user on the Web. In my case, that URI is http://hyalineskies.com/, my blog. OpenIDs come from an identity provider, a company that will "park" an OpenID spot for you much like companies do for domain names. In any case, free OpenID identity providers are everywhere: if you have an AOL/AIM screen name, you already have an OpenID, and your URI to access it is http://openid.aol.com/screenname.
To use your OpenID on other sites, however, software must be installed that allows for authentication with OpenID servers. Those accepting OpenID logins were originally called consumers, but are now referred to as relying parties. You'll still hear people call OpenID-accepting sites "consumers," so be prepared for both semantics if you get deep into OpenID development.
Everyone's an Identity Provider
OpenID has somehow been able to become a trend among tech cognoscenti, and, as with any trend in the world of Web 2.0, has seen plenty of hype surrounding it. Because of this hype, many companies have quickly wanted to jump onto the OpenID bandwagon.
Of course, being a true OpenID adopter on both the identity provision end as well as the relying party end takes a large amount of development time. However, implementing the identity provision end is much easier than being a relying party for most large-scale organizations, so everyone has been quick to become an identity provider. Identity provision is an easy way to be part of the OpenID bandwagon and also has a lot of positive business strategy surrounding it, sure to appease the penny-pinching administrators of any company: using URIs at the domain of the company effectively increases "mind share" and brand identity for the identity provider. As the user's OpenID becomes more established, it also increases both traffic for the provider as well as that wonderful "lock-in" as the user establishes that specific provider as theirs. (Being an OpenID identity provider also means that you're "with it" and "hip," both terms I use rather cynically.)
All of this identity provision, however disproportionate to relying parties it is, is still a good thing. Any adoption of OpenID is both necessary and desired at a point when the identity system is still in its infancy: the more ubiquitous the identity provision, the more users--both techie and pseudo-Luddite--will be curious as to what OpenID is. This increase in exposure is necessary for large-scale OpenID adoption, which in turn is necessary for OpenID to become a viable candidate for global blog authentication.
The relatively large number of OpenID identity providers at this point leaves the beginning OpenID user in a minor dilemma: what identity provider should one choose? AOL, here, is an identity provider, but so are ClaimID, My OpenID, and VeriSign, all of which offer an array of OpenID URIs. For those of us that are part of social content creation, however, it would make the most sense to have our OpenID URIs be our blogs, MySpace profiles, or other frequented properties of ours. While if you have a blog on WordPress.com, LiveJournal, or Vox you're already covered, those of us with standalone installations, such as the version of WordPress I'm using at hyalineskies.com, will require site owners to either host their own OpenID identity provision tools or have a way to have the standalone blog URI act as an OpenID delegate URI.
While my inner geek considered running my own OpenID identity server, I quickly found out that I could use my already-created AOL OpenID with hyalineskies.com as the trusted URI, as long as I posted two link tags in the document <head>. Now, if you view the main page source at hyalineskies.com, you'll notice these two tags:
<link rel="openid.server" href="https://api.screenname.aol.com/auth/openidServer" /> <link rel="openid.delegate" href="http://openid.aol.com/hyalineeston" />
By placing these two tags in my WordPress theme's header.php file, I can then use that URI--as well as any other URI that references that header--as my OpenID URI. To restrict your OpenID URI to a WordPress blog's home page, you can use the is_home conditional, wrapping the link tags as such:
<?php if(is_home()) { ?>
<link rel="openid.server" href="https://api.screenname.aol.com/auth/openidServer" />
<link rel="openid.delegate" href="http://openid.aol.com/username" />
<?php } >
(In your case, you'll want username to be your AOL/AIM screen name, not mine.) Once you have this set up on your blog, you can then use your blog's URI as your OpenID URI without having to run the identity provider server on your own site. By using our own website URIs as our OpenIDs, we establish not only a proper way to authenticate with blogs, but a link back to ourselves and our own content that is more secure than that of the simple URI field on most blogs now. We can prove that we're the owners of the blogs in our OpenID URIs, increasing trust and accountability.
By doing this, we can help mitigate the problem that I talked about at the start of this article: people pretending to be someone else as they post inflammatory or threatening comments on other people's blogs. OpenID offers a means for combatting this type of activity, which is so easily achieved in today's blogosphere.
Conclusion
All of this adoption of OpenID identities, either from us or from those seeking to be identity providers, is great; however, OpenID is still costly to users unless the blogosphere also adapts its existing tools to allow for OpenID use on the majority of standalone blog installations. The rather disproportionate amount of providers (and existing identities) to sites where you can actually use them is staggering; after all, being a relying-party is much tougher than signing up for yet another account or placing a quickly configured PHP script on your own server to provide identities. Instead, being a relying party requires a blog owner to write basic OpenID authentication code and hack their existing layout files to allow for OpenID consumption. This programming creates a greater hurdle for relying-party adoption that few feel prepared to tackle.
For the next article of this two-part series, I've interviewed some of the most prominent authorities in both the blogosphere and the OpenID movement, explaining both how to become a relying party on your own blog as well as the future of OpenID on sites such as WordPress.com, social bookmarking service Ma.gnolia, and TypePad. For now, however, let's take the one small step; eventually--hopefully--we can then continue onto the proliferation of OpenID relying parties to fully add authentication where recent events have shown we need it the most.
OpenId!
OpenId is the future!
Bst Rgds,
Michael B.