How Private Are Your Private Messages?

Earlier this week Twitter announced on their blog and to the developer community a change to their API permissions system to give users greater control over what applications can access and do with each user’s account. This seemingly minor change has caused big ripples in the development community. Basically, every Twitter application that needs to access a user’s private messages has to be updated and partially re-written to account for these changes. The deadline for completion is now June 14, less than thirty days from the date of the announcement. However, initially developers were only given until the end of May to complete the changes to their applications. After the initial complaints from the developer community, Twitter relented and extended the deadline another two weeks. The current Twitter permissions system allows only read access or read and write access. Read access simply means an app can access the account to read and search tweets, followers/friends, lists and private messages but not allowed to post or change anything on a user’s account. Read and write access allows an application to do all of that plus post tweets and add or remove followers, friends, create and edit lists and send private messages. In most cases this hasn’t caused user problems with private messages, but many users didn’t realize this and it wasn’t explicitly stated during the Twitter authorization process. Twitter is now adding a third level of permission called read, write, and private message access. This level of access will now be the only level allowed to even read a user’s private messages, making private messages a little more private. To see what level of access an application has to your account check out your applications setting page. The changes, while inconvenient for developers are a step in the right direction for the overall security of the Twitter community at large. Many developer’s are angered that their applications cannot be “grandfathered” so that the changes will only affect new applications. Twitter’s Matt Harris responded to the group: 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. Basic computer and network security theory dictates that default permissions should be the most secure state or configuration and that loosening any permissions should require a user to explicitly allow or request the less secure state. The recent revamping of Facebook’s permissions system was completely contrary to these protocols. Yes, they provided new permissions to allow users fine-grained control over access to their private information, but they defaulted the majority of them open and public, requiring user’s to explicitly “lock down” access to the information. What good is it if you can hide much of your private data if it’s already been exposed to the world by default? On the user side, any of the Twitter applications you use that would like to access your private messages will have to go through the Twitter authorization steps again to change the application’s access permissions. While this may be a slight inconvenience to users, it should be a thirty-second process for most and quickly forgotten. The official statement specifies this relates to “third-party apps” so it is still unclear if users of Twitter’s own official client’s will need to go through this process of re-authorization. Another plus on the user side is the updating of the Twitter authorization popup, called Twitter OAuth to more elegantly explain what permissions a user is (and isn’t) giving to the application. Twitter has setup a dedicated FAQ page to keep up with the growing list of questions and answers posed through the various developer lists and via Twitter itself.

Social Pro Daily

How Private Are Your Private Messages?

Damon Parker

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Damon Parker