Twitter Security Smackdown

May 19th, 2011

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.

8 Responses to “Twitter Security Smackdown”

  1. curtismchale Says:

    I’ve certainly been less and less impressed with how Twitter has been treating their developers. Really the developers helped (in a huge way) make Twitter what it is. If they hadn’t come along and provided native interfaces for Twitter I doubt that Twitter would have the use it does.

    This also brings to light the fact that it’s a bad idea to rely on another service as your business model since they can change the terms and screw you with no recourse on your part.

    I for one just refuse to use the Twitter official apps. They’re still not even the best ones out there, in some cases they’re missing major features that others have had for a long time. Twitter needs to get it’s head out of it’s ass.

  2. Denis Hennessy Says:

    I don’t think it’s evil apps that Twitter are trying to combat (because, as you say, they can instantly disable them). It’s that some app using xAuth don’t properly convey to the user what rights the app is requesting. These ‘naughty’ apps are a source of nuisance to users (and, I guess, Twitter).

    Also, OAuth doesn’t mandate a web browser. It’s possible that Twitter could release an OAuth library that would invoke the native Twitter app for authorization if it were present on the device, and fall back to the browser if it were not. This would make the user experience a little better…

    Having said all that, I think the sensible route would have been for them to dramatically reduce the number of xAuth approvals (and limit them to full-blown clients like twitterific) and let all the ‘add-on’ apps use OAuth.

  3. Hamish Says:

    @Denis Hennessy: “It”™s that some app using xAuth don”™t properly convey to the user what rights the app is requesting. These “˜naughty”™ apps are a source of nuisance to users (and, I guess, Twitter).”

    xAuth allows Twitter to revoke access for those apps. What was the problem again?

  4. Denis Hennessy Says:

    @Hamish Many of the social media apps allow a user to log in with their Twitter account. With xAuth, they’re actually getting permission to do much more than authenticate the user. I’m guessing that Twitter are trying to crack down on this.

  5. zwei Says:

    Twitter could outright kill every third-party client and I’d have no qualms about going back to

    The Service > The Client

    Yes, I feel bad for the devs, and I absolutely love Tweetbot on my iPod Touch, but the benefit I get out of twitter outweighs the right to client choice. About the only thing that would kill twitter for me is if they made me use it in a web browser. It’s just another lesson learned about the risks of building a business on top of someone else’s.

  6. Mark Bernstein Says:

    I think the upshot of this move is not simply that we’ll not have any real third-party Twitter clients — there will still be a few abandoned clients, of course, and some school projects — but that no other Web application will ever again have this sort of vibrant development community.

  7. grobbins Says:

    The goal of using OAuth in native apps is not to protect against the malice of those apps. Rather, it accomplishes these things:

    – It avoids the need and incentive for apps to ever hold the user’s password locally on the device, and instead lets apps store just a limited-scope, revocable token.

    – It avoids the need for client apps to implement support for all the present or future security features needed by the service (perhaps with captchas, second-factor authentication such as by mobile phone, and so on.)

    Since Twitter can update their clients whenever they update their authentication, they don’t need to worry about security changes breaking their clients the way they’d need to worry about changes breaking third-party software.

    It’s the same reason that Apple’s own applications need not follow the same rules as third-party apps: Apple can and does update their own apps as system changes break them. Third-party developers don’t like being asked to follow stricter rules, but the reasons for it are still legitimate, as they make it less likely that the externally-developed apps will break.

  8. Daniel Jalkut Says:

    Thanks for the points, grobbins. I hadn’t considered the advantage of being able to add additional security options during the interactive OAuth phase. That is certainly an undeniable perk.

Comments are Closed.

Follow the Conversation

Stay up-to-date by subscribing to the Comments RSS Feed for this entry.