Lessons from Twitterank launch

The Twitterank experience this week is a sobering example of how equilibrium around an online application can quickly change.

Twitter is a powerful tool used by a huge number of people worldwide (Japan enjoys the greatest usage and the most sophisticated usage model - only the Japanese currently enjoy user groups using 'Twicco', as this video by Seesmic's Loic Lemeur illustrates).

Here's a good overview of Twitter for the uninitiated:

Twitter is an online service that enables you to broadcast short messages to your friends or "followers." It also lets you specify which Twitter users you want to follow so you can read their messages in one place.

Twitter is designed to work on a mobile phone as well as on a computer. All Twitter messages are limited to 140 characters, so each message can be sent as a single SMS alert. You can't say much in 140 characters. That's part of Twitter's charm.

Twitter is useful for close-knit groups (although there also are some fairly large mobs on Twitter). If you follow your friends, and they follow each other, you can quickly communicate group-related items, such as "I'm going to the pub on Fourth Street, come on along."

Since Twitter launched and achieved mass adoption many other 'microsharing' tools have arrived on the scene, but Twitter, which just passed it's billionth 'tweet' has the huge advantage of an existing and growing network of users, the address book effect...

So why was the Twitterank launch an issue?

For those of us in the enterprise space Twitter represents an extremely useful collaboration tool, but like many 2.0 applications IT security in large companies ban this type of communication due to security concerns. The SAP community have an open source Twitter style project called ESME which addresses a lot of these concerns, and there are other vendors attempting to gain traction with similar products to Twitter for business.

Twitter currently has a less than fully formed API to write to and no implementation of Oauth or similar.

From Oauth's site:

If you're storing protected data on your users' behalf, they shouldn't be spreading their passwords around the web to get access to it. Use OAuth to give your users access to their data while protecting their account credentials.

Without these types of built in safeguards, Twitter is pretty porous. This means when Ryo Chijiiwa got bored watching Family Guy in his hotel room and decided to whip up a Twitter app in 5 hours, he unknowingly demonstrated just how easy it could be to harvest usernames and passwords.

This may not seem like a huge thing, but if you're using Twitter to communicate to your cohorts in a business environment and decide to get a vanity number for your Twitter popularity, you may suddenly find someone else sending out tweets in your name, and you're not able to log in anymore because they changed your password.

Ryo's 5 hour thrash to create Twitterank understandably didn't include much in the way of user interface design, guidance or who was offering the service, and the application he was accessing doesn't have much in the way of security.

My strong advice: look very closely at the credibility of a site before sharing your account details, because it would be very embarrassing to have someone broadcasting your secrets from your twittername to your followers...and Twitter, if you're reading this, lots of people want you to continue to succeed, please fix this!