Exactly one year ago, I wrote a little post about Twitter’s OAuth experience, entitled Checkboxes, bitches. One thing led to another, and now I work at Twitter. So that went well.

Anyway, having been working in Twitter’s Platform Team for nine months, and taking on most of the front end work for the redesign of those very same authorization screens, I thought I’d revisit the original bullet points from that post:

• When you create an app, it should declare which permissions it actually requires to function (disabled, ticked checkbox) and which it desires by default (ticked checkbox.)
• Everything not required is optional/user definable.

We haven’t done this exactly. I still think it’s a good idea, but quite hard to retrofit in a meaningful way onto an existing API with a million registered applications, especially the user-time configuration aspect, which could result in an old app expecting to be able to do something, the user denying it, and the app failing gracelessly. I think it’s entirely reasonable that an API provider expect applications to be programmed robustly, and really anything built on a web service should be expecting failure in any case, but you do need to set that playing field, rather than redrawing the whole thing mid game. As was demonstrated by the big change we made to Direct Message access, it’s a bit of a shitter for everybody involved when you have to do that.

So no checkboxes, but big things did happen: Firstly, direct messages became a separate access scope. No-longer can all apps access DMs, even when all they needed to do was hook you up with the people you follow. Alongside that though, there’s now the ability for an application to upgrade tokens: So, once upon a time if you authorized your app with a Read token, you were stuck with that forever, or until the user explicitly revoked your app. What is now the case is that you can pass an x_auth_access_type param when generating a request token, and use that to upgrade a user’s access type to your app on subsequent authorizations. So, you can make an app, request read-only access initially, and then ask the user to add read-write access at a later time, when they try to perform an action that requires write access.

It’s not user control over granularity, it’s application control over granularity. Not the same, but not bad. And we have plenty of anecdotal evidence that it’s in apps best interests to do this, as users are more likely auth apps that don’t ask for write permission. I’m hoping to get actual numbers to back that one up at some point.

• Permission to post a tweet is separate from other, private profile writing operations, since it’s so socially destructive.

We changed DMs, and did it in such a way that we had to change all the permissions that existing applications had. That was annoying, but necessary to ensure that user’s opted in to granting sensitive DM access. Adding other levels of granularity though—such as this one for posting access—wouldn’t require the same kind of reset though, and existing apps could be opted into it by default. I’d definitely like to make this happen at some point, especially now that Web Intents are proving so popular with app makers who only need a simple way to post a Tweet, rather than having to create their own mimicked UI.

• I think this also makes the permissions/capabilities copy clearer. Bonus.

I’m still really, really happy with the redesign. We revised the language a couple of times, to the point where I no-longer receive comments about it coming on too strong, so I hope we’ve struck a good balance, and users are now more aware of what’s what.

---

It’s fair to say that really we built something quite different to my little post, but a lot of the principals are in there. I’m pleased with the progress.