The so-called Twitter follower “bug”

For those of you who don’t use Twitter, a follower is another user who consents to receiving text messages of your latest activities.  On May 5, 2010, on an obscure website in Turkey,  someone described a method that allows you to make any Twitter user, of your choosing and without their consent, into one of your followers.

Accept @DalaiLama

The first person to be followed by the Dalai Lama on Twitter.

On the morning of May 10, 2010 at about 10 AM CDT… @korhankurt, Korhan Kurt, made history as the first and only person on Earth to be followed by @dalailama, the Dalai Lama on Twitter.  Within the hour, via @hasanbasusta (Hassan Basusta), WebRazzi, and TechCrunch; Twitter began going into “fail whale mode,” as untold numbers of people took advantage of the “bug” that allowed one user to “force” another user into becoming one of their followers.

Realizing what was happening, Twitter staff were able to remedy the problem within three hours.  But was this really a “bug?”  I think not.  To take advantage of this particular “bug,” all one had to do was type the command “accept” followed by a user name; into Twitter’s web interface.  This so-called “bug” conforms to the format for Official Twitter Commands.

Come to think of it, why does Twitter call them “official” anyway?!?  Does it mean there is a list of “unofficial” commands?  This is no “bug” folks –  It is a backdoor, perhaps leftover from Twitter’s testing phase; that was long forgotten.

When computer programs are written, it is normal for programmers to incorporate test features, that allow them to exercise various parts of the computer program, before it is finished.  But unless these test features are properly documented, knowledge of these features becomes lost; either because of staff turnover, bad documentation, or deliberate concealment.  And when they are rediscovered by end-users or adversaries, these innocuous test features suddenly morph into backdoors.

Managers should learn from this, and ensure that design documentation exists for all software projects.  The existence of all test features must be properly identified; in order to facilitate their removal from the finished product.  If you have a project that can benefit from a detailed design and documentation review, please contact The Assurer for a consultation.

Spread the word!