Twitter, OAuth, and Client Restrictions

Over the last 24 or so hours theres been a lot of commentary on Twitter reitterating their policy that developers should not implement full twitter clients. This should have come as a suprise to no one, but seems to have kicked off a lot of ire in the dev community, nearly all of it misplaced, Yes, Twitter gained a lot in its early days from having a warm relationship with developers, and yes its a shame that they’re moving away from that stance, but at the same time they’ve made some very nice contributions back to the OSS community, Bootstrap is a godsend for people like me who haven’t invested the time to design things well.

What is most interesting to me is how few people seem to have seen this coming. The outcome was obvious with their rollout of OAuth as the only authentication mechanism. What OAuth gives end users and operators in terms of securing their passwords from unauthorized 3rd party use, its takes from users in their choice of access methods. Oauth is essentially DRM for networks, allowing operators to choose which clients they allow to connect to their networks, and giving them the power to revoke that permission when neccessary. Whatever your views on DRM, that’s not too bad for OAuths intended purpose of server to server authentication, but fails as miserably as most restriction services when pushed to end user systems. This does little for securing their platform. At best it keeps honest developers honest. Those interesting in doing things without authorization will continue to. Gaining access to the keys, and coding a client to use them for unapproved purposes is fairly trivial for anyone with an intermediate level talent in reversing and coding. And I am likely being generous with calling it intermediate.

Twitter needs no justification, they built the pool and they’re entitled to construct whatever fence around it that best suites their interests, and to their credit I have not seen them use security as a justification for their API changes/clarifications, but there are certainly some outside of it doing so. Besides, the dev community could really do with one less thing to blame on security.