I’ll often want to Tweet something, but feel the need to explain further in a second Tweet. But something in that will need explaining, so it occurs to me that I really need a blog post. But then I realize I should probably post this as 2 or more separate posts to isolate ideas and keep them self contained and just link between them.
Then I realize I’ve got work to do, and drop it till I have time …
… which never comes and my thought dies having never lived.
*Even this one tweet expanded into a blog post!
I’m noticing a lot of Twitter tools requiring the user to enter their Twitter user id and password to use the tool. These tools obviously need the users’ credentials to access the Twitter API and act on behalf of the user.
But am I the only one who is uncomfortable with this? I mean, isn’t the first rule of passwords not to give them out to anybody? Isn’t it?!?!?
Instead it’s become the acceptable practice to enter it into every app requesting it! Correct me if I’m wrong, but as far as I know, you can’t use TweetDeck, StockTwits, or Twubble without entering your Twitter credentials, just to name a few.
Now you may say, the risk is low … I mean who really gives a hoot if my Twitter account gets hijacked? I’ve currently got 91 followers, many of which are social media experts looking for reciprocity follows anyway! Who cares? Nobody’s listening! Maybe so, but all it really takes is one follower who trusts me to go to a phishing site and act on ‘my’ recommendation. The risk is high enough for me.
The stakes are even higher for users with larger followings. Do you think Ashton Kutcher, with his 933k followers, doesn’t use any of these tools? Do you really think he’s using the basic web page? I doubt it.
…. maybe I’m being paranoid. After all, I have zero qualms about entering my sys admin credentials into my database tools. Currently I use Microsoft tools to access my SQLServer databases, so there is a bit more trust, but I still wouldn’t have a problem entering my credentials into TOAD to access an Oracle database.
My fear is that as more web applications attempt to expose their API’s to 3rd party developers, this unsafe credential divulging scenario will only proliferate.
What is really needed is second tier Twitter access. Like the valet key for your car, you can hand over the keys to the valet, but they can’t pop the hood, get in your glove box, or steal the golf clubs out of your trunk.
It’s late and to be honest I don’t immediately see any good way to handle this, but here are some initial ideas:
- A second lower tier password specifically for 3rd party tools
- Having the tool redirect to some kind of Twitter log in page, hosted on Twitter, which would then return the user to the tool web site, while providing access in the name of the user.
- The ability to log into Twitter and get a temporary or permanent ‘application key’, which the user could copy & paste into the tool.
Option 1 and 3 both kind of suck, with 3 adding any extra cumbersome step, increasing resistance and dropping adoption of these tools.
WeFollow is currently using it. If you go to their home page (do people still say home page?), click on the ‘Add yourself to WeFollow’ image, you eventually get sent to a Twitter authentication page. Once you authenticate yourself, and you get sent back to the WeFollow site. This is nothing new, and is used in PayPal and MyOpenID just to name two. Later, you can go into your Twitter Settings, select the Connections tab, and remove WeFollow from having access if you want to.
This doesn’t really work well with a desktop application, since the browser would probably end up being embedded right into the desktop app anyway, which doesn’t really have the detached neutrality feel of a 3rd party web browser does it? So some type of valet key for the desktop apps would still be preferred, but in truth, I feel a lot more comfortable entering my credentials into a desktop app, than an unknown website any day.
Why aren’t their users demanding it?
Copyright © John MacIntyre 2009, All rights reserved
WARNING – All source code is written to demonstrate the current concept. It may be unsafe and not exactly optimal.