Recently an Ars Technica article stirred the discussion around Twitter’s implementation of OAuth, but what was not part of that discussion is a larger, lingering security issue – Twitter’s permission system for applications.
Currently Twitter application developers are given 2 choices when registering their apps – they can either request “read-only access” or “read & write” access. For Twitter “read & write” means being able to do anything through the API on a user’s behalf. These course-grained levels push most apps to choose “read & write”, in case they want to tweet on the user’s behalf, or make it simple to follow a Twitter account. Anecdotally, of the 130 apps & Twitter-integrated websites I’ve approved91% have full read & write access to my Twitter account, with the other 9% having read-only access. (I probably use more apps than most, but hey, it’s my job.)
Twitter’s overly-broad permission structure amplifies the concern around OAuth token security because of what those tokens allow apps to do. If Twitter is to be the “message bus” for all types of real-time information, it has to secure it’s trustworthiness for the benefit of users & developers.
Problems with Twitter’s permissions
Apps that have this level of access to Twitter users’ account could be a problem in a number of ways from annoying to severe:
Pushy Promotion – These are apps that auto-tweet without permission, such as the recent Twifficiency affair. This is obnoxious and definitely against the API Terms but causing little damage and relatively simple to stop since it is obvious what app is misbehaving.
Direct Message Privacy – Do you consider your DMs private? People increasingly use DMs like short emails or IMs and assume it is a private channel between two people. In reality any app you have granted access can read all of your DMs. As an example, if you can get Michael Arrington (@arrington) to try your site and use Twitter OAuth you can now read all of his DMs. That might be tempting to an unethical few. And the challenge to Mr Arrington would be to even know that they were read without his permission. Twitter would have the logs of the API calls, but how would he know it happened? Or which app to revoke if he suspected it?
For as much flak as Facebook has taken for its privacy settings, they are ahead of Twitter in explaining what specific abilities an app will have during approval. While this is more complicated than Twitter’s “write access” request, it helps toreduce user surprise when an app does something later on their behalf.
Spammers & Script Kiddies – There is always the chance of malicious behavior in a large network like Twitter. If an app can get your token with full-write access they could be evil in a number of ways:
Unfollow all your friends – Or follow all sorts of spam or embarrassing accounts.
Send out DM spam as you – Your friends would likely click on a shortened link you DM them.
Delete your tweets – While there are services like Backupify to backup tweets, someone could attempt to delete your tweet history.
Preserving Trust & Twitter Developers
Beyond these potential problems for users is that developers don’t really want more permission than they need. In the same vein as previously feeling uncomfortable storing user’s passwords in cleartext, as a developer I don’t want to be able to read their DMs or accidentally unfollow their friends. As more & more websites use Twitter for authentication this issue will become more pronounced and important to preserve user trust when approving apps. Thankfully to date there have been apparently few issues like those described above, but as the ecosystem grows a few bad actors could negatively impact user’s trusting apps.
There was a tweet from a recent Twitter Developer meetup in Toyko that fine-grained permissions may not planned for the near term. There are definitely real challenges to layering it onto a large app ecosystem, and UX challenges to present more fine-grained levels to users. But the effort to solving these challenges would be a win for the app ecosystem to ensure people can continue trust apps to do their job, and nothing more.
Originally published Jul 21, 2011 2:05:00 PM, updated October 20 2016