Going Rogue: How Twitter app developers can circumvent Twitter’s restrictions (and why they probably shouldn’t)

[tweet https://twitter.com/falcon_android/status/305255115651182592]

Expect to see a lot more tweets like the one above in the near future as popular Twitter clients across a variety of platforms reach the 100,000 API token limit imposed by Twitter, forcing them to stop accepting new users.

If you’re not familiar with the idea of API tokens and Twitter’s arbitrarily-set limit, I’ll attempt to explain this very quickly. Essentially, every user that logs into any given Twitter app requires a special string of text (a token) in order to use that app. Due to recent changes, Twitter only allows apps to hand out 100,000 of these tokens. What that means is that 100,000 people are allowed to login to any given Twitter app ever. Now, it’s possible for users to revoke their token for an app if they don’t use that app anymore, but the majority of users won’t do that. If the token is revoked, someone else can take that user’s spot in the 100,000. If not, that user will be counted as one of those 100,000 tokens forever, even if they aren’t using the app. So if you buy a Twitter app, login, decide it sucks, then delete it, you have taken up one of those limited slots and wasted it.

When a Twitter app runs out of tokens, people will no longer be able to login through it. Twitter simply blocks all new logins. App developers can request more tokens from Twitter, but Twitter is not obligated to comply.

[tweet https://twitter.com/falcon_android/status/306340529405300736]

Because of this, developers are forced to charge more money to ensure that only truly dedicated users will buy their apps, and that people who simply buy a cheap app and then stop using it won’t waste a token.

But what if there was a way around that limit? As it turns out, there kind of is, and it’s kind of a bad idea.

This will probably be a bit more technical than some people are comfortable with, but I’m going to try to explain this like you’re five.

Several versions ago, a hidden settings panel was discovered in Tweetbot that allowed the user to add any set of custom API keys he wanted. Basically that let you change the “via” tag on your tweets to say that you had tweeted from anything you wanted. There was a side effect of this, though. Those keys are what determines what “app” you’re using. You aren’t supposed to be able to change them in a normal app. That was just a hidden development feature that the creators used to mask beta versions of the app.

But here’s the thing: when you change those tokens, Twitter no longer sees you as using “Tweetbot for iPhone.” Instead, it sees you as using “Mike Beasley’s iPhone” or whatever you setup. That means you could revoke your Tweetbot token and still continue using Tweetbot, because both Twitter and Tweetbot thought you were using a different app.

What that means is you’re no longer using one of Tweetbot’s limited number of tokens. You could now login 100,000 users to “Mike Beasley’s iPhone” or whatever custom app name you created. Twitter sees this as a whole separate app.

So think about this: what if an existing developer went rogue and came out with an app that asked you for your own keys right at the beginning. Instead of using its own keys, it used yours. Your keys have a 100,000 user limit, but you’re likely the only person that would be using them.

Imagine what that would do. Twitter wouldn’t be able to stop this app, because there’s nothing on their end to shut down. They can’t revoke the keys that power the app because there are no keys. The users bring their own. It would be foolish and impossible for Twitter to try to track down each set of custom keys and revoke them all manually, and there’s no way to detect which ones are being used in this app and revoke them automatically.

Twitter would be completely helpless. For a while, at least.

I’ve seen a few people suggesting this on Twitter, and I have to say, it’s a pretty good idea if you don’t stop and think about what it could mean for developers.

Now let me explain why this is a terrible idea:

If Twitter saw this kind of thing happening, all they would have to do is update their API to require a different kind of key, then closely monitor the usage of each pair of keys. Each key would have to be approved by them, and considering their recent Display Guideline changes, they might even want screenshots of the app to make sure it fits their guidelines before issuing the developer a key.

This would be a very bad thing for the Twitter developer community. If you think they have it bad now, imagine if they had to go through something similar to the App Store review process on Twitter’s end just to get API access.

Twitter does not care about developers. I believe they’d sooner shut down third-party access to the API than go through the trouble of setting up something like that. That would be incredibly bad news for everyone currently using, building, or selling a Twitter client on any platform.

While “going rogue” may seem like a good way to flip the bird at Twitter (PUN FULLY INTENDED, THANK YOU), it can only end in the death of the entire Twitter client ecosystem.