Today Twitter announced a few distinct policy changes for clients of their API, all wrapped up under the banner of improved security permissions for end-users. The best response I’ve seen yet is from John Gruber, who smells something funny in the deli. I tend to agree. The announcements today comprise some useful security enhancements, but the security gains from some of the decisions that were announced are not so great that they offset the serious disadvantage they impose on 3rd party developers, particular developers of native mobile and desktop apps.

Let me break the announcements today into three policy change assertions, and how I react to them.

1. Access to Twitter direct messages will require a new level of user-granted permission. This is a great thing! I recently tweeted that exactly something like this was necessary, because I’ve grown tired of giving every damn service that I wish to connect to Twitter, access to all my confidential direct messages. The new permission allows developers of client apps to state their desired permissions, and those permissions will be listed prominently on your list of approved applications.

   Verdict: Kudos, Twitter.

2. Developers of Twitter clients will be required to use OAuth in order to gain this new permission. In laymen terms, this means client apps can’t log you in with just your username and password. You will need to be redirected to the web. This requirement is ostensibly because Twitter wants to increase the likelihood that end-users will be made aware of exactly which permissions a client application is requesting. Without this requirement, a native application could claim to seek read-only access, but behind the scenes be using your username and password, by way of Twitter’s xAuth solution, to request a higher level of permission than you intended to allow.

   I concede that this requirement is, on the face of it, an added protection for customers who are wary of providing Twitter credentials to an untrusted app. But here’s the catch with native software: you better trust it, because there is no shortage of ways in which it could screw you. It’s running with some degree of elevated permission on your own device. Twitter putting shackles on native app developers in the name of security is laughable. For example, it would be easy for an untrustworthy native app to provide a custom, compromised browser view that purports to drive a user through the Twitter OAuth permission flow with a given permission, but is actually requesting a different level of permission in a second, undisplayed web flow.

   This is not to say that we shouldn’t bother reining in native software that may be flawed or whose permission we may want to revoke. This is what is so clever about the xAuth workflow, the compromise that allows native apps to authenticate as if by way of an OAuth flow, but using a user’s username and password to facilitate the process. If an end-user or Twitter itself loses confidence in an xAuth based application, they can still revoke access to the application in the same way they would for any other OAuth managed client.

   Verdict: Nice try, but if you don’t trust your native software, Twitter can’t do much to keep you from getting screwed.

3. These requirements apply unilaterally to all native clients. Except Twitter’s. I grant you, it makes sense for a company to exempt itself from security restrictions that are imposed to prevent “bad guys” from taking control of a user’s credentials and doing damage to the user or to Twitter itself. But this story is complicated by the fact that Twitter entered a competitive market of native clients of its own system, where for years it was not a player, and then proceeded to adopt increasingly developer-hostile attitudes. In particular towards developers of software that aims to fill that coveted role of a “general purpose read/write Twitter client.”

   Is it illegal to do what Twitter has done? Absolutely not, nor should it be. But in my opinion these 3rd party developers were a valuable asset that was pivotal in building passion for Twitter in the earliest years of its existence. Many of the features that we take for granted in Twitter itself were prototyped in 3rd party native applications. Hell, even Twitter’s own native Mac app was itself a 3rd party application (Tweetie) until not too long ago.

   Twitter’s attitude towards these developers seems to be: thanks for all the help, but we’re done with you. The fact that Twitter is willing to “whitelist” their own apps further suggests that this may not be a pure security play. Only legitimate developers of trustworthy apps would be interested in seeking an API key to connect to Twitter. If your aim is to write malevolent software that abuses Twitter or its users, you should be content to take an app like Twitter’s own Mac client, extract the portions that communicate “securely” with Twitter, and build your own app that only the savviest user will notice is actually posting to Twitter as “Twitter for Mac.”

   Twitter’s willingness to exempt any apps from the OAuth procedure is a concession that they don’t view xAuth authentication as inherently insecure. But they want to limit which API keys get the privilege of continuing to use it. So, expand that list of API keys. At the very least, add long-time supporters such as Iconfactory’s Twitterrific. Better? Provide some kind of approval process through which any qualified developer can seek first-class status. Best of all? Stick to what OAuth and xAuth are best for: providing the power to revoke access for bad actors after bad intentions are discovered. Forcing applications through OAuth is not going to prevent offensive, buggy, or intentionally malevolent code from being authorized by users, but it is going to degrade the user experience for all native clients except, oh, how about that? Twitter’s own.

   Verdict: Dick move, Twitter.

This entry was posted to Rant, Technology, Web. Comments are closed. Thanks for reading!