Wednesday Twitter announced they would be changing the way 3rd party users grant permissions. Twitter stated “users and developers have requested greater granularity for
Another hit for developers?
Unfortunately, this is another hit for 3rd party developers, particularly mobile. In laymen’s terms what Twitter is asking mobile developers to do is move over from an authentication system that just required a username and password (XAuth, and the password was never given to the 3rd party developers to store) to a more convoluted system that requires a pin to be entered, and and an authorization screen to be accepted.
A developer on the Twitter Google Group Forum may have put it best:
Thanks for your feedback. I think the following paragraph can’t be
Question: Why will you not grandfather existing applications into DM access?
Matt Harris’ Answer: “Grandfathering all existing read/write tokens assumes they all wanted
access to DMs. The feedback we’ve had from users and developers tells
us otherwise. We want to give users the opportunity to make an informed choice.”
I can assure you that if I am asking any of my 100.000′s users that
they would disagree with that statement. They all explicitly want to
access DMs in my Symbian based Twitter client. They actually EXPECT to
have access to direct messages.
A Twitter client without access to Direct Messages is not a Twitter
client. Wouldn’t you agree?
I would urge you to rethink this decision – or let us know in all
honesty why you were imposing this bad UX on third party clients only.
If there was a proper way of doing the Web OAuth flow on the Symbian
platform, things would be a bit different (although not much.)
But now, the best option for me is to setup an intermediate server for
the OAuth flow – effectively giving me access to the users’ OAuth
credentials. Something, that I didn’t have access to before.
Something, that I didn’t WANT to have access to from the beginning.
This doesn’t seem like an improvement of privacy for my users at
Please, please find a better solution for this. There are many options
that won’t break third party clients – clients which cannot go through
the web Oauth flow, clients that have a wonderful user base
contributing to the Twitter “experience” with a lot of great Tweets.
Ole ( @janole / @gravityapp )”
Mobile apps may not be able to do it in time:
Especially iphone / ipad applications whose users rely on the DM feature to function, it could take 4 to 6 weeks to get approval for the changes. This means that a lot of mobile apps may have a useful feed displaying an error message. Originally Twitter announced an “end of the month” deadline for the change, but late last night changed it to be June 14th.
Twitter’s own apps are NOT adhering to the same level of privacy:
Matt Harris of Twitter’s API department says in response to “ Will Twitter’s own applications also go through the OAuth web flow?”
“We’re taking this step to give more clarity and control to users about
the access a third-party application has to their account. The way
users interact with Twitter’s clients is not expected to change.”
The wrong message
The public is getting the wrong idea. A recent Mashable article framed this as a very positive move for Twitter, and one look at the comments immediately shows how people simply aren’t understanding the motivation. Comments like this do nothing for the image of developers:
” I had no idea they could do this to begin with. This is pretty eye-opening. I feel violated and I don’t even know if third party apps have actually accessed my DMs. lol”
Third party apps are not in the business of trying to steal your information, least of all DMs which is arguably the most spammy part of the Twitter experience. Instead, developers are trying to streamline the UX so that people set themselves up easily and quickly. Who wants to do 3 steps when it can be done in one?
Have your say
Are you a Twitter user who is really happy about this recent change, or are you a developer coping with the hit? Let your thoughts be known by commenting!