In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications . . . → Read More: Time To Criminalize The Password Anti-pattern]]> Update: Twitter made another commitment today to adopting OAuth which is great! However they acknowledge that it won’t solve all problems (like we argue) – nevertheless these are positive steps to us eradicating the password anti-pattern

In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications what search did to information. It has exploded in popularity, and whether they find a revenue model or not – their impact is permanent and is leading the way for a new era of communications. I am one of their biggest fans and want to help them succeed. But I feel with their growth, propelled by loyal users like myself, we ought to let them know there are things that concern us.

The biggest issue is that whilst they enable data portability, they are doing it in an insecure way. As Chris Messina said, lets make 2009 the year we see the end to the password anti-pattern. In this post, I will explain what that anti-pattern is and a way we can fix it. The biggest reason why Twitter is continuiing with this anti-pattern (from my eyes), is because it’s a usability issue. But as you will see me prove below through screenshots, it isn’t. Just think of having a PIN code on your bank card: that’s a usability issue as well, but y’know, one of those good usability issues.

Twitter and Security: all we’ve heard in 2009 so far
Twitter is used to constant free PR, but this year two separate events occurred that could have been non-events (if they do what we ask).

The first was a third-party that provided a feature people wanted. As Twitter has an Application Programming Interface (API), third-party’s can create mashups and therefore provide this functionality to Twitter users. However because Twitter does not support delegated authentication, you need to enter your username and password. There are hundreds of third-party applications like this, and most are safe (we hope), but this particular site within 24 hours had put itself up for sale! And people couldn’t turn off the service – they had to change their password to do so.

The second incident to occur this last week, was an attempted phishing. Apparently, some users were being sent private messages telling them to visit a certain site which compromised their security. It’s ironic that Twitter tells you to not “share your private info” but for you to get value out of their API for mash-ups and third-party tools, that’s exactly what you need to do – and it makes situations like this slightly more risky.

Fortunately, there are things that can be done to minimize the risk of your accounts getting hacked, and for you to never have to give up information about you that will compromise your security.

Delegated authorization
There is a solution to this situation. It’s free to support it, simple to use, and in fact – Twitter’s team inspired its creation the other year. It’s through the use of an Open Standard called OAuth. There is plenty of material you can read on the web about this and a good start is Eran Hammer-Lahav’s explanation of oAuth followed by his three-part series for beginners if you want to dig a little deeper.

The basic concept is that it allows you to delegate authorization for use of an API. Huh?

I’ll illustrate this with an example. Let’s say you come across a Cool Product that allows you to do something unique with your Twitter account (say, being able to stream your Tweets through your e-mail client rather you having to visit the Twitter website). As this Cool Product has no formal links to Twitter, for you to use it, it needs to pretend to be you. Therefore, it asks for your user name and password. It knocks on Twitter’s API door, pretending to be you, and the Cool Product then gets access to your account to do the stuff you want to do with this third-party application. The problem with this approach, however, is that they can knock on Twitter’s door anytime pretending to be you – even when you don’t want them to.

With OAuth, it would be very different. Instead of you needing to provide your username and password, this Cool Product will say “Hey dude, I need to get some permissions – click this link to give it to me”. Then a request will be sent to Twitter’s API and Twitter will send you to a screen saying “hey dude, these third party dudes want access to your account – you cool with that?”. Then, with a simple click of the button, you can approve or deny access. Once approved, the Cool Product can then function – and you didn’t have to give up any private information like your password.

Here are some screen shots between another innovative start-up called FriendFeed and Google (who supports OAuth).

In this scenario, I want to add some more friends on my FriendFeed account. So I click on the option to invite them

When I click on “import from Gmail”, instead of having to type in my username and password to access my contacts, I simply get redirected to a screen. And because I’m permanently logged into my Gmail account, I don’t need to do anything else other than read and click “grant access” (otherwise, I would need to enter my Google credentials).

.

Easy! Compare this to Facebook, another company that needs to think more proactively about its users security. If I want to add friends to my Facebook account, instead of redirecting me to the Google servers where I can grant access, it asks for my password.

Next steps
As people on the web using web services, we’ve been forced to give up confidential information to get the value out of a service. We’ve forced ourselves to be okay with it with the sites we trust, but there are plenty of brands out there we don’t know to trust. But the thing is, this isn’t something we need to trust anyone with. With our health records and financial records accessible online, this isn’t just a matter of reputation risk but one of genuine identity risk.

There is a solution to this problem, and now that you recognize it, demand web services to give you data portability in a secure way. Let’s make 2009 the year that we kill the password anti-pattern. While easier said than done, it’s a fix that will curb some of the security issues: we hope Twitter hurries up in changing their API to require OAuth.

Twitter – we know you’ve been meaning to do it, but hopefully you really mean it this time. Because quite frankly, we as users are fueling your growth and the promotion of your API without some sort of safe-guards like this, is irresponsible (especially as these attacks prove you are going all the more mainstream. I don’t want to tell you how to run your business – it doesn’t have to be OAuth – but for crying out loud, give us some security for our digital identity.

One final Big But
Twitter has strong arguments to not jump onto OAuth, some of which they’ve said publicly and some that I think might be issues. They certainly have a competent team, and whilst they know the benefits, they also understand the fact that jumping onto OAuth or any type of delegated authorization will not fix all problems. However it’s a start. Here are some issues:

1. OAuth is only good for services over web browsers. It is a real pain (or virtually impossible without some hacks) to use it for the client side (ie, on the desktop) and mobile sites – both of which Twitter has a lot of users that use it this way. The response to that is that some security is better than none – it’s not a big deal that users will have to authorize applications via the browser (and Twitter can just point a hairy finger at the standards community so they can fix it). At least give users the option to determine how secure they want to be.
2. Twitter will need to support multiple authentication systems due to the limitations of oAuth. This is a real issue, but not an impossible one to manage, and the community is certainly willing to help out. My main point is that this is actually a security issue that matters, and because the cost is borne by the users and not the company, it’s not given equal recognition.
3. The user experience will suffer for users. Well the reason users will “suffer” is because now, instead of just entering their password, they will now have to click a few buttons on different screens. As the screenshots show above, the user experience is not affected that much and I think while a valid point, it’s more a “different” user experience
4. The user experience will suffer for developers. Yes it will, because instead of the lazy option to just ask users to hand over their password, they actually have to write some code to get the appropriate permissions happening. But this is a core reason why the DataPortability Project supports widely-supported Open Standards, as it minimizes the costs to business: once a developer learns it once, they know it for all future application development.  And like I said above: a bank not puting a code on your bank card, is more painful for your bank, but better that pain than the option without which poses risks for users.
5. It will not prevent phishing.  Lachlan Hardy gives a useful explanation on why (notice all Australians give the best explanations ), as theoretically, people will be more prone to phishing attacks because of the ease. This is a valid point, as people potentially will just blindly click away to their doom, but let’s also remember there will also be a lot more control. A site can monitor suspect services to alert users, there is a full digital paper trail, and a user can revoke their authorization at any time. Certainly a bit of control is better than none, and by reducing the weak spots in the chain, more targeted efforts can be made to ensure users’ security is no compromised.

The data portability Landscape Diagram

2008 was called “The year . . . → Read More: The data portability Landscape – An update]]> Given the recent intense activity around data portability (Announcements from Facebook, Google, Twitter, Yahoo etc) and the impending end of the year, I thought it opportune to summarize the data portability landscape from my personal perspective and the perspective of the DataPortability Project.

The data portability Landscape Diagram

2008 was called “The year of Data Portability”. In many ways, that prediction was very true.

Above is a diagram of the data portability ecosystem in so far as it relates to Google Friend Connect, Facebook Connect, the DataPortability Project and the Open Stack.

1. data portability (the general idea)

The idea of data portability, in general, has emerged to mean the ability to reuse data between services in some shape or form. It may be a one off implementation between two services, a proprietary universal login play or an open standards attempt at interoperability.

2. Participating Sites

Sites that participate in providing and/or receiving data. They do this with the authority and permission of their end users.

3. DataPortability (Specific Idea)

The specific notion of DataPortability as defined by the DataPortability project is as follows:

Vision
Data portability enables a borderless experience, where people can move easily between network services, reusing data they provide while controlling their privacy and respecting the privacy of others.

For the user
With data portability, you can bring your identity, friends, conversations, files and histories with you, without having to manually add them to each new service. Each of the services you use can draw on this information relevant to the context. As your experiences accumulate and you add or change data, this information will update on other sites and services if you permit it, without having to revisit others to re-enter it.

For the Service Provider
With cross-system data access, interoperability, and portability, people can bring their identities, friends, conversations, files, and histories with them to your service, cutting down on the need for form-filling which can drive people away. With minimal effort on the part of new customers, you can tailor services to suit them. When your customers browse networked services and accumulate experiences, this information can update on your service, if people permit it. Your relationship remains up-to-date and you can adapt your services in response, even when they don’t visit. With mutual control and mutual benefit, your relationships remain relevant, encouraging continued usage.

Data portability is a new approach, where it is easier to use and deliver services. This frictionless movement through the network of services fosters stronger relationships between people and services providers and helps build a healthy networked ecosystem.

Mission
To help people to use and protect the data they create on networked services, and to advocate for compliance with the values of DataPortability.

The most important notion in that entire section is ‘Interoperability’. I’ve highlighted it in red and made it bold. Interoperability means that irrespective of who is providing or receiving the data, it should be provided in such a way that is agreed upon by the community so that the implementation is consistent irrespective of parties participating in the transaction.

Sound unrealistic? The Web is already such a system. Any web browser can request a HTML document using HTTP. It does this over TCP/IP. It sometimes uses SSL.

FTP, IRC, Email, Newsgroups, WiFi – all follow a similar pattern. These protocols are owned are not owned by companies. If they were we would have a very different Internet today. Vendors, however, innovate on top of these technologies to create Browsers, FTP clients, IRC Clients, Email Clients, Laptops and so much more.

4. DataPortability Project

The DataPortability project is the project that turned the nascent standards conversation into a full fledged riot in January of 2008.

The project is responsible for defining ‘DataPortability’, advocating its adoption by developers, explaining its value to business executives, promoting its usage to end-users and providing context and commentary on  industry news as it unfolds.

The project does not create technology or software products. It evaluates the technology and products of others provides advice to the community about its compliance (or non compliance) to the core goal of interoperable data interchange.

In essence, The DataPortability Project is the ‘Spread FIrefox’ of the standards community.

5. Tools (Google Friend Connect, JanRain RPX, Others)

Perhaps where the most innovation potential exists is in the tools layer.

Current tools have made good faith efforts to provide DataPortability complaint services to site owners. Because the specific implementation guidelines are still emerging, there is still some way to go to ensure that all the tools provide a consistent programming interface.

Current tools also act to bridge the gap by turning non-compliant systems (e.g. Systems that don’t use Open Stack) into more standards compliant end-points.

It is hoped that all services begin to implement their own standards compliance to limit the need for tools to act as gatekeepers. Tools will still be necessary, however, to provide a plethora of value-added services. These services, however, should never break the interoperability promise of ‘DataPortability’.

6. The Open Stack

These are the core open standards based technologies that make Interoperable DataPortability possible. Some have been created by formal and official standards bodies, others by ad-hoc community efforts. Some are protected by the W3C, others by the Open Web Foundation. All, represent a piece of work that is freely available, generally agreed upon and open for use by all.

7. Facebook Connect

Facebook connect is a version of ‘data portability’ (Point 1). It allows an elegant and simple re-use of data between Facebook and other services. Rather than being based on the Open Stack (Point 6), it is based on Facebooks Proprietary Platform (Item 8 on the diagram).

The key point here, however, is that Facebook Connect is owned by Facebook. Rather than interoperable point to point ‘DataPortability’ as defined by the DataPortability project, it provides a hub and spoke model where the technology and the experience is owned by a private company.

So far Facebook Connect is the best implementation of data portability available in the wild. It offers a compelling business value (millions of ready and active users) and simple APIs.

The community, via the many pieces loosely joined detailed in point 1-6, must come together to create a cohesive value proposition of its own in order to compete with this proprietary model.

Compete we must, however. Facebook, like AOL and Microsoft Passport before it, must eventually participate in the Open Web. Because the web is, and always will be, bigger than any single company.

The Future

Closed platforms are like ice cubes in a glass of water. They will float for a while. They will change the temperature of the liquid beneath. Ultimately, however, the ice cube must eventually melt into the wider web.

Facebook’s success with Facebook Connect can and will further drive innovation in the community to develop an open alternative.

Facebook’s success will also drive large media companies, competitors (like Google, Microsoft and Yahoo, AOL, Myspace, countless major media properties and countless small startups) to create alternatives. At least some of those participants will recognize (if they have not already) that the most open among them will earn both the respect and the market share of the next phase. Moving from Facebook Connect’s ‘data portability’ to Interoperable DataPortability.

A web of Data.

That’s a landscape where we can continue to innovate on a level playing field.