Design patterns are useful. They enable us as developers to encapsulate recurring interactions and refine them. From simple pagination right up to Ajax requests, patterns allow us to codify common conventions.
Inevitably, conventions can lead to a cargo cult mentality. Clients start to request
Allowing users to import contact lists from other services is a useful feature. But the means have to justify the ends. Empowering the user to import data through an authentication layer like OAuth is the correct way to export data. On the other hand, asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:
It teaches people how to be phished.
This issue was raised by Tantek at Fundamentos Web. Rigo Wenning—privacy activity lead at the W3C—was quick to back Tantek’s position. While we can’t protect people from themselves, we have a duty not to deceive them into thinking that throwing passwords around like confetti is acceptable behaviour.
Oh, don’t worry… the terms of service for Google accounts puts the responsibility in the hands of the user:
- Your passwords and account security
- 6.1 You agree and understand that you are responsible for maintaining the confidentiality of passwords associated with any account you use to access the Services.
- 6.2 Accordingly, you agree that you will be solely responsible to Google for all activities that occur under your account.
…but this isn’t a question of legalities.
I was somewhat surprised, even shocked, to see 37 Signals highlight this anti-pattern on Facebook as
a smart way to connect members of the site. Simon was quick to point out the problem:
The Facebook thing isn’t a smart way of connecting members, it’s a horrible precedent that teaches users to be phished. Unfortunately that kind of feature is so prevalent now that you’d be foolish to launch a new social network without it, but from an ethical point of view it’s distinctly unpleasant.
He’s right. The issue for us as developers is a moral question. Do we blindly follow the dictates of clients looking to “add value” to their applications even when we know that the long-term effect is corrosive? I don’t think we should. We can collectively make a choice not to erode the long-term stability of our users’ data. Sure, the particular site you’re working on might not have any nefarious plans and the next site might claim to be secure, but over time we’re creating a climate conducive to cultivating honeypots.
Morality (or ethics) is not something that’s usually discussed alongside Web development. But Jeff Veen pointed me towards this great quote from Jamais Cascio’s talk at the Singularity Summity that illustrates the underlying truth:
To put it bluntly, software, like all technologies, is inherently political. Even the most disruptive technologies, the innovations and ideas that can utterly transform society, carry with them the legacies of past decisions, the culture and history of the societies that spawned them. Code inevitably reflects the choices, biases and desires of its creators.
So here’s what I’m going to do: even if it costs me a contract in the short-term, I will refuse to implement any kind of interface that involves asking the user for a password from a third-party site. I urge you to do the same. And if you feel equally strongly about this, make your thoughts known: blog about it, talk about it… you might even want to make your position clear in your terms and conditions. As the Naked Yak blog so eloquently puts it:
With the endless possibilities of the social web it is easy to fall into the trap of going for broke, applying everything in life to a particular application or piece of software that seems to enhance it. From now, I will always ask the question “Will this have a positive effect on my world?” rather than “What could I pull into this new tool?”
Update: For all the people saying
yeah, but no, but yeah, but we need access to users’ data, please read the post again and this time, pay attention to the part about OAuth. See also:
I don’t know how much clearer I can make this: the end result of exporting data is desirable; teaching users to hand over their passwords to any site that asks for them is not. There is no excuse for asking for a third-party password on your website. You’re doing it wrong. That authentication must happen on the third-party site.