Twitter making it hard to use OSS apps with their API

Twitter, the biggest microblogging tool around, decided to change their policy to applications and it’s making it hard to OSS developers create applications that can be as good as the other applications.

First, let me explain what is the problem they are trying to solve, how they are trying to solve and how this will make the life of OSS developers harder.

How things work today?

Today, applications can use the Basic Auth, which send your username and password to Twitter, which checks and, on success, returns your messages, direct messages, post your update and so on. The flaw in this is that someone could be “listening” to your communication and easily guess your username and password. Or you computer could get hacked, attackers could just retrieve the file with your password. And then, one day, you wake up and see some of your updates saying, for example “Buy viagra” or “I liek cocks”; not good.

Solving the password stolen problem with OAuth

To solve the problem of someone stealing your password, Twitter decided to embrace OAuth for two reasons: First, you store an authorization token on your side and not your password, so if you your computer gets hacked, they still don’t have your password. Second, if one application misbehaves, you can remove its permission to post and you should be all good.

On top of that, for applications that are very very naughty, they can completely revoke your application access. Why? The logic behind it is that spammers don’t really care if their spammy applications are misbehaving, as long as they post spam all the day. It also makes the spammers life harder by forcing them to create accounts manually (which they do already) and applications manually, or a group of fake accounts could suddenly stop working ’cause one single application was revoked.

And where is the problem?

Basically, to avoid someone to listen to your communication and use your authorization token, the application must have an identification and a secret token, which is used to encrypt the authentication token and message signature. So, even if your computer is hacked and their stole your authorization token, they still can’t use it ’cause they don’t have the application secret and, that way, can’t sign the messages as being that application.

So Twitter said to all developers today: “Never share your keys! I”

And here lies the problem for open source developers: We were forced to chose amongst two options:

  • First, we could follow Twitters idea and not share the application keys with the application itself. For a user to be able to use the application, then, they would have to register they application themselves, with another name. For an experienced user, it may be ok, but for users that simply want to read new messages, going all the way of registering an application, knowing if it is a desktop or a browser app, provide some URL and so on it’s too damn complicated. Most users would simply forget about, and think that their friend’s application, which is closed source, is way better.
  • Second, we ignore Twitter’s recommendation and distribute our application with our keys. In this case, we can either suffer from someone taking those keys and spamming Twitter, thus revoking the application secret and letting our users without any access till we provide a new secret; greately reducing our users protection ’cause their authorization tokens can be easily exploited in case their computers get hacked; or, simply, Twitter decides that since we are providing our keys publicly, and that’s bad for the ecosystem (because of the two previous maybes) and revokes the application anyway.

In summary: Either we give applications with a terrible user experience or we have to bite the bullet and give our users an application with incredible reduced security for them (or that, one day, will simply stop working even if the community of users around it behaves nicely, just because someone took the keys and abused the system.)

Twitter came with a solution for open source applications that, basically, mimics the application registration thing: The application is marked by them as open source, so we would have access to another URL, which basically registers a new application with your application as template, gets a new application secret and identification, returns to you and then you keep using that from now on. So, in case the secret is hacked, only one application is compromised and only one application is blocked. But that won’t be available on the day they will kill the basic authorization. So there will be a gap where open source applications and their users will be completely vulnerable to attacks.

Personally, I hate this instance from them. With Mitter, I always aimed for a simple application that would be easy to use and secure, whenever possible. Their current position forces me to chose one in favour of the other.