Pages

Showing posts with label OAuth. Show all posts
Showing posts with label OAuth. Show all posts

Wednesday, 11 August 2010

I've been scammed! A follow-up to Twitter Auth Issues

This is a follow-up post to Social Network Authorisation Needs to Change.

Having written the above post over a month ago and considering myself to be quite net-savvy, I'm hugely embarrassed and mortified to admit that I've just been victim to a Twitter-related scam. This is the scam site that duped me: http://www.ipadappstesting.com/. It's safe to browse to it - JUST DON'T LOG IN!

I received a Twitter Direct Message (DM) from a trusted friend that invited me to go to the site so that I could sign up to be an iPad tester. At the end of the test period I would get to keep the hardware. Superb! Yeh, right.

My spidey-senses were working well enough that I didn't complete the in-depth financial survey they put in front of me. What did happen, however, was their servers sent DMs to, presumably ALL, my friends inviting them to do the same. Needless to say that this was without my knowledge - let alone my consent.

Twitter, seriously guys, this needs to change quickly otherwise you're going to go the way of Facebook.

The access granted to my account for an application needs to be segmented and I need to have the ability to REVOKE any aspect I'm not entire happy with at login time. For instance, the shill application in question should have had to request DM read / write access during their registration with Twitter. This should then have appeared as a checkbox on the Twitter OAuth screen. I would then have unchecked it.

Feeling rather violated now but, hey, how was I to know? I currently just have to put my trust in the application developers and I don't think that's either fair or sustainable.

Tuesday, 6 July 2010

Social Network Authorisation Needs to Change

A few weeks ago I took a look at a website that needed my twitter login to work. The nature of the site was overtly read-only so I was happy to grant it access via twitter's OAuth process. Yesterday I took another exploratory look at a Facebook application which requested access to my account. Again, the nature of this application was completely read-only. Both apps were mildly interesting and I'd achieved what I'd set out to do. Done.

Imagine my [surprise | outrage | fury] (you choose!) when I discovered that both apps had posted public comments from my account. WTF!? Both used the familiar template of 'I have just used [appX] to do [functionY]. Go to [urlA] to try it yourself.'.

OK, so nothing malicious in that - but I didn't authorise either of these posts. Facebook does give you the ability to deny an application from posting in your name, but only after you've installed it. If the app posts immediately there's nothing you can do about it.

Now, don't get me wrong, good applications deserve to be blown along on the virtual word-of-mouth jet stream; but, and here's the critical bit:

"It should be my decision to publicise my usage of your site."

At TweetPivot we made a very conscious decision to enable a user to promote our site easily but not to presume that that's what they wanted. If the site's good enough they will, but automatically doing it for them removes any worth from the act.

So, what should happen now?

Well, you have to apply to Twitter if you want your application to be able to use their OAuth process. At that point you are asked whether your application requires read-only or read-write access to users' accounts. When I enter my details into the popup OAuth window I want to be told whether I'm giving write rights to the app and, if that's not acceptable to me, I want to be able to decline that 'write' request. If you want me to try out an application that I know has no reason to write to my account then I need confirmation that you can't.

I would hate to see the Twitter authentication process get as complicated as Facebook's became; but it does need improving. The API that all 3rd-parties hook into has very specific, well defined methods. Developers should have to declare, individually, which ones they need to invoke. For instance, if I gave you read-only access to my account how can I be sure that you haven't just farmed off all my private Direct Messages?

Ultimately, this is going to be bad news for application developers that require integration to social networks. The next time I'm asked to try something like this I might hesitate. The time after that I might decline. Good developers are going to be punished and their great apps ignored by the unacceptable actions of the few.