Mark Ng's dashboard

A follow up - now, if you follow the twitfave user, it prioritises you and your followers - also, if you ask for a user via the user box, it'll find the user straight away, but not that users favourites straight away.

thanks for your kind note :)

Hi, this comes from the way that twitfave works versus the way favrd works. Twitfave spiders the whole of public twitter, and discovers new users by following the favourites of other users. Favrd is an opt-in system, where users favourites are indexed when that user opts in (so far as I'm aware).

If twitfave doesn't know about a user, it's because that user is private or it hasn't found that user by spidering yet (obviously, twitter has alot of information !). I am planning to allow manual addition of users to twitfave at a later date. That said, I'm happy to add a couple of users as points from which to spider now manually, if you would like to give me a couple of usernames.

added to the wishlist - if you want this information in a less convenient manner, however, you could filter the API results, too:

http://code.google.com/p/twitter-api/... - twitter have fixed the ability to specify source. This will probably help with making improvements with this issue.

I'm sorry, for my part, if I seemed unfriendly. I don't know if I was one of those you refer to. However, it's worth noting that the somewhat... robust response back from getsatisfaction was probably what caused alot of people to join in the conversation. Perhaps there are lessons for all of us to learn here. – Mark Ng, on November 24, 2008 19:47

Scott and Ted, I'm kind of surprised by the push-back from you guys. As your rightly pointed out, you have done *excellent* work on implementing OpenID and hCard subscription in your sign-up process so I would have that the negative effects of the password anti-pattern would be self-evident to such savvy developers.

I can't provide you with too many examples of direct phishing attacks based on the password anti-pattern. Here's one:
http://www.codinghorror.com/blog/arch...

Then there are the less extreme cases like the MyNameIsE example mentioned above:
http://getsatisfaction.com/e/topics/a...

That was an example of (mild) identity theft rather than direct phishing.

But as so many have already pointed out, the real problem isn't direct cause and effect phishing, it's the message being sent out that it's okay to hand out passwords from one site (Twitter) on a completely different site (Get Satisfaction). If—or should I say when—this practice becomes commonplace then phishing and identity theft become so much easier ...even if it remains hard to measure directly.

Right now, Get Satisfaction are basically aligning themselves with sites like this: http://twitterawesomeness.com/
(though this is done as a joke whereas Get Satisfaction are doing it in all seriousness).

Now, the usual response to pleas for removing the password anti-pattern (e.g. Slideshare, Pownce, LinkedIn) is that they desperately need to be able to import people's address books. In the case of Get Satisfaction, you aren't even trying to do that! All you want to do is allow people to post a message to Twitter. For that, you *do not* need anybody's password.

Ted, you asked me to provide a solution. I made very sure to do just that in my original post. Simply make your "Twitter this" an actual URL that points to http://twitter.com/home passing it a query string with a variable called "status" pre-populated with the message you want to post.

The current solution isn't just bad practice and bad for the web, it's kind of over-engineered, don't you think?

P.S. to everyone else who is rightly upset by this, please remember: Ted and Scott really are top-notch developers who have done great things with OpenID support and hCard subscription.

Interesting point. I'd counter that casual users tend to have anti-virus and anti-spyware software, where they don't tend to have anti-phishing software. – Mark Ng, on November 24, 2008 19:30

@martin twitterific, running on my local machine, is something I can watch the network traffic coming to and fro, should I choose to. I can verify that it is doing nothing naughty and that it's not storing a password somewhere where someone other than I can get to it.

I cannot verify what anyone else does with my password.

I don't see that the benefit of retweeting something straight from the page out-weigh the *actual* (not perceived) harm caused by spamming expeditions like that of Quechup or similar.

@ted, i think adactio DID offer you a solution. Use the ?update= there is no reason you NEED the persons password except for YOUR convince not theirs. You are now in-control of sensitive information!

there have been plenty of examples of people being phished. Quetchup and Plaxo being just two examples. You give them your name and password in good faith and they go and spam your whole address book. There are probably plenty of other examples that have gone UN-noticed as well.

"hello my name is e" is another example of being phished by a company. You gave your twitter name and password to them to allow them to find your social network friends. Behind the scenes they were posting to twitter on your behalf. Just search for "hello my name is e" http://hellomynameise.com/ and you will quickly see how many people got burned by entering their passwords. It could have been MUCH MUCH worse because people are stupid and use the same password for multiple services!

I am concerned that you are so quick to dismiss "benefit out-weighs any perceived harm", isn't just one person's bank account being completely emptied because of password phishing bad enough?

A solution was offered that solves the problem without having to use a password, and infact is ALOT less code to maintain. That should be your benefit! That certainly out-weights the liability of your service, or an evil employee, taking user passwords and exploiting them across the web.

presumably, the reason alot of people still ask for a username and password to do this is for self promotional purposes (via the API, it'll show the client name which will click through to the website).

This doesn't excuse this, of course. If anything, it makes it even worse.

Hi,

I've built an app that does this (I'm not a twitter employee, but their API allows you to do useful things like this). It takes a while to pick up all tweets, due to the way it has to crawl the API, but it's still useful (though it only works if you're a public user).

It's at http://twitfave.com/

Mark

Good idea - consider this near the top of the list (got a bunch of UI issues to work on first), but this will be our first new actual feature.