Twitter detail new permissions change, devs annoyed

Twitter announced this week that they were making various changes to allow users finer control over accounts. Until recently, with other applications such as Twitterific requested access to the account, it could get into the ability to read and post tweets but also into the full history of messages. When the change is implemented today users can tell twitter if they want the third party applications to get access to that history or not.

Yesterday they announced to developers how the new model will work in detail. They said that applications that dont need access to your direct messages wont need to be adjusted, but they said that if they do then they need to update to accommodate the new OAuth System.

Logging into Twitter via a third party application, it doesnt need to store your password. It can use one of two authorisation systems: xAuth where the app actually sends you to Twitter to provide your username and password – Twitter then tells the application whether you are successfully logged in or not.

Many of the web applications use oAuth. You are already on the net, so it sends you off to the Twitter site during the login process. Many non web applications use the xAuth system as it works better, such as iOS programs.

The problems arise when the update happens today and Twitter's deadline of ‘the end of this month' comes into play. Because some applications will be unable to display or send your direct messages. Any user who relies on direct messages will get an error message instead of a successful posting.

John Gruber, in his usual passionate style hasn't been too pleased with the new system. “When you open a native app — Mac, Windows, iOS, Android, WebOS — you don’t expect to be forwarded out of the app and into your web browser. Developers can alleviate some of the context switching by using an embedded web view inside their native app for the OAuth authentication handshake, but at that point, why not just use xAuth and simply allow the user to enter their username and password in a native dialog box? So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth — but there’s a huge decrease in usability, simplicity, and clarity to the user.

And OAuth is even worse for setting up multiple accounts in a native client (and good multiple account support is surely one of the leading reasons to use a native Twitter client instead of the twitter.com web site). Because then, not only do you need to go through the cumbersome OAuth login process for each additional account, but you must first sign out of the Twitter account you’re already signed into in the web browser. The twitter.com web interface is inherently single-account. To use a different Twitter account in the same web browser, you have to first sign out, then sign back in using the other account. With xAuth, to add an additional account you merely enter another username and password. With OAuth, you have to start by signing out of whatever account you previously signed into. You only have to do this when first creating each new account in the client app — the app can save the OAuth credentials for multiple accounts — but it’s still far more complicated and annoying than simply entering a username and password.”

KitGuru says: a move for the better?

Become a Patron!