Twitter on Tuesday announced via its blog various changes aimed at allowing users finer-grained control over their accounts. To date, when another application (such as TweetBot, Twitterrific, or Echofon) or Web service (such as Favstar) requested access to your Twitter account, it was an all or nothing deal: Granting a third-party access to your Twitter account meant giving it not only the ability to read and post tweets on your behalf, but also full access to your direct message history. After Twitter implements the change it announced today, however, users will get the ability to specify whether they want to allow third-party apps to access that direct message history.
On Wednesday, the company clarified just how the new permission model will work. In an announcement to developers, Twitter declared that apps that don’t need access to your direct messages won’t need to change a thing. Apps that do depend upon offering access to those direct messages—in effect, any full-featured Twitter client——will need to update themselves to leverage Twitter’s OAuth system.
A quick background: When you log into Twitter via a third-party app or service, that service needn’t know or store your password. It can use one of two authorization mechanisms: xAuth, wherein the app gets your login credentials from you and sends them off to Twitter for verification, and oAuth, where the app actually sends you to Twitter to provide your username and password, and Twitter tells the app whether you’ve successfully logged in or not.
Most Web apps historically rely on oAuth; you’re already using the Web, so sending you off to Twitter’s site for a moment during the login process flows naturally. Most non-Web third-party apps—iOS apps and Mac apps, for example—prefer to go the xAuth route, which allows for a more seamless experience.
So what does this all mean? It means that unless Twitterrific and the rest issue updates to their apps by Twitter’s deadline of “the end of this month,” those apps will soon be unable to display or send your direct messages. That would obviously leave such third-party apps rather crippled; any user who relies on direct messages will instead be greeted by some unspecified error and/or blank direct messages list.
Thus, it’s rather likely that we’ll see a slew of third-party Twitter app updates in the next couple weeks. But in order for those apps to embrace Twitter’s new permission model, they’ll need to embrace oAuth. If you use third-party desktop or iOS apps that leverage Facebook’s login credentialing system, you already have a sense of what this will look like.
When you log in to Facebook via a third party app, that app must briefly display an inline Web view of the Facebook login screen. If it’s your first time logging in with that app, you’re then asked to approve the specific Facebook permissions that app is requesting.
Of course, as John Gruber points out (warning: salty language), if you use Twitter with multiple accounts, the oAuth process will make the initial setup process distinctly more frustrating: After using oAuth to log in with your first account via the Web, you’ll need to log out of the Twitter Website and log back in with the next account to connect it via oAuth. And you’ll repeat that log out, log in dance for each account you want to set up.
Twitter apps formerly accustomed to relying on the more native-feeling xAuth experience will now require a similar in-app oAuth Web view, either as their sole approach to logging in, or only when users first attempt to access direct messaging after previously logging in via xAuth.
There are a few Twitter apps that will be excluded from Twitter’s new oAuth requirement: Twitter’s official clients across all platforms. Twitter developer Ryan Sarver confirmed— via a tweet, naturally—that the service’s own apps aren’t subject to rules for third-party developers.
Various third-party developers on Twitter complained—to each other, to Sarver, and to the public at large—about this authorization change. Some developers are worried that the Twitter experience will now necessarily feel lousier in their apps when it comes time to log in, and consider Twitter’s self-exclusion from the oAuth requirement unfair.
Back in March, Twitter famously (and controversially) clamped down third-party apps. In kicking off that uproar, Sarver wrote:
…Developers ask us if they should build client apps that mimic or reproduce the mainstream Twitter consumer client experience. The answer is no.
That stance has already cost Mac users much further development of at least one popular Twitter client. On May 16—prior to Twitter’s oAuth announcement—the developer of Kiwi published a melancholy blog post announcing that he’s stopped further development on Kiwi (save for bug fixes), because of his perception that “3rd party clients are not wanted” by Twitter. “Twitter,” he wrote, “has been slowly chipping away at the fun” of making such clients. Today—again, in tweet form—he wrote:
So glad I threw in the towel on Kiwi when I did. Wish I had given up on Twitter sooner.
Gedeon Maheux, the co-founder of the Iconfactory, which is the company behind Twitterrific, posted a tweet of his own:
Very very soon you will be able to interact with Twitter in just one way. Their way. #writingisonthewall
In its short history, when Twitter has made controversial announcements, it’s tended to stick by them. The company never recanted on “The answer is no,” and there’s little reason to believe the company will backpedal on this oAuth decision, either. Whether the developers behind popular third-party Twitter apps will make the necessary changes to remain fully compatibile with the service remains to be seen. And if they do make this change, there’s no certainty that they’ll be willing to make further updates when Twitter’s third-party requirements are updated next.