I’ve talked about this before (as one of the secondary motivators behind OAuth) but I felt it deserved a special call out.
Recently, Simon Willison presented on OpenID and called the practice that Dopplr (and many many others) uses to import your contacts from Gmail absolute horrifying
. I would concur, but point out that Dopplr is probably the least offender as they also provide safe and effective hcard importing from Twitter or any URL, just as Get Satisfaction does.
Unfortunately this latter approach is both less widely implemented and also unfamiliar to many regular folks who really just want to find their friends or invite them to try out a new service.
The tragedy here is that these same folks are being trained to hand out their email address and passwords (which also unlock payment services like Google Checkout) regularly just to use a feature that has become more or less commonplace across all social network sites. In fact, it’s so common that Plaxo even has a free widget that sites can use to automate this process, as does Gigya. Unfortunately, the code for these projects is not really open source, whereas Dopplr’s is, providing little assurance or oversight into how the import is done.
What’s most frustrating about this is that we have the technology to solve this problem once and for all (a mix of OpenID, microformats, OAuth, maybe some Jabber), and actually make this situation better and more secure for folks. Why this hasn’t happened yet, well, I’m sure it has something to do with politics and resources and who knows what else. Anyway, I’m eager to see a open and free solution to this problem and I think it’s the first thing we need to solve after January 1.
Factory Joe 
Good post Chris. We’ve also captured this as social network anti-pattern #1: Upload your Address Book on the microformats wiki.
Please add more examples, screenshots etc. to that wiki page. Please tag any related screenshots on Flickr with: antipattern socialnetworkantipattern
Thanks,
Tantek
Amen.
That’s all I had to say. (Those “import your contacts” boxes drive me crazy: why would I give someone my password?)
This is a great use for oauth and LiveJournal’s GMP. But until people realize they can delegate auth without giving over credentials (read “oauth wins”), we’re screwed.
At least we don’t have places asking for your openid, and the username and password at your OP.
http://wiki.openid.net/Group_Membership_Protocol
On folks are being trained to hand out their email address and passwords – yes, that’s frightening indeed.
But they do it mostly for the same reason that my mother refuses to believe that certain additives will cause cancer:
“If it was really all that bad for me, then someone would make them stop selling it.”
That thinking + reckless use of technology = disaster
I’ll help to spec it out! Should be fairly easy to do like a 0.3 version based on Atom, OAuth, OpenID, etc.
Tara’s point brings up something worth mentioning: this practice is popular because it works pretty darn well for users. People understand the goal (“avoid retyping all those damn addresses”), and the interaction model is very clear. “Upload Your address book” may be the technical anti-pattern, but it’s a very effective design pattern.
Anything that wants to compete with the current way needs to keep it *as simple* as the current way from the user’s point of view.
right on!
First, I’m not giving my password to a random social networking site.
Second, I’ll invite the contacts that I want to invite to a particular service. Yes, it may save time to import, but I don’t need a bot to send friend invites for me.
I’d consider it with your idea of basing it on OpenID, etc. where I might have a little more control over the process along with better security.
I have been surprised at the responses provided by customer support when this issue is raised. For example, here is what Geni, had to say:
They side-stepped the issue, ignoring the potential of the web services abusing the information itself. Not to mention the lil’ phishy training that users internalize in the process.
Indeed the security risks with these practices are obvious but it has been indeed the simplest solution for quite some time. I’d think that Dopplr’s hCard approach is good but maybe so far only understandable to geeks.
For the short term I see the best solution here to use OAuth, Google would need to step forward and enable getting your addressbook via OAuth. Having then libraries for PHP, Ruby, Python etc. for this would IMHO help quite a bit here.
OpenID is not really needed in this step I think but of course it would be great if this could be added in the same step and maybe make it automatable even more.
On the long run I’d like to see little reason to login anywhere to fetch all my contacts from x different places. I would want one place (which I choose) where my contacts are stored. When I login to some new service it should automatically discover these with me just deciding which should be transferred (maybe group based).
But I think we are going in this direction anyway with things like DiSo et. al. It’s mostly a question of adoption.
“I’d think that Dopplr’s hCard approach is good but maybe so far only understandable to geeks.”
And therein lies the problem. OAuth is a great idea, but how do you convince Joe Shmoe that it’s worth him figuring out? Geeks will flock to OAuth inevitably after hearing about it, but they aren’t really the folks who need this. They know better than to give out info like this; Granny Jones doesn’t.
“But I think we are going in this direction anyway with things like DiSo et. al. It’s mostly a question of adoption.”
QFT
Does anybody know if somebody has already created a widget that allows users to import their contacts in a good way…
E.g. Some widget that redirects the user to logon directly to GMAIL asks them which contacts they want to import, imports just those contacts, and brings them back to the website.
I’m not a programmer… I’m just trying to think of a way that people can get their contacts from other email accounts in a way that’s not Phishing site like and super-easy-user-friendly.