Devil’s advocate on Twitter’s OAuth change | Hacker News Reader

Devil’s advocate on Twitter’s OAuth change

marco.org

44 pointsapievangelist25 comments

I'm annoyed by the change. I was the DevNestSF meetup last week though at TwitterHQ and they said they didn't mention that were going towards doing this and instead praised the developer community for making them what they are.

When they surprised us with this, they claimed it was because most users didn't realize that they gave up that level of access to their account. This change allows them too, but at the cost of bad UX for mobile and native apps, while breaking all existing apps so far.

They moved the deadline back 2 weeks. That gives you less than 4 weeks to make the changes and if it's iOS, you have to get the app approved by Apple which takes 1 to 3 weeks (accounting for one possible reject and Apple being slow).

Then you have to hope that all your users upgrade right away and when they do upgrade they have to reauth everything again with the crappy experience.

These UX issues were what drove the design of xAuth in the first place durning the basic auth switch. xAuth was manually approved and was for clients and not for services that had a web side. These clients are more likely to need DM than most simple web app tools, but xAuth retroactively and going forward doesn't get DMs.

This will break TweetBot, older Seesmic clients, Twitalator, Twitterific, TweetDeck, TwitDroid, etc. Even the official Twitter client (formally Tweetie) would break because it uses xAuth but I'm sure they are hard coding exceptions for different clients.

The official apps get an exemption (some would say unfairly) from the new permissions model.

How is it unfair? Read the post again.

This is to clarify permissions users are giving third parties. With the official client, there is no third party.

> When they surprised us with this, they claimed it was because most users didn't realize that they gave up that level of access to their account.

An interesting contention on their part, considering Twitter clients don't exactly hide the fact that they handle direct messages within the apps.

> while breaking all existing apps so far

Thats seems like the point.

Sure, it's Twitter's service to do with as they wish. I hope they have a nice time with it. Over the last few months, they've done a great job of convincing me that I don't need Twitter as a user and that I should absolutely avoid them as a developer.

I made a plugin for wordpress based on the twitter API. Sure, there was a time when an abrupt change in 2010 broke my code. I got introduced to JSON when I fixed it, so I guess I'm OK with the experience now that it is behind me. This DM change doesn't affect me.

Yes, Twitter is interested in keeping casual API developers such as yourself. It's the people who wish to make full Twitter clients or base businesses upon their API who are being made to feel unwelcome.

I followed till I came to "Twitter isn't ours".

I don't know if Twitter's particular changes here are desirable or not. But if company is also providing a messaging utility that millions of people contribute content to and that other provide enhancements to, then "we" sure as heck should criticizing what it is does, deciding whether it is worth "our" while and so forth. If "we" don't, "we" will become serfs to those convenient information providers.

Certainly, "twitter isn't ours" so we can't sue them or immediately fire whoever made this decision. Our options include accept-whatever-without-a-beep(or-a-tweet), criticize and suck-it-up as well as criticize-and-abandon. And latter options seem reasonable.

Are you paying Twitter money to use it? No? Then they are perfectly justified in ignoring you.

Remember this quote: "If you are not the customer, you are the product."?

Any money Twitter makes is a result of Twitter having users. It doesn't matter if they're selling member data or charging for the service: they need people to use the service, one way or the other. If they wish to have me in their inventory to 'sell', they'd better provide a service I wish to use. Yes, free members are customers.

What happens to businesses who ignore their customer base? They lose them. I hope you don't operate your own business with an attitude such as that.

no, free members are product, just like a farmer and a dairy cow, they have to do enough to keep you happy, but don't think for a minute you are their customer.

I don't care if I'm their customer. My point is that if they displease me, I'm leaving, and that does have an effect, same as if I was a customer.

If you want to look at it as they're losing inventory, fine. There's no difference.

Personally, I don't buy the argument that this change is because Twitter wants users to use the official twitter clients.

http://en.wikipedia.org/wiki/Hanlons_razor

Twitter is retroactively changing the xAuth rules in a way that will break every existing install of a native client (except the official one), and make every native client (except the official one) going forward harder to use.

Stupidity would be breaking their own clients, too. Stupidity doesn't seem to adequately explain their commitment to going forward with this change, so we turn to Occam's Razor. The simplest apparent explanation for the observed behavior is that they want to discourage the use of third-party clients.

Maybe, but if I were twitter and wanted to discourage 3rd-party clients, changing authentication methods to one that is harder to use is a really roundabout way of accomplishing that goal.

The comparison is a bit flawed. It would be rather odd to say that Twitter is trying to shift usage of their service to official clients out of 'malice'. Clearly, they feel it's a business strategy that is in their best interest. That could be due to stupidity, but I don't think they're out to specifically cause trouble for developers. A reasonable guess is that they're working on restructuring the business to make it easier to make revenue, and are displaying apathy and a lack of gratitude towards developers.

7 steps* and a few hours to upload to the market.

in between you have 11 days to test.

* http://donpark.org/blog/2009/01/24/android-client-side-oauth

Those 11 days also need to include app store approval for iOS and getting all of your users to upgrade to the latest version.

it was a tongue-in-cheek statement about how nicer it is for the developer to have control of the publishing methods as in the android market opposed to iStore.

This time it was just a twitter-dick-move©, but tomorrow it could be a security vulnerability being exploited massively in the wild and you will not be able to provide a timely response.

i'm not saying that the android model is better. i'm all for no control. i'd ditch both if i could.

I went back into history, to find my blog post about how to tweet from Python (http://corbinsimpson.com/entry/the-bird-is-the-word) and confirmed that Twitter started rolling out OAuth in July 2010. That means that they have given xAuth apps the better part of a year to transition, when the original plan was to give them only a month or so.

My sympathy is limited towards Twitter app developers -- you were warned a while ago, you've had plenty of time to figure out the new system, and it's really not that painful.

I think you are confused. Twitter had basic auth and they gave us transition period.

xAuth is OAuth but doesn't require a web based interaction to authorize. With xAuth, apps ask for a username and pass but get a token and only store the token (instead of storing the username and pass like with basic auth). This was created to help with UX of non-webapps like mobile and desktop. The first release of xAuth was Seesmic Look which was after basic auth was in the count to shutdown. xAuth is only given to apps that are approved by Twitter that prove that they are not a web service and need the improved UX.

The issue is that these apps are usually clients that desktop and mobile and probably need DM access, but xAuth clients can't ask for DM access (they are only allowing that access to clients that web auth).

Twitter has actively advocated using xAuth in mobile apps and has never said, until yesterday, that they prefer developers using OAuth. Twitter themselves set the precedent with all of their official apps using xAuth.

oAuth replaced Basic Authentication, not xAuth. xAuth was specifically built to make the oAuth experience nicer for native apps.

xAuth is now having functionality removed with very little warning.

The order of operations was:

* Twitter supported basic auth only.

* Twitter forced all new apps, including native apps, to use OAuth. Existing basic auth apps were allowed to continue working without modification.

* Twitter rolled out xAuth specifically to allow native app developers to provide non-shitty user experiences.

* Twitter finally forced all apps off of basic auth. I don't think there's a single native app that chose the web-based OAuth workflow over xAuth.

They were at one point in a position to move forward with only the OAuth web flow, but they chose to roll out xAuth after they were requiring all new apps to use the OAuth web flow.

Now they're taking away privileges from xAuth apps without providing a solution to the problem xAuth was created to solve in the first place. And they're giving developers 2 weeks to figure out what to do and do it.

It's not surprising that developers are upset.

Reply on news.ycombinator.com