Journal tags: antipattern

I think a lot about Danielle’s talk at Patterns Day last year.

Around about the six minute mark she starts talking about gaps and overlaps.

Gaps are where hidden complexity live. If we don’t have a category to cover it, in effect it becomes invisible. But that doesn’t mean it’s not there. Unidentified gaps cause inconsistency and confusion.

Overlaps occur when two separate categories encompass some of the same areas of responsibility. They cause conflict, duplication of effort, and unnecessary friction.

This is the bit I keep thinking about. It’s such an insightful lens to view things through. On just about any project, tensions are almost due to either gaps (“I thought someone else was doing that”) or overlaps (“Oh, you’re doing that? I thought we were doing that”).

When I was talking to Gerry on his new podcast recently, we were trying to figure out why web performance is in such a woeful state. I mused that there may be a gap. Perhaps designers think it’s a technical problem and developers think it’s a design problem. I guess you could try to bridge this gap by having someone whose job is to focus entirely on performance. But I suspect the better—but harder—solution is to create a shared culture of performance, of the kind Lara wrote about in her book:

Performance is truly everyone’s responsibility. Anyone who affects the user experience of a site has a relationship to how it performs. While it’s possible for you to single-handedly build and maintain an incredibly fast experience, you’d be constantly fighting an uphill battle when other contributors touch the site and make changes, or as the Web continues to evolve.

I suspect there’s a similar ownership gap at play when it comes to the ubiquitous obtrusive overlays that are plastered on so many websites these days.

Kirill Grouchnikov recently published a gallery of screenshots showcasing the beauty of modern mobile websites:

There are two things common between the websites in these screenshots that I took yesterday.

1. They are beautifully designed, with great typography, clear branding, all optimized for readability.
2. I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.

The web can be beautiful. Except it’s not right now.

How is this dissonance possible? How can designers and developers who clearly care about the user experience be responsible for unleashing such user-hostile interfaces?

PM/Legal/Marketing made me do it

I get that. But surely the solution can’t be to shrug our shoulders, pass the buck, and say “not my job.” Somebody designed each one of those obtrusive overlays. Somebody coded up each one and pushed them into production.

It’s clear that this is a problem of communication and understanding, rather than a technical problem. As always. We like to talk about how hard and complex our technical work is, but frankly, it’s a lot easier to get a computer to do what you want than to convince a human. Not least because you also need to understand what that other human wants. As Danielle says:

Recognising the gaps and overlaps is only half the battle. If we apply tools to a people problem, we will only end up moving the problem somewhere else.

Some issues can be solved with better tools or better processes. In most of our workplaces, we tend to reach for tools and processes by default, because they feel easier to implement. But as often as not, it’s not a technology problem. It’s a people problem. And the solution actually involves communication skills, or effective dialogue.

So let’s say it is someone in the marketing department who is pushing to have an obtrusive newsletter sign-up form get shoved in the user’s face. Talk to them. Figure out what their goals are—what outcome are they hoping to get to. If they don’t seem to understand the user-experience implications, talk to them about that. But it needs to be a two-way conversation. You need to understand what they need before you start telling them what you want.

I realise that makes it sound patronisingly simple, and I know that in actuality it’s a sisyphean task. It may be that genuine understanding between people is the wickedest of design problems. But even if this problem seems insurmoutable, at least you’d be tackling the right problem.

Because the web can’t survive like this.

Twitter has come in for a lot of (justifiable) criticism for changes to its API that make it somewhat developer-hostile. But it has to be said that developers don’t always behave responsibly when they’re using the API.

The classic example of this is the granting of permissions. James summed it up nicely: it’s just plain rude to ask for write-access to my Twitter account before I’ve even started to use your service. I could understand it if the service needed to post to my timeline, but most of the time these services claim that they want me to sign up via Twitter so that I can find my friends who are also using the service — that doesn’t require write access. Quite often, these requests to authenticate are accompanied by reassurances like “we’ll never tweet without your permission” …in which case, why ask for write-access in the first place?

To be fair, it used to be a lot harder to separate out read and write permissions for Twitter authentication. But now it’s actually not that bad, although it’s still not as granular as it could be.

One of the services that used to require write-access to my Twitter account was Lanyrd. I gave it permission, but only because I knew the people behind the service (a decision-making process that doesn’t scale very well). I always felt uneasy that Lanyrd had write-access to my timeline. Eventually I decided that I couldn’t in good conscience allow the lovely Lanyrd people to be an exception just because I knew where they lived. Fortunately, they concurred with my unease. They changed their log-in system so that it only requires read-access. If and when they need write-access, that’s the point at which they ask for it:

We now ask for read-only permission the first time you sign in, and only ask to upgrade to write access later on when you do something that needs it; for example following someone on Twitter from the our attendee directory.

Far too many services ask for write-access up front, without providing a justification. When asked for an explanation, I’m sure most of them would say “well, that’s how everyone else does it”, and they would, alas, be correct.

What’s worse is that users grant write-access so freely. I was somewhat shocked by the amount of tech-savvy friends who unwittingly spammed my timeline with automated tweets from a service called Twitter Counter. Their reactions ranged from sheepish to embarrassed to angry.

I urge you to go through your Twitter settings and prune any services that currently have write-access that don’t actually need it. You may be surprised by the sheer volume of apps that can post to Twitter on your behalf. Do you trust them all? Are you certain that they won’t be bought up by a different, less trustworthy company?

If a service asks me to sign up but insists on having write-access to my Twitter account, it feels like being asked out on a date while insisting I sign a pre-nuptial agreement. Not only is somewhat premature, it shows a certain lack of respect.

Not every service behaves so ungallantly. Done Not Done, 1001 Beers, and Mapalong all use Twitter for log-in, but none of them require write-access up-front.

Branch and Medium are typical examples of bad actors in this regard. The core functionality of these sites has nothing to do with posting to Twitter, but both sites want write-access so that they can potentially post to Twitter on my behalf later on. I know that I won’t ever want either service to do that. I can either trust them, or not use the service at all. Signing up without granting write-access to my Twitter account isn’t an option.

I sent some feedback to Branch and part of their response was to say the problem was with the way Twitter lumps permissions together. That used to be true, but Lanyrd’s exemplary use of Twitter for log-in makes that argument somewhat hollow.

In the case of Branch, Medium, and many other services, Twitter authentication is the only way to sign up and start using the service. Using a username and password isn’t an option. On the face of it, requiring Twitter for authentication doesn’t sound all that different to requiring an email address for authentication. But demanding write-access to Twitter is the equivalent of demanding the ability to send emails from your email address.

The way that so many services unnecessarily ask for write-access to Twitter—and the way that so many users unquestioningly grant it—reminds me of the password anti-pattern all over again. Because this rude behaviour is so prevalent, it has now become the norm. If we want this situation to change, we need to demand more respect.

The next time that a service demands unwarranted write-access to your Twitter account, refuse to grant it. Then tell the people behind that service why you’re refusing to sign up.

And please take a moment to go through the services you’ve already authorised.

Quite quickly after I wrote my email to Findings about their email notification anti-pattern, I got a response back from Lauren Leto:

Give it to us. I applaud you shouting at us from a rooftop. I also hate defaulting to all notifications and agree that it was a douchebag startup move but can assure it was one made accidentally - a horrible oversight that the entire team feels bad about and will work to amend for you and the rest of our users.

We try to be a site for the common user - nothing like Facebook taking cheap shots wherever they can. I hope we haven’t forever turned you off from our site. Relaunches are hard and mistakes were made but nothing like this will happen again.

Apart from the use of the passive voice (“mistakes were made” rather than “we made mistakes”), that’s a pretty damn good response. She didn’t try to defend or justify the behaviour. That’s good.

She also asked if there was anything they could do to make it up to me. I asked if I could publish their response here. “Yeah, feel free to post”, she said.

I think it’s important that situations like this get documented. It could be especially useful for new start-ups who might be thinking about indulging in a bit of “growth hacking” (spit!) under the impression that this kind of behaviour is acceptable just because other start-ups—like Findings—implemented the email notification anti-pattern.

As Lauren said:

I think every startup manages to mess up one of these at some point in their life, either willingly or unwillingly. A clear listing of all offenses could be useful to everyone.

That’s where Harry’s Dark Patterns wiki comes in:

The purpose of this pattern library is to “name and shame” Dark Patterns and the companies that use them.

• For consumers, forewarned is fore-armed.
• For brand-owners, the bad-press associated with being named as an offender should discourage usage.
• For designers, this site provides ammunition to refuse unethical requests by our clients / bosses. (e.g. “I won’t implement opt-out defaults for the insurance upsells because that practice is considered unethical and it will get you unwanted bad press.”)

The email notification anti-pattern isn’t yet listed on the wiki. I’ll see if I can get Harry to add it.

Dear Findings,

I see you have introduced some new email notifications. I have also noticed (via my newly-overstuffed inbox) that by default, these new email notifications are checked.

WHAT THE FSCK WERE YOU THINKING‽

Sorry. Sorry. I lost my temper for a moment there. And the question is rhetorical because I think I know exactly what you were thinking …“traction”, “retention”, “engagement”, yadda yadda.

I realise that many other sites also do this. That does not make it right. In fact, given the sites that already do this include such pillars of empathy as Facebook, I would say that this kind of behaviour probably has a one-to-one correlation with the douchebaggery of the site in question.

You’re better than this.

Stop. Think. Spare a thought for those of us who don’t suddenly—from one day to the next—want our inboxes spammed by emails we never opted into.

Didn’t anybody stop to think about just how intrusive this would be?

Also, doesn’t this flood of new emails directly contradict this section of your privacy policy?:

As part of the Services, you may occasionally receive email and other communications from us, such as communications relating to your Account. Communications relating to your Account will only be sent for purposes important to the Services, such as password recovery.

Contrary to appearances, I don’t want to be completely negative, so I’ve got a constructive suggestion.

How about this:

If you’re about to introduce new email notifications, and all my existing notification settings are set to “off”, perhaps you could set the new notifications to “off” as well?

Sound good?

All the best,

Jeremy

Two months ago, I called Twitter out on their insistence that developers use OAuth when authorising with Twitter while they themselves continued to use the password anti-pattern when they wanted to peek into third-party address books.

I’m happy to report that Twitter have since fixed this. If you go to the Find Friends portion of the “Who To Follow” section, you’ll now be greeted with links that lead to correct authentication with LinkedIn, Gmail, Yahoo and Hotmail.

Thanks, Twitteroonies!

Meanwhile, Flickr recently launched their own “Who to Follow” functionality. There is nary a password request in sight: they’ve implemented correct authentication right out of the gate for Yahoo, Gmail, Hotmail and Facebook.

Thanks, Flickroonies!

See? I’m not always bitching’n’moaning.

The OAuthcalypse is upon us. Since August 31st, all third-party Twitter services must use OAuth to authenticate. This is a good thing; a very good thing. Before that date, services were allowed to use the password anti-pattern to log you in.

Twitter has put its foot down and declared that the password anti-pattern will no longer be tolerated. Hurrah!

What a shame then, that Twitter is being utterly hypocritical. On their Find Friends page, they encourage you to:

Scan your email address book or contacts to discover which of your friends are already using Twitter.

They do this using the password anti-pattern. You are asked for your Gmail password even though the Google Contacts API would allow Twitter to connect to Gmail using proper authentication …exactly what Twitter is insisting third-parties use when they want to access Twitter’s data.

Twitter asks for your Yahoo Mail password even though the Yahoo Contacts API would allow them access to your address book using OAuth.

Twitter asks for AOL passwords (now there’s an audience that we shouldn’t be teaching to give their passwords away) but even AOL has an API with proper authentication.

Twitter does connect to LinkedIn correctly. That’s one out of four.

There are two solutions to this state of affairs. Either Twitter decides to do the right thing and switch over to using APIs and authentication for Gmail, Yahoo and AOL …or else Gmail, Yahoo and AOL follow Twitter’s example and disallow the password anti-pattern for scraping address books.

Twitter should not be encouraging Gmail users, Yahoo users and AOL users to divulge their passwords but at the same time, Gmail, Yahoo and AOL should be taking steps to ensure that such profligate behaviour is not rewarded.

Twitter has done the right thing with third-party services wishing to access its data. Now let’s see if the third-party services currently being abused by Twitter will follow this example.

Update: There are some very encouraging responses from Twitter. Ryan Sarver says:

all good points and I think there are already plans to fix it

And Josh Elman concurs:

yes - great points and something we hope to migrate very soon

Twply is a straightforward little Twitter app that sends @replies to email. It uses the password anti-pattern. Oh, but don’t worry. It states quite clearly on the site that Your password is safe with us. No worries!

Twply is up for sale . That means all those passwords are available to the highest bidder ($1200 in this case).

Sleep tight, Twply users. May you wake to a better day.

A new site called My Name Is E launched for beta testing today. Eager geeks rushed to sign up for the contact aggregation service. The second step of the process involved handing over your Twitter username and password. This request was dutifully obeyed by the eager geeks.

Muppets.

This is a classic example of the password anti-pattern. And this time it bit the willing victims on the ass. My Name Is E used the credentials to log in to Twitter as that person and post a spammy message from their account.

This is identity theft. It’s not as extreme as having your credit card used or having somebody get in to your email account but it’s still an unrequested violation of personal details. I’m very interested in hearing how the willing victims felt when they saw the message appear on Twitter with their own name and their own avatar next to it. I imagine adjectives like “outraged” and “shocked” would describe the initial reaction but I wonder if “embarrassed” would be far behind.

The “auto-tweeting feature[sic]” was removed within hours in response to the overwhelming negative reaction, as demonstrated on Get Satisfaction. What’s ironic, in the Alanis Morissette definition of the word, is that the Get Satisfaction page features a “share” tab that includes a link to “Twitter this.” Click it. Go on.

Needless to say, I disapprove of what My Name Is E did. But I don’t lay the blame entirely at their feet. Frankly, I’m really disappointed that so many people who really ought to know better were so quick to hand over their Twitter password to any site other than Twitter.

I blame Facebook.

I don’t mean that facetiously. I really do blame Facebook. I also blame Digg. And LinkedIn. And Plaxo. And Twitter.

All of those sites—and many others—actively, sometimes aggressively, use the password anti-pattern. Together they have created a pervasive atmosphere in which it is now completely acceptable for even seasoned geeks to throw their passwords ‘round like car keys at a dodgy ’70s party.

I’ve been banging on about the password anti-password for what feels like ages now. I keep saying that it’s teaching users how to be phished. After a particularly dispiriting discussion of OAuth on the iPhone, Simon went one further and put it in the past tense.

I fear that Simon may be right. But I’m not going to give up hope just yet. Now that Google, Yahoo and Hotmail all have OAuth-style contacts APIs, I think the tide could still be turned.

Mind you, Twitter’s continuing lack of an OAuth-based API is nothing short of shameful, as acknowledged by Blaine in his comment here:

OAuth came out of my worry that if the Twitter API became popular, we’d be spreading passwords all around the web. OAuth took longer to finish than it took for the Twitter API to become popular, and as a result many Twitter users’ passwords are scattered pretty carelessly around the web. This is a terrible situation, and one we as responsible web developers should work to prevent.

So while Twitter positively encourages the password anti-pattern (by example and by design), the situation is very different now for Google, Yahoo and Microsoft. Access to those web-based email services are used as justification for the majority of instances of the password anti-pattern. Now that they all offer alternatives, the only reason for abusers (like Digg and LinkedIn) not to switch from the password anti-pattern to using the official APIs is development time and priority.

Those are valid reasons for not immediately making the switch so I understand that not everybody scrambled to implement, say, the Google Contacts API in the week it came out. But it was released in March. It is now September. Surely that’s long enough for even a low priority task to get implemented?

I realise that I sound very negative in my finger-pointing here so I’d like to give credit where credit is due. Back in March, I listed a chart of web sites who were using the password anti-pattern but who I hoped would switch over. Shame on me for not including Flickr in the list because they were the first to follow Dopplr’s lead and scrap the anti-pattern in favour of a seamless import feature. Shame on me also for putting Last.fm at the bottom of the list. As part of their recent redesign, they too scrapped the anti-pattern. Good for them!

At the top of my list of sites I expected to ditch the anti-pattern was Pownce. Alas, they’re still not all the way there (Yahoo import is working correctly, GMail and AOL isn’t). But after some petulant grandstanding on my part, I have been assured that they are working on it.

I know I should care more about the big abusers like LinkedIn and Facebook than the little guys like Slideshare and Pownce. But it’s precisely because I love Pownce so, so much that it upsets me to see them get such an important thing so wrong when they get everything else so, so right.

Y’see, I’ve been thinking of putting my money where my mouth is. I should really plant a flag in the sand and set a date in the not-too-distant future (like maybe early next year) beyond which I will simply refuse to use any site that implements the password anti-pattern …and delete any existing accounts.

Now, I wouldn’t mind doing this for LinkedIn, Digg or Facebook (I’ve already done it for Plaxo). I wouldn’t miss those sites. I don’t have any strong attachment to those sites. But I have a very strong attachment to Pownce and I would miss it very, very much if I were to delete my account there.

I’d also have to delete my Twitter account, which would probably feel like losing a limb. It’s not that I feel a strong emotional attachment to Twitter—using Twitter often feels like being in an abusive relationship with a Fail Whale—but it’s so pervasive that it would be like swearing off using email, or chat, or the telephone.

Besides, what difference would this grandstanding of mine do? I’m just one measly account. But if other people were to join me …well, perhaps that might affect the speed and priority of abandoning the password anti-pattern.

I could set up a Wiki, or something similar; somewhere where others could add their voice to the call to remove the password anti-pattern. It needn’t be wholly negative either: it could double up as a place for listing useful resources for developers who want to implement OAuth-style APIs.

So I have a few questions for you:

1. Is this a good idea or am I tripping?
2. Would you abandon sites that refuse to ditch the password anti-pattern?
3. Do you know of any good, easy to implement Wiki software?

Today Yahoo announced the release of their Address Book API — previously only available internally and to selected partners. It follows on from Google’s Contacts Data API and I hope that this is one more nail in the coffin of the password anti-pattern.

Chris has expressed disappointment with the proprietary nature of the response formats and Dave also wishes there were more consistent APIs. It’s a fair point but the situation is still immeasurably better than logging in and scraping the individual address book services.

The sites that have so far abandoned the anti-pattern in favour of best practices are:

• Dopplr and
• Flickr

Meanwhile a whole bunch of otherwise-great services are still encouraging people to get phished:

• Pownce
• LinkedIn
• Digg
• Last.fm and
• Twitter …although, to be fair, they’ve got some other problems they need to be concentrating on right now.

The clock is ticking. There really isn’t any excuse any more for asking for my Yahoo Mail or GMail username and password.

There are two problems with April fool’s day on the Web.

Firstly, there’s the curiously timeless nature of online publishing. Google has a habit of preserving everything we write in amber so that long after a joke has been published in the context of April 1st, it resurfaces in search results where it may the taken at face value.

Secondly, it becomes very difficult to separate “real” stories from the japes. Remember a few years back when Google launched their GMail service? Remember what day they launched it on? I recall quite a few people who refused to believe the veracity of the announcement.

With that in mind, here are some tidbits that are most definitely pranks:

• GMail adds time-travel support using an e-flux capacitor to resolve issues of causality.
• John Resig releases Class Query for developers who are sick and tired of brevity and simplicity. This one is only funny if you a total code nerd but if you are a total code nerd, it’s very funny indeed.
• The Web Standards Project follow up their bookmark campaign with hyper-localised social tagging.
• Moo announce the MightyCard.
• The latest World of Warcraft character is the bard with damage effects like “epic solo” and “shoegazer”.
• The BBC show flying penguins.
• And finally, every single featured video on YouTube is a winner today.

These bits of news, on the other hand, are for real:

• Joe launches Captioning Sucks in an attempt to bring sanity and standards to the worlds of film and television. Any garishness you may experience is intentional.
• The good people over at Flickr have resurrected Game Neverending—the game that many years ago served as the genesis for Flickr itself (that’s why you’ll still the .gne extension to this day). The message announcing the resurrection is, of course, very much a joke.

There was one other announcement from Flickr but they managed to get it out right before the dreaded day of foolishness. The site now has a flawless import feature that has completely scrapped the password anti-pattern. Instead they’re using authentication APIs from GMail, Hotmail and Yahoo Mail (that last one is actually a bit of a cheat as Yahoo do not offer any export API for external services).

Needless to say, I’m over the moon about this (although Lachlan is less pleased). First Dopplr, now Flickr. And I’m ashamed to say that I didn’t even put Flickr in the running in the race to do the right thing. Consider me suitably chastised.

Last week Google announced something called the Contacts Data API. This makes me a very happy camper indeed.

I’ve made no secret of my loathing for the password anti-pattern. Asking for a GMail username and password on a third-party website is just plain wrong. I’ve said it before and I’ll say it again: it teaches users how to be phished. I spoke about this at the Social Graph Foo Camp, naming and shaming implementors of the anti-pattern:

Brave representatives from Facebook, Plaxo, Twitter, LinkedIn, Dopplr and Pownce showed up to be named and shamed (though most of the shame was reserved for Google in not providing an API for contacts).

To be honest, the impression I got from Google was that I shouldn’t hold my breath but now that they’ve stepped up to the plate and provided an API, there’s really no excuse for websites to ask users to enter their GMail username and password. The API uses AuthSub now but Kevin announced at SXSW that it will support OAuth at some unspecified future date.

Within 24 hours of the Contact Data API’s release, Dopplr had already removed the username/password form and implemented the handshake authentication instead. Bravo, Matt!

So who’s going to be next? Place your bets now. Here are my nominations for the next contenders:

1. Pownce
2. LinkedIn
3. Digg
4. Twitter
5. Last.fm

C’mon Leah, don’t let me down.

I’m starting to see a pattern. Whenever I bitch and moan about something, it seems to get fixed:

• the search functionality on Upcoming,
• the default behaviour of IE8
• and now this.

I think I might be suffering from some sort of reverse paranoia. The whole world seems to be out to help me.

Update: Well, shame on me for not including Flickr in the list of contestants. They’ve implemented a superb import feature that never once asks for a third-party password. Bravo, Flickrites!

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 Web 2.0 standards. I have no idea what that means but it usually involves tagging, “friends” and gratuitous use of JavaScript. This kind of copycat development isn’t so bad if you’re ripping off a site like Flickr—the more sites like Flickr, the better. The problems start when web apps start replicating bad design patterns as if they were viruses. I want to call attention to the most egregious of these anti-patterns.

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:

• The Flickr authentication API and
• Google’s AuthSub.

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.