January 9th, 2009
The Curious Case of Twitter and Twply
by Joshua Porter | 
15 Comments | shortlink: http://bokardo.com/p/938
Late last week a service called Twply tricked over eight hundred Twitter users to give over their sign-up credentials using deceitful design. I’ve annotated their sign-up screen to show how they did it.
The Twply story is a lesson in many ways (see the discussion about the password anti-pattern here, here, and here), but I going to focus on the interface of the service in particular.
First off, here is how the ruse worked. Twply claimed to send @replies to your inbox, a valuable service that Twitter doesn’t currently provide (Twitter does give you the option of sending direct messages) When you signed up for Twply, you enter your Twitter username and password to give them access to your account. You also had the option to “support” Twply on your first login (an option which was on by default). Many people did this. However, after they signed up, many noticed that Twply had posted to their account on their behalf (that’s what “support” meant). The message read:
“Just started using http://twply.com/ to get my @replies via email. Neat stuff!”
So followers of the person, upon seeing the tweet, would then go see what Twply was about, and the process would repeat itself. Thus Twply started a viral campaign that spread itself to thousands of twitters very quickly. This, in itself, isn’t a bad thing. Unfortunately for people who tried Twply, they did it using deceitful design.
I’ve annotated the Twply screen with a few of the problems, including patently false copywriting, ambiguous messaging, and interface elements that are out of order.
(click for full size)
Further, Twply was creating false recommendations. When a follower would see “Neat Stuff” in the tweet, the rational assumption would be to believe that the person had actually posted the tweet themselves. Of course, they didn’t, and so the deceiving message was passed off as authentic.
Even worse, Twply sent the tweet even if you selected the option to not support them! This is evil, and must never happen in interface design. It’s akin to the database mantra that you must never show conflicting data. In this case, there must never be a conflict between the actions of the system and the interface which describes it.
But that’s not all. During Twply’s fast rise to prominence, Robert Scoble posted his thoughts on the matter, calling the ruse “SPAM”. Someone from Twply commented on the post, claiming that people didn’t have the right to complain:
Honestly everyone needs to stop yelling about the message, we clearly ask on the homepage. Before it was based on IP but we took that off so everyone can see. If you want to see please log out or see the screenshot here. http://upload3.net//uploads/761Picture%206.png
Sorry if this killed your twitter account, but dont say we didnt ask.
The service is currently down right now due how effective the marketing worked.”
Obviously, this denies the reality of the situation. The interface is not clear at all. Nowhere does it say that the service will post a tweet on your behalf. That, at the very least, needs to be made explicit. (of course, this issue is moot anyway since the tweet was sent even if you opted to not “support” Twply).
Finally, as if to declare to the world their evilness, Twply was auctioned off within 24 hours, after having accumulated over 8 hundred twitter passwords, for $1,200.
The text they used to help sell their newly minted dataset?
“Twply has been spread through twitter like nothing I have ever seen before, over 800 accounts added in one day.
Big names like TechCrunch, 1938media and many more using the service.”
Moral of the story? Design can effectively be used to deceive people. Deal only with those services you know and trust. Oh…and don’t trust everything you twead.
Links to this Post
Comments
1. Daniel 10:56am, Fri 9th, 2009
Twitter could also help avoid the viral nature of these things by not setting source of posts from the API as “web”. That way people can tell if the tweet was handwritten via twitter.com or not. Right now, there is no way to know. I just submitted this suggestion to the Twitter Dev Group.
2. Sarah Bourne 11:33am, Fri 9th, 2009
Nice write-up, Josh. I was talking to one of our Security Gurus about this case the other day, especially about the “social engineering” aspect. We also talked about the “twishing” exploit this week and the doubt this throws on the viability of Twitter for any official government activities. Personally, I’ve decided that there is no web-based twitter service that could offer enough value to warrant relinquishing my password! Security may not seem Fun! but it is the guardian of trust.
3. Hugh Briss 1:40pm, Fri 9th, 2009
Shouldn’t that be “twead”?
4. Matthew Snodgrass 1:44pm, Fri 9th, 2009
Great article. I wonder how many people were twicked?
5. James Williams 1:45pm, Fri 9th, 2009
Awesome writeup, I have been very conscious of late, as I started to add services that the service was genuinely needed, but I think what is needed, is an interface on Twitter that third party apps can link into that does not give them control of the settings and profile of the user that hooks the app.
Keep up the vigilance, thanks for your work
6. Josh 2:51pm, Fri 9th, 2009
@Hugh: Yes. Changed. Thanks!
7. Josh 2:52pm, Fri 9th, 2009
@Sarah thanks for mentioned the trust issues within government. Are you folks actively considering Twitter integration?
8. zephyr 2:53pm, Fri 9th, 2009
I don’t know if them selling it in a hurry is confirmation of there evilness or just sheer panic. $1200 doesn’t seem worth the effort.
9. Sarah Bourne 3:08pm, Fri 9th, 2009
I wouldn’t try to claim that we’re thought – much less action! – leaders, but there are a few of us looking a Twitter as an additional communication channel. Emergency communications seem promising, especially for situations where folks may not have access to desktop computers (for instance.) We’re also thinking about the social/conversational aspects of using Twitter as part of our efforts to foster civic engagement.
So far, we’ve only taken baby steps: a few of us are trying to embrace and learn about Twitter, and we’ve set up robo-feed accounts for both the state portal (@massgov) and the Governor’s Office (@massgovernor). And we’re trying to pull together what we’ve learned so we can start evangelizing.
10. Conrad 3:08am, Sun 11th, 2009
Well this just helps http://www.tweetreplies.com, we offer a real service that send emails and uses no password. The design might not bed as great but we work and dont need password.
11. Russ 6:13pm, Tue 13th, 2009
@Sarah: I was recently reading an article about the success and potential security issues with Twitter (sorry I cannot recall the URL). The author of the article mentioned that they should be able to identify higher profile/traffic accounts and add additional levels of security. Granted, those accounts might still be at risk of phishing, but other web services have taken steps to try to help them from being hijacked.
@Conrad: Hope this doesn’t hinder your potential success. I wonder if it would do more harm or good to mention this story somehow on your site and explain how you’re not like them.
12. Manuel 10:43pm, Thu 22nd, 2009
The auction link does not work – seems you need to remove the blanks at the end of the url.
13. Social Media Blog 5:11pm, Sun 1st, 2009
Nice post. This is why I don’t use any service that relies on my credentials for another site. For example, I think TwitPic and Xoopit are probably great services that add value, but so much of our lives are online now that the risk of sharing your login info with another company is just too great. I understand that they’re trying to make our lives simpler by requiring one less password, but its still not worth it. If companies would opt to include AuthSub or OAuth in their API then we wouldn’t have to share our credentials.