OpenID Foundation Finally Grabs @openid Twitter Account

The OpenID protocol, aimed to authenticate users in a decentralized way, helping individuals own their own identities instead of requiring unique accounts for every service, has had something of an ironic issue for some time - given that the OpenID Foundation didn't actually own their own ID for one of the more popular discussion forums out there - Twitter. Today, this issue can be put to rest as Facebook employee and open source advocate David Recordon announced this afternoon they had gained access to the @openid account - giving folks a central place to keep tabs on updates to the protocol.

While OpenID at times has been pilloried for being obtuse, making logins more complicated rather than less, the project has helped push the concept of decentralized identities away from individual domains, including last week's news that Flickr had adopted the standard. The protocol, developed by now Google employee Brad Fitzpatrick in 2005, while at Six Apart, has seen deployment at a significant and influential number of Web services, and has corporate members including Facebook, Google, IBM, Microsoft, PayPal and Yahoo! on the foundation's board of directors. Ironically, nobody from Twitter is involved on the board.

The release of the account may or may not have been related to yesterday's OpenID OAuth Summit, held at Facebook headquarters, which saw stakeholders from a variety of tech companies, including Kevin Marks of BT, Chris Messina and Joseph Smarr of Google and Tantek Çelik, computer scientist at Microformats.org, participate to potentially discuss the differences between the at times complimentary but competing formats. Also, the Internet Identity Workshop (IIW) kicks off today in Mountain View, where many of these same folks will be participating.

Debate on OpenID versus OAuth continues to rage on the Web, of course. Recent entries include the Halloween post on Codebase: OpenID OR OAuth – That is the Question. Regardless of the eventual resolution, proposed as a new agreement called OpenID Connect, adoption of open standards and reduced complexity is a good thing. You can now follow OpenID's happenings at @openid.

Designing Buzz for a Google-Free World

If you haven't seen a lot of applications built in the last few weeks that leverage the Google Buzz API, it's because there aren't any. In fact, Google hasn't yet rolled out any API for Buzz. According to the company, this isn't due to any backroom dealings where they plan to introduce proprietary code and hooks that tie activity to their platform, but instead, because they wanted to be sure they could first build a product that in fullness leveraged open Web standards, and start with that foundation to deliver an interoperable system that could continue to function even if Google were to "disappear off the face of the earth".

In a presentation to the Silicon Valley Google Technology Users Group last night, held at the Google campus, DeWitt Clinton, a software engineer for the company, talked to developers and other tech enthusiasts about the company's API strategy and approach to Buzz, and explained that Buzz is designed not to increase lock-in to Google, but instead, to leverage open technologies that will let data flow to and from sites without central ownership. While a Buzz API will eventually be released, it will leverage the same open standards that power it today.

"The first principle of Buzz is that we can build this on protocols that are open and free, but not centralized," DeWitt said. "Can Google disappear off the face of the earth and Buzz still works? We need to make this data federated and distributed."

On the day Buzz launched, I referenced much of the foundation for Buzz in a quick article about the open tools and APIs that "make Buzz hum". But last night, DeWitt expanded that story to include 9 major open APIs, briefly outlined below.

1. Atom

DeWitt called Atom "the lingua franca of the programmable Web today", explaining that Atom contains entries that are "well structured", and include source entry, GUIDs that enable deduplication, and specification of the content type. He said, "You are able to pass rich data in that Atom feed in a way that is more specific than other feed types."

2. AtomPub

DeWitt said AtomPub "has become the most popular paradigm for restful APIs on the Web." AtomPub expanded the original Atom format to include the ability to both create and update feeds, not just passively read.

3. ActivityStreams

ActivityStreams essentially watch users' activity and can specify rich verbs and actions within those feeds. This enables feeds for all comments posted on Buzz, all likes, or even alerts that one person following you on Buzz also follows you on another network. DeWitt's examples hint at future developments for the platform, as these specific feeds are not yet clearly visible.

4. Pubsubhubbub

Much discussed here on the blog, Pubsubhubbub reduces the need for sites to poll for updates, and powers real-time updates between services. DeWitt reiterated "the hub is decided on by the publisher" and "there is nothing Google-specific about that.", saying that the infrastructure and plumbing for Buzz has been laid for the last few years. Pubsubhubbub has been pioneered by Brad Fitzpatrick and Brett Slatkin, both Google employees.

5. MediaRSS

Developed by Flickr, MediaRSS syndicates rich media through both RSS and atom feeds, creating a structured namespace inside RSS for content and a thumbnail. Buzz leverages MediaRSS, letting you pull rich content, like Flickr photos, into the platform. Of course, PicasaWeb, a Google property, also supports MediaRSS.

6. OAuth

The product of engineers from all corners, including Twitter, OAuth was engineered "to solve a vexing problem in the industry," Dewitt said, explaining OAuth prevents the need to ask users for their name and passwords on third party sites, acting as a delegated authorization protocol that gives permission to the application. Google Buzz, like Twitter, leverages OAuth to provide authenticated access to your data.

7. WebFinger

A new-age version of the old command-line prompted, text responding Finger protocol, WebFinger aims to be a way to get public information tied to an individual, through their identity, assigned to an e-mail address. "We want people to identify themselves, and we want people to discover people," DeWitt said.

WebFinger is similar to the strategy of OpenID, but OpenID hasn't had massive adoption by end-users who have found it unwieldy. WebFinger, aiming to be less arcane, enables the independent nature of Buzz, helping to federate the data and distribute it by domain, owned by the end user. DeWitt said, "The profile lookup and notification mechanism can be in the hands of the user being addressed."

8. Salmon

Still in earliest stages of development, Salmon is an extension or replacement for the old PingBack model that had blogs informing the other about references or links. This "flawed" model only provided minimal data, and could not be verified, letting me send PingBacks anywhere I wish if I chose. Salmon's goal is to leverage what's being called "Magic Signatures", signed with a public key to prove and verify linkage.

The first approach for Salmon will be to migrate comments from aggregators to originating posts, as covered a few times on this blog. But DeWitt said that "Likes" are similar activities that could flow back with Salmon, or be used to notify users of "following" or other activity. DeWitt forecast that sites like Blogger and StatusNet would rapidly adopt and federate Salmon to transmit data updates.

9. Portable Contacts

Simply described, Portable Contacts show your information and that of the friends who you follow, providing users a secure way to get access to address books and friends lists without having to request credentials or scrape the data.

DeWitt also noted XFN, the XHTML Friend Network, and FOAF (Friend Of a Friend) as being key contributors to the Buzz technology stack today, adding that he was "glad smart people were working on this ten years ago because we are all benefiting from it now."

DeWitt, on his Buzz feed, has been talking a lot about open standards and their importance to the Google team at large. See @Jesse Stay A few points of clarification to your most recent post [1], because I believe getting the details right matters. and "The thing I find most attractive about Google Buzz is its stated commitment to open standards.", as well as his first post from February 21st, which thanked the standard developers: Standing on the shoulders of giants—a look at the people behind the protocols behind Google Buzz:

Given Google's size, there is a good amount of distrust on the Web from people who think they own too much of your data, know too much about you, or have goals that run contrary to your own ideals on privacy, communication and sharing. Not even DeWitt's detailed presentations and explanations and promises of openness and data portability will convince everyone that they are on the right path. But I personally believe the frankness and detail that is being shown here is not just promising a strong future for this individual product (Buzz), but also in extending the groundwork done for the entire Web, for products and services we haven't even seen yet.

DeWitt adds: "All of these protocols are open. They are literally also all free. They are intended to be used by everybody, with or without Google being involved. You don't have to ask us if you can use Salmon or Pubsubhububb. We have a liberal and permissive patent license."

Is Google going away? Not today, and not this year. Is Buzz perfect? No. Of course not. Can it do all the things I can do on other sites, like FriendFeed? No. Not yet. But it seems that the Buzz team has opted to make tradeoffs that favor fast shipping and openness over completeness and individual features. And if you don't trust Google, it sounds like you can do something about it.

"We are pretty adamant about not building this on proprietary technology," DeWitt said last night. "If any of you feel that it is not going in the right direction, you have the power to change its direction and Google will not stop you."

You can find me on Buzz here and can follow DeWitt Clinton on Buzz here.

Open Identity Exchange Proposes Identity Trust Framework

Today, at the RSA conference, the Open Identity Exchange (OIX), aimed to increase trust in online identities, and backed by the OpenID and Information Card Foundations, announced its inception. In parallel, the U.S. Government is recognizing multiple technology companies as meeting federal standards for identity assurance, including Google, PayPal and Equifax, essentially securing users' ability to register and log in at federal Web sites with credentials from each of those services.

Goals of the Open Identity Exchange include building online users' trust and confidence in the exchange of identity credentials, standardizing these interactions and reducing hassle with online logins, registrations and purchases. As practically any Web user knows, frustrations with remembering scads of online user names and passwords, each corresponding with different sites with varying trust levels, can be a complete pain - no matter how much effort is taken to standardize, and the alternative, keeping one password for multiple services, which many do, has many more problems of its own.

OIX and its members are looking to reduce the problems with today's Web and move toward further highlighting open standards. Founding members of OIX, a non-profit corporation, include Booz Allen Hamilton, CA, Equifax, Google, PayPal, Verisign and Verizon.

The Often Complicated Process of Assessing Trusted Identity Online

Google's participation in the exchange follows the company's hirings of some of the more vocal advocates of OpenID and the open movement in general, including Chris Messina and Joseph Smarr. Earlier this week, a Google spokesperson wrote by e-mail that the inclusion of the company as part of OIX's launch should not come as much of a surprise.

"As you probably know, Google has long supported and contributed to the development of identity standards such as OpenID and OAuth, largely in order to increase online security by reducing the reliance on password use across websites." they wrote.

A white paper on the new OIX Web site, entitled "An Open Market Solution for Online Identity Assurance", explains how open identity technologies, including OpenID and Information Cards, serve to take closed user name and password systems deployed by most Web sites and expand them to accept identities issued by other parties, such as Google, PayPal and Equifax. Much of the paper, and OIX's mission, centers around the issues surrounding identity, including social, business, legal and emotional, such as trust.

This model of trust is explained in a second piece which defines a new "Open Identity Trust Framework (OITF)". The OITF paper shows holes in today's trust frameworks, and questions how people passing along personally identifiable information can be sure their data is protected with acceptable technical, operational and legal safeguards, while proposing a structured role for policymakers, providers, assessors, auditors, and dispute resolvers, to be sure that all participants are acting in a trusted manner. It may seem overly bureaucratic, but considering the Federal government needs to accept its findings, process is a good thing.

Lest you think this just yet another association or bureaucracy with talking heads looking to grease the skids of online growth, see the conclusion of the OITF model paper, where the authors explain a data utopia: "
Imagine 
that 
the 
OITF 
model
 takes
 off
 and
 identity 
aspects
 of 
all 
digital 
communications 
become
 reliant 
on 
this 
new
 layer 
of 
the
 Internet. 
Society 
could 
become
 dependent 
on 
this 
type 
of 
infrastructure 
for
collective 
action. 
The 
authors
 want
 to
 make
 it 
clear
 that 
trust 
frameworks
 for 
identity 
information 
portend 
to 
be
 so
 important 
for 
the
 future 
information 
society 
that
 they
 warrant 
extensive 
scrutiny, 
participation, 
and
feedback
 from
 a
 wide
 representation 
of 
stakeholders.
"

You can find out more on this new exchange at http://openidentityexchange.org. In addition, Google posted on the announcement on the company's online security blog: Federal Support for Federated Login

Twitter Maturation Continues As They Embrace Developers

As Twitter grows from early adopter curiosity to full-fledged mainstream phenomenon, the company is undergoing a much-anticipated and much-welcomed maturation process, one that comes following the company's highly-visible raise of a significant venture capital round, which valued them at a billion dollars, the hiring of well-respected team members from Valley titans Yahoo!, Google and Facebook, and the recent roll-out of new features to the platform, including Retweets and Lists. Today, at LeWeb, Ryan Sarver, Twitter's director of platform, unveiled even more proofpoints that show the company is moving beyond its shaky relationships with developers (and uptime) and looking forward to a more public, more robust experience.

Over the last two years, some of my more public criticisms of the service have centered around the company's struggles with uptime, and lack of transparency with developers, who often got short shrift as Twitter worked to keep its products stable, throttling API access or changing functionality, often with no warning. The results, in some cases, were drastic, leading to products being delayed, canceled, or simply rendered ineffective.

Keep A Close Eye on Chris Messina for the Web's Future

There are a few people in the Web whose work I can't help but watch with significant interest, as I know they are among the more visible people, working in teams with lesser-known colleagues, focusing their effort on moving the Web forward. From DeWitt Clinton, Brett Slatkin, Brad Fitzpatrick, Chris Saad, Dave Winer and David Recordon, to people like Jason Shellen, Chris Wetherell, Kevin Marks, Leah Culver, Paul Buchheit, Bret Taylor and Chris Messina, to name two handfuls, I can believe that these folks are working on those projects that are shaping the way we communicate and take in information. Messina, in particular, has penned a few blog posts over the last month that have had us thinking quite a bit - and it is safe to say he is on a roll.

Chris, in November alone, has proposed a new microsyntax for Twitter, forecast the death of the URL, and talked about how "designing for the gut" takes advantage of how the new social Web pushes people to overcome phobias and connect with people.

A well known advocate for open source, and one of the voices behind OAuth, which we discussed on Thursday, Messina has a history of thinking beyond where we are today and proposing concrete ideas that can be acted upon immediately. Those hashtags you see everywhere on Twitter these days, in practically every tech event and many trending topics? Chris proposed the idea in August of 2007. So it makes sense that he might have given a ton of thought to more uses for microsyntax, as he describes in his proposals for Twitter, as he suggests new items, including "/by", "/via" and "/cc". These suggestions are very clear and concise, the work of someone who has done his homework.

Chris' thoughts on the reduced focus on the URL too are salient, as we become more used to navigating in our browsers with pre-determined buttons and workflows. For me, URLs are often simply one-time visits before they are thrown into my RSS reader for safe-keeping, or they become bookmarks for later clicking. But the act of typing in a URL character by character seems antiquated. As he says, that's a gut feeling, and not one backed by much science on my part.

As I see it, the social Web changes the entire process of content discovery. Instead of portals, we are relying on mortals. Our trusted friends and experts bring us the best content from around the Web to us directly, via Facebook, Twitter, FriendFeed, and even that old tool... e-mail. We are trusting human filters to select the best from our RSS repositories and hand it off downstream. We pick a handful of trusted favorites, and make them the equivalent of our Yahoo!, or even Google.

Chris' post on the death of URLs paints a not so pretty picture of how, if left uncontrolled, a few powerful companies could help funnel the majority of users to predetermined sites, hand selected by them - much like the fears we once had about dominant portals. This could be done as we graduate from the traditional browser and link model to something else, where Web-connected applications pass us the requested data. He says, "We all know that the internet has won as the transport medium for all data — but the universal interface for interacting with the web? — well, that battle is just now getting underway."

One thing about the Web is that it is ever evolving. The places we choose to communicate are changing. The information we think provides value is changing. Our requirements for how quickly we need the data are changing. Chris and the many folks I mentioned in the first paragraph are among the first line of defense we have, trying to set standards and promote change for a world that feels right from both the gut and from the mind. You can find Chris' writing over at http://factoryjoe.com/blog/ or on Twitter at @chrismessina. While I assume many of you read him religiously, it's time the rest of you did as well.

Is There a Looming Battle Over OAuth's Successor?

The OAuth protocol, used on many popular Web sites and applications to pass your credentials between sites without requiring the entry of your user name and password, including Twitter, is potentially under pressure from a team of techies representing Microsoft, Google and Yahoo!, who have introduced a competing specification interpreted as being aimed to succeed OAuth, called Web Resource Authorization Protocol, or WRAP. Eran Hammer-Lahav, the Director of Standards Development at Yahoo!, who helped coordinate many OAuth contributions, and created a formal specification for the initial OAuth standard, recently panned the move, saying, "The road to hell is paved with good intentions," adding his own proposal for OAuth 2.0, which he hopes will better separate between authentication and authorization.

Today's OAuth standard is known to have its imperfections. Hammer-Lahav notes in his 2.0 proposal that OAuth is essentially "unusable" for mobile devices or installed apps, and also suggests that OAuth "does not adequately support large providers". But he says the move to create WRAP has confused developers' focus, and diverted resources, calling it "just one illustration of the demise of the OAuth community".

But his opinion, unsurprisingly, is not universally accepted. David Recordon of Facebook, also on the boards of the OpenID and Open Web Foundations, states in the comments of the post that Facebook is not supporting OAuth 1.0 as it is simply too heavy - requiring a massive increase in HTTP requests, also adding that other developers find OAuth "too difficult to correctly implement".

David followed on to his initial comments with a post to the IETF mailing list, which you can see here: Facebook, OAuth, and WRAP. In the note, he highlights the belief that the proposed WRAP alternative maps well to the company's current authentication process, adding WRAP simplifies the development community's learning curve.

The discussion, which is ongoing, may end up splintering development communities between sticking with the current version of OAuth 1.0, looking at WRAP as an alternative, or trying to support a new OAuth 2.0, as specified by Hammer-Lahav. But if you have wondered why Facebook Connect acts one way and Twitter OAuth acts another way, it's because they are different approaches entirely. If this discussion is any indication, one can expect there to be continued divergence, rather than a single way to deliver user authentication and authority between sites and applications in the future on the Web.

For another viewpoint on this broad topic, see Jesse Stay's post: The Future Has No Log In Button. Also, DeWitt Clinton of Google, on FriendFeed, says the open discussion "is good".

Progress Being Made On Twitter's Network After 10 Days of Attacks

After an initial wave of attacks brought the popular micromessaging service to a standstill, as well as a host of other social networking sites, on August 7th, the Twitter team has been fighting to turn the tide and restore access for the service's customers and developers to near-normalcy. Ten days into the attacks, they have not disappeared, according to postings from Twitter, but it looks like the company may have turned a corner in dealing with the additional stress from the distributed denial of service.

In a post to the company's Twitter Development Talk forum titled "Platform Status Update" entered at 4:30 this afternoon, Twitter's Ryan Sarver said:

"Over the past ten days we have been dealing with a lot of stress on our network and that has caused a number of our partners to be knocked offline for extended periods of time. This is obviously not something we want to happen and the platform and ops teams have been working hard throughout that time to address the needs of our ecosystem while protecting the system as a whole. We have made some great progress today in tuning the system to a point that should allow our partners to operate as they were before the recent issue began."

He added "the system is still under stress", and asked developers who might be continuing to have issues to work with them and provide information around what IP addresses their machines use to access the Twitter API, the method they are using to make requests, and any other information - including data as granular as their host operating system, browser, cookies and network connection.

Ryan's comments followed a note from earlier in the afternoon by Alex Payne, the company's platorm lead, where he also said the company continues to "fend off" the attack, saying that without specifics from developers (like those listed by Ryan), they could not adequately troubleshoot any issues.

While the majority of Twitter users are not experiencing the widespread outages that we saw a week and a half ago, it is still not uncommon for applications utilizing the Twitter API, and specifically OAuth, to see failures. There's also no doubt the ongoing attacks have led to a fair share of fail whale sightings. (I've encountered a few myself) Twitter posted a note to the company's status blog Sunday acknowledging the problems, and said they are "working to resolve it".

It has been tempting at times to poke at Twitter for its struggles during this period, but as I mentioned on August 7th, when the troubles first arose, the company is being much more visible and fast to respond to developers and to provide status, as they show signs of maturing. Their operations teams look to have been busy around the clock for the last two weeks, and they will need to keep fighting - as it looks like this battle may go on for some time.

Twitter Announces OAuth Details, Hints At App Directory

By Jesse Stay of Stay N' Alive (Twitter/FriendFeed)

In an announcement on the Twitter developers mailing list today, Matt Sanford, a developer at Twitter who has been leading the efforts to integrate Twitter API with OAuth, announced details on how the new OAuth would work. In the announcement, he released a preview of documentation for the new OAuth methods, how developers would integrate using a sample Ruby on Rails application, and what developers would need to know to integrate.

Interestingly, the documentation also hints at other plans in Twitter's future as well. For instance, Sanford suggests users will be able to see what applications they have given access to and revoke that access. He also hints at a future catalog of applications and opportunity for developers registered within the API to be a part of that Catalog.

Announcement of such a catalog and authorization process has been speculated on for quite awhile now. It was mentioned as a possibility when I visited Twitter with Robert Scoble about a year ago. So seeing Twitter's plans to stick towards this path and continue towards this goal is welcome news to say the least. Also mentioned in the documentation is the suggestion that the basic auth API Twitter is using today will eventually be phased out.

Twitter plans to release the OAuth API to developers that are participating in the closed beta "by next week", and they have not announced a date it will open to the public yet. However with increased pressure to have better control over the applications that run on Twitter you can bet Twitter is now putting top priority on this particular issue.

Read more by Jesse Stay at Stay N' Alive.

Hey Twitter, It's Not Just a Worm, It's an App

By Jesse Stay of Stay N' Alive (Twitter/FriendFeed)

There's no doubt that the worm making its rounds on Twitter is a nuisance and a huge problem for all. The fact of the matter is, somebody has collected your usernames and passwords, and many of your accounts are now Zombies, spamming each friend on your friends list through direct message, turning more unsuspecting accounts into zombies, and spreading like wildfire. Louis has talked about the worm which has surfaced on Twitter, and the urgency of the situation and potential implications for OAuth and security for Microblogging.

I suggested plain text passwords could be to blame - after all, any application out there that collects your usernames and passwords could theoretically use those passwords to start such a worm, in order to gain access to people with similar bank account passwords and more. That would be the fastest way over, say, a single user trying to amass friends to dm. We're already seeing several of those compromised accounts sending iphone-related spam, so it would appear the worm developers could now be monetizing this, through your friends. At the same time, I keep seeing others criticizing the possibility that OAuth could have prevented this. I'd like to share my thoughts why.

Disclaimer

First of all, let me preface this with the fact that I am not a security expert. I have been developing software since I was 10 (I am now 31), and have plenty of real-world experience writing secure software. I've worked in health organizations requiring software to respect privacy around your health data, with e-commerce protecting your money, and I've written APIs. I understand what it takes to keep software safe. I also run my own business in which I also have to protect my users' data. I also understand that nothing's perfect. While security has not been my sole focus, I hope I can at least make some sense of the matter.

First Things First - This is an App

Let's set things straight here. Now, I could be wrong, but all evidence seems to suggest that this "worm" is actually an application, or possibly multiple applications, running on multiple servers around the world (the IP range also suggests that the same developers have targeted YouTube and Bebo in the past). After all, the only other way to log in on behalf of users and DM others would be to screen-scrape Twitter, simulating a user actually logging in via the Twitter.com interface. This is possible, but I would imagine we would see Twitter very quickly implementing some form of Captcha to slow it down. We haven't seen this yet so the most logical conclusion is that someone has written an App somewhere, which is taking advantage of the fact that you can login via plain text usernames and passwords. The same application is taking those usernames and passwords, and programmatically logging in on behalf of each compromised user and direct messaging their friends to collect more usernames and passwords.

Currently, the Twitter API makes it completely possible for anyone with your username and password to log in on your behalf, programmatically. Essentially, Twitter has given developers the key, and all keys open up the same lock. The only way to shut this down would be to kill the lock, which would shut off all developers. This is why the topic of OAuth continues to be brought up - to start off, OAuth forces any developer to use a protected key or token in order to log in on behalf of the user. The developer never has the user's username or password. The user himself keeps their own keys to Twitter without having to give a copy of those keys to developers.

It's not that simple though.

Why They're Saying OAuth Wouldn't Have Fixed the Problem

Assuming Twitter had implemented OAuth, let's assume no developer has your username or password and your information now feels secure. There is still nothing stopping those users from using those tokens to log in on your behalf. Essentially, while the developer couldn't screen scrape your data to log you in through Twitter with such a key, they could still use the API, just as these current Phishers are probably doing, to continue to send DMs and messages on your behalf. An OAuth token is just like another username and password essentially, intended just for API use.

The other criticism they're giving OAuth is that it still doesn't stop the Phishing. When the end-user authenticates through an OAuth-enabled website, they are taken back to a page on the originating site that, if they aren't logged in, asks them to log in, and that site in turn returns them back to the third party site with an OAuth token that can be used for access. Nice and simple, right? Well, the problem (which I've only seen theorized, but it is definitely possible) is that any third-party developer could create an app that redirects the user back to a page that just looks like the originating site (like Twitter.com, for instance), and pretends the user isn't logged in. The site could then collect the username and passwords of unsuspecting users, just as the current phishing scheme is doing now. The potential is still there to collect usernames and passwords, just as before.

The Advantage People Keep Forgetting

Let's ignore the last paragraph and just focus on the one before it. Even though an application can easily login on behalf of the user via the API, with OAuth, a site like Twitter now has full control over each and every application that runs on the API. OAuth has controls which allow API providers like Twitter to cut off any application using the API. So, assuming Twitter sets up some sort of manual approval process similar to Facebook's (I suggested this to Ev and Biz in the interview I attended with Scoble last year (end of the article), and they said they were working on this) to weed out the sketchy applications, it becomes much easier to just cut off the offending application. They now have record of the exact application sending these DMs, and can cut it off immediately. Currently, they're stuck chasing IP addresses, and trying to block various IP ranges, which are tough to block and easy to switch.

Back to the Problem

So, let's assume Twitter had implemented OAuth. We now have two possible scenarios: Scenario 1, said Phisher signs up to have an app on the API (or buys an app like Twply), and sends out DMs on behalf of users. (Note that the Phisher couldn't start as an individual and collect usernames and passwords in the manner this Phisher did in the current scenario because they couldn't send plain-text usernames and passwords via the API) The Phisher gets users' friends to login via OAuth, he collects the tokens to send out DMs on behalf of other users. Twitter's in-house alarms go off of such activity. Twitter shuts down said Phisher in a matter of minutes, and only a few people even see the worm.

Scenario 2 is a little more difficult, but less motivational for a Phisher on a site like Twitter. In this scenario, a Phisher creates a fake 3rd party app, accumulates a lot of followers somehow, and gets users to somehow think they are going to Twitter to login, and they collect the users plain-text usernames and passwords. The said Phisher can't do anything through the API, because it doesn't allow plain-text usernames and passwords. All they can do with it is screen-scrape Twitter, login on behalf of the user, and go about it that way. They also have to accumulate a decent sized following.

First, let's face it, there's not a ton of information that's not already public a Phisher can gather on such a site as Twitter, other than their username and password, which could also be used on other sites like banking sites. I really think most of these Phishers are more interested in spamming you, trying to make a quick buck off the unsuspecting sending spam to their friends (like the iPhone example above) - selling the data to spammers I'm certain is big bucks (at least $1,200, according to the sale of Twtply). Second, Twitter could easily implement a captcha system in such a case, and by that means they could at least slow down the Phisher or spammer. At that point, if the Phisher or Spammer is still diligent enough to get through, they have a much more controlled system, and they can then play the IP blocking game. Let's face it though - this isn't a banking site, usernames and passwords only go for a meager $1,200 from what we know, so most spammers ought to give up at that point. It's much less of a problem, and much easier of a problem to deal with than what Twitter is seeing now.

The Purpose of Security is to Make it Harder

As I said earlier, no security plan is a perfect plan, but the harder it is for a perpetrator to get through a system, the more secure that system is. Currently, there is no barrier between Twitter and those than can potentially misuse your usernames and passwords, other than you. As I said earlier, Twitter has only one lock for each user, and each developer you share your information with has the same key to that lock as you do.

However, despite the continued risk for phishing OAuth poses, as Lachlan Hardy suggests at the end of his piece here, it is still a step in the right direction, and I think would have prevented this particular worm. OAuth would have given Twitter the capability to revoke the keys of the offending phishers, enabling them to shut the worm down when it happened. After all, this isn't just a worm, it's an app, using the API, like any other developer, but in this case to spread malicious websites. I want to suggest that Twitter stop skirting around this issue, stop pretending OAuth wouldn't have solved the problem, and just implement something, quick.

Read more by Jesse Stay at Stay N' Alive.

Twitter's OAuth Target Slipping Amid Increased Security Pressures

Over the weekend, more than one exploit, sent by way of Twitter's Direct Message feature, has made it around the Web. As Twitter's growth has continued, the microblogging service looks to be a new domain for scammers and spammers, previously contained to traditional e-mail. And as the shenanigans gain in momentum, so too does the call for Twitter to implement OAuth, the open protocol that allows for secure API authorization, which has become popular among many Web tools in use today. But Twitter employees' postings in the service's development group, and their own notifications on the site, show a shifting roadmap, while they also try to divert criticsm by separating the need for OAuth from the weekend's incidents.


An example of one Twitter phishing attempt.
Twitter's success has seen a groundswell of applications being developed that require users to enter their user name and password on third party sites. Given Twitter's lack of OAuth support, Twitter users have grown used to posting their data whenever they are asked, and in the rare case a site has been found to malicious, it forces them to once again change their passwords to protect their account.

The OAuth Web site spells out the reason behind the project's development, saying: "If you're storing protected data on your users' behalf, they shouldn't be spreading their passwords around the web to get access to it."

The weekend's activity featured a mock Twitter login page, where users were prompted to enter their credentials. (See: CNet: Twitter phishing scam may be spreading) While this specific attack would not have been solved by OAuth, but instead by users simply paying attention to where they were logging in, you can see Twitter's attitude on the current process.

Alex Payne, a lead developer of Twitter told one user on Saturday: "Right now, you can't see which apps are using your requests. You can change your password, though.", and later told another user, "We're trying to discourage against clicking on the link." Pretty basic stuff.

When pressed on whether Twitter was going to implement OAuth, and reduce users' growing too comfortable with posting their passwords everywhere, Alex said, "OAuth isn't a panacea against phishing and other web security issues. We're still going to support it," and following on, echoed the OAuth site by saying, "A main benefit is that OAuth limits the scope of activities that can be done with a user's credentials," while also linking to a post from April of 2008 that showed how phishing scams could not be stopped by OAuth. See: Phishing Fools?

So, we get that the phishing problem won't get solved through adding OAuth, but we do see more and more applications getting your password. As the New Year came in, Twply managed to get many passwords, and then was sold the same day. (See: Scobleizer: Twitter spam, effective or idiotic?)

Alex mentioned Twitter is going to support OAuth. But when?

In the Twitter Development Talk forum, you can see the target continues to move.

Alex, on November 24th of last year, wrote: "We're currently waiting on our User Experience team to put the final touches on a BETA release of our OAuth support. It's going to have bugs, to be sure, but we should have it out there soon. "

On November 26th, after being pressed for a date, he said, "As I don't know the entire schedule of our UX team, I can't. I would say less than a month and closer to a week by far, but please don't hold me to that."

On December 8th, Alex gave more specific timing: "It won't be available for testing this week, but should be available before the end of the month. I'd definitely encourage you not to launch on it, though, as it will be a beta."

Now more than a month from the first comment, amidst more developer pressure, Alex says the next major version of the API will be OAuth-only, but deflects some of the criticism by pointing fingers at other services that have not yet jumped on the OAuth bandwagon.

This afternoon, January 4th, Alex said:

"Of course, once we offer OAuth, it would be nice to see the same community pressure that's been applied to us put towards companies like Amazon. The Amazon.com iPhone app collects my username and password, and that account is actually tied to my credit card information. Where are the blog posts about their anti-patterns?"

Now, there's no question I'm no security expert. Don't forget that on November 12th, I once wrote, Twitterank Can Have My Password, No Questions Asked, and Alex looks to be feeling the strain of other non-experts, like me, pushing the team to get more robust. He commented on Twitter this evening, "It doesn't help that web folks generally have next to zero security/crypto education," a bucket I'm no doubt in.

The groundswell of demand on Twitter to improve its security measures, to get to OAuth as quickly as possible has no doubt reached a crescendo in the wake of this week's exploits - both those solvable by the project and those that are merely phishing scams. But it looks like Twitter developers' confidence has been shaken by so many promises being out there, and the deadline continuing to move.

Five Ways OpenID Can Be Embraced

By Mona Nomura of Pixel Bits (FriendFeed/Twitter)

Attempting to learn OpenID for the upteenth time, I ended right where I started: Confused. So I reached out to the community for help and received tremendous feedback that helped me better understand what OpenID is about. People left thoughtful, thorough comments on how to actually use OpenID and someone even left step by step directions. That made me realize: OpenID is still irrelevant for the average user.

However, the discussions held on FriendFeed and my personal blog opened an avenue to great (rational) exchanges of ideas, which got me thinking about how OpenID can be relevant to us.

• Verifying needs to be simpler
  Technicalities aside, verifying, signing up, claiming, or whatever the "correct" term is, one thing is clear: The steps need to be simpler. Right now, the process is a nightmare requiring many steps. Users should be able to go to OpenID provider sites, and with one step - two at the most, be able to verify.

• Email providers need to get involved
  With password storage managers the norm, URL log-ons should not be a burden - in theory. And that is the problem: in theory. Realistically, non-technical users are intimidated by using something other than their usernames, e-mails, or handles (nicknames) to log on. Since usernames and handles, without the URL, would be difficult to use as an OpenID log-on, Gmail, Hotmail, Yahoo et al joining the movement makes perfect sense.

• Partner with consumer sites
  One word: incentive. Imagine if OpenID were to be accepted by Amazon, eBay, PayPal and financial institutions. Why wouldn't everyone use OpenID?

• Update the site and Wiki with clearer instructions. I did not know that being logged into a provider site omits the verification process and log-on using OpenID without verification is possible - did you? That information is not readily available on the OpenID site, why? Or why isn't that on their Wiki? Almost every person with Internet access can go in an edit a Wiki. Will someone go in an update OpenID's Wiki page, please?

• Create a Need
  Either I am missing something or it is still unclear why OpenID is so important - and most of it is due to all the technical jargon that is on the site. OpenID / OAuth, privacy, owning information, decentralizing, centralizing, user-centric, SSL, profiling, identity, and other stuff (for a lack of a better term) - it would be helpful if it were re-written in English anyone can understand.

If OpenID were to implement at least three of the above five, even my mother would be able to understand and use OpenID. Are you a part of the movement? If not, what would make you use OpenID? Or do you even care about OpenID?

Read more by Mona Nomura at Pixel Bits