That day has come. The Google Contacts API went live tonight and it enables far more than just contact transfer.

• Synchronize Google contacts with contacts on a mobile device
• Maintain relationships between people in social applications
• Give users the ability to communicate directly with their friends from external applications using phone, email, and IM

"The Contacts API allows developers to create, read, update, and delete contacts using the Google Data protocol, based on AtomPub," the announcement says. "It also allows for incremental sync by supporting the 'updated-min' and 'showdeleted' parameters."

Pretty hot read/write stuff and particularly interesting given today's developer launch of the location tracking Fire Eagle from Yahoo!

One thing Fire Eagle has going for it that the Google Contacts API does not is support for the open authentication standard oAuth. Support by Google for oAuth in this API would have reduced the work required for developers by allowing code from other authentication proccesses to be reused. Google is supporting oAuth in OpenSocial, but on some days that hairball is harder to get excited about that a nice simple API like this one that delivers clear value.

Today's a big day for developers, may the secure Gmail contact leveraging begin!

Unfortunately that's what we're asked to do with a lot of new applications these days. It doesn't have to be that way, though.

Twitter

Senior Software Engineer at Twitter Britt Selvitelle said today in a conversation for developers working with Firefox that Twitter "will be using OAuth as our primary form of token auth."

That's fantastic news for a few reasons. Twitter is a very important communication tool for many people, the service's Application Programming Interface (API) has allowed a huge ecosystem of interfaces and applications to flourish around it...and yet today all of those 3rd party apps have to ask for your Twitter password in order for you to use them. It's been an awful lot of risk for users to take and we're really surprised that no one has yet ripped Twitter passwords from unsuspecting users and then unleashed a wave of valid looking spam.

Finally, it appears, Twitter will soon implement a secure way for you to give 3rd parties access to parts of your account without giving them a copy of the key to walk in the front door any time they like.

Firefox

The conversation today took place in the context of a question from Matthew "lilmatt" Willis, a Flock employee and longtime contributor to Mozilla. Willis wants to know if the Firefox developer community would like OAuth built into Firefox and if so how. He points out that much of the work has already been done, if not multiple times.

We're not entirely sure what this would look like, but we are intrigued. Browser-based authentication for data mashups sounds great. Browser plug-ins that securely access your various accounts without asking you for your passwords sound great too.

As of this afternoon there's a developer preview of a browser-based OpenID implementation for Firefox (thanks Vidoop!) so we hope that an OAuth implementation for Firefox could be a complimentary project.

The Big Picture

Google adopted OAuth for all the Google Data APIs this summer, so there's really no reason why 3rd party apps should ask you for any Google passwords ever again.

This is all very good news for everyone. Secure user authentication equals greater user trust, which equals developer access to more user data. More developer access to user data equals more innovation. More innovation makes us happy (we love this stuff) and, co-incidentally, leads to more user data. Data portability is good for everyone. Bring it on, Twitter and Firefox!

WordPress announced last night on the company blog that WordPress.com users have a new blogging option called "Turbo," which uses Google Gears to speed up the service's admin functionality. Just an hour earlier, WP founder Matt Mullenweg indicated that users should look for OAuth support in future versions of the software.

The new WP.com Turbo feature uses Google Gears to download more than 200 files to users' local computers so they can be run without accessing the web. Though many of the most high-profile Gears implementations elsewhere are focused on providing off-line functionality, it's not clear whether that's the case here or if Gears is just being used to speed up blogging. Either way, this is good news. With the new feature, WordPress.com effectively offers what is called a Rich Internet Application (RIA), combining the responsiveness of local actions on the desktop with the connectivity of the web.

RIAs are already shaping up to be a powerful part of the web. Local storage and user interaction with at least some data fleshes out the possibilities offered by the celebrated migration towards web applications.

This is probably only the beginning for WP support of Gears. We wonder whether the WP developer community will build extensions that leverage WP support of Gears, perhaps even incorporating Gears support for mobile devices. Oh, the possibilities are a thrill to consider. The draft version of WordPress.org, scheduled to be released in final form within the next two weeks, already includes support for Gears as well.

OAuth

OAuth is a user authentication protocol that is quickly becoming a standard. It's all about making mashups fast, easy, secure and thus more common. When Google rolled out OAuth support for all its data APIs earlier this week, we said it was only a matter of time until almost every one else did so as well.

WP's Matt Mullenweg said last night that he wants to see OAuth support in WP but wouldn't be able to include it in the next version. Can we expect to see it in the next version then? We certainly hope so.

What might OAuth support in WordPress look like? There are a number of directions it could go. By supporting inbound OAuth authentication, WordPress could do things like allow you to post to your blog through 3rd party applications without giving them your password. It could also allow blog commenters to associate their accounts on other OAuth supporting services with their WP comments, again without giving up their passwords.

For blog publishers to be able to get secure programmatic access to their reader's data from other services would be very exciting. You don't want to give some random blog your Google Accounts password, but imagine if you could see all the comments ever left on that blog by your Gmail contacts - without giving up your password. That would be great.

There are probably far more possibilities than we can imagine, but that's what makes WordPress so exciting. There's a huge world of plug-in developers that extend the service in ways that none of us could imagine. With OAuth support those developers would be able to leverage a whole new class of options based on secure user data. That means WP blogs could tie in programmatically with any of your Google accounts, your Photobucket account or any other service that supports OAuth in one direction or the other. That's exciting to imagine and it sounds like it should be coming soon.

We're excited to see that WordPress isn't just relying on its developer community to keep it fresh and hip with the times. These new core developments will serve as a foundation for those developers to improve even further on the WordPress user experience.

The spec got a burst of publicity earlier this week when the widely used feed reader Bloglines announced that they intend to support it in addition to OpenID and the Attention Data standard APML.

In this post I offer a high-level overview of what OAuth does, in as much as I understand it, followed by some thoughts on the concepts from some helpful industry experts.

Standards are the railroad tracks to a potential explosion of innovation and OAuth aims to make mashups far easier to develop than ever before. The group of developers took what they believed to be the best qualities from a long list of other authentication protocols and created an open standard they believe will make mashups safer to use and simpler to develop.

What Will This Look Like?

Here's one example of what OAuth might look like. There are lots of services like Twitbin or Twitteriffic that let you use your Twitter account in a much more powerful way outside of the Twitter web page. Those applications ask for your Twitter username and login, though; OAuth will let these apps interact without users exposing their full login info.

In that, OAuth is like OpenID, but this protocol will let services that hold your data offer a set of rules and options for allowing other applications to access selected parts of it. You could login to Twitter through Twitterific but only give Twitterific access to read and write messages - not to change your user profile page, your password or do anything else that they could in theory do today with full access to your account.

Is This Really Going to Happen? Let's Ask Some Experts

Making open standards real doesn't sound like a lot of fun, but the OAuth group seems to have a good start. The spec is being worked on by people from Google, Amazon, Yahoo/Flickr, Six Apart and all the three leading microblogging services. Implementation is expected soon by Netflix, Threadless, Bloglines, Twitter, Jaiku, Pownce, Ma.gnolia and others.

Agreeing on the final draft of the 1.0 spec is likely the last thing companies are waiting on and that's something that's happening a lot faster with OAuth than with OpenID 2.0, for example. Scott Kveton, Chairman of the Board of the OpenID Foundation, told me he thinks OAuth is another exciting move towards data portability and user control. He said that the small group involved in the spec is a real benefit when it comes to speed of development but that they will still have to struggle with IP like copyright before implementation really takes off with large players.

Oren Michels, of the recently funded API management service Mashery, says that OAuth could save his team a lot of valuable time currently spent working with the particulars of each non-standard API. He also told me, though, that many of his customers already have their own APIs built and would not likely go back and make them standards compliant. Ultimately, he said, good APIs are more important than standards compliant ones. In the future, companies that learn about OAuth early in the development of their APIs could implement it if there's sufficient market adoption.

Finally, I talked to John Musser of API super-site Programmable Web. Musser said that he's long argued that security is the number one barrier to further mashup proliferation and OAuth appears to address that well. "Higher value, 'personal mashups' require access to more interesting data than you can get without some secured access," he said, "but of course it's also an area lacking in standards, certainly from the perspective of the current generation of web 2.0 APIs." Musser also agreed with Michels that good APIs are more important than standards; he said that mashups are perfectly buildable today with the current circumstances but that a standard like OAuth could make a big difference by easing the complexity for developers.

Only time will tell whether OAuth has legs - but given the parties participating and the potential power of the standard, it may not take too much time to get a good look into the future.

When Google pushed out the Contacts API we called it "the most in-demand API on the web" that hadn't yet existed. These APIs are important because they allow socially aware applications to offer users the ability to import information from their address books without having to worry about giving up their password to a third-party site. The application seeking the information also no longer needs to employ any screen scraping to gather information.

Like Google and Microsoft, Yahoo! opted to employ their own authentication technology in the API, called BBAuth. Yahoo! intends to supports OAuth in the future, though, which will make it easier for developers to use the API. "Support for OAuth is coming, my friends, in due time... Seriously," wrote Wu. "At Yahoo! we're already doing a lot with OAuth (think Fire Eagle) and it's a big part of our plans."

The API is currently limited to 5,000 queries per IP address per day.

Standardized legal documents for technical specifications may not seem like the sexiest thing in the the world - but this is actually pretty exciting news. Developments like this could be a key part of the foundation that online service providers need to move forward on a long list of great ideas for ways to serve their users.

People come up with crazy ideas for making the web work better all the time. This agreement aims to provide an easy way to make it safe to implement those ideas. The companies participating have spent large amounts of time and money negotiating the agreement, now anyone can take advantage of the fruits of that labor at no cost.

Existing specifications that will be placed under the Open Web Foundation Agreement, per the announcement today, include:

• Syndicated media delivery spec Media RSS (currently controlled by Yahoo!)


• Secure 3rd party authentication spec OAuth Core and Wrap (from Facebook, Google, Yahoo! and Microsoft)


• Real-time feed protocol PubSubHubbub (Google)


• Comment aggregation protocol Salmon (Google)


• Web Slice Format (Microsoft)


• And several others.

Sadly, it doesn't look like Google implemented any advanced authentication mechanisms like OAuth for the Twitter integration (Update: apparently this is Twitter's own fault for not supporting OAuth yet, though they promise to enable this feature in the next major release).

As Biz Stone points out on the Twitter blog, this might indeed become an interesting way to find your Twitter friends on other sites. For now, however, Friend Connect is not implemented widely enough for it to have any real effect yet.

Friend Connect vs. Facebook Connect

Google is clearly locked in a battle with Facebook Connect, and thanks to this Twitter integration, Friend Connect now feels a bit more like Facebook Connect, as your actual friends are shown separately from the other members of the site.

This Twitter integration will surely sway a few site owners to implement Friend Connect over Facebook Connect, but it will surely take a month or two before we can see which service is taking the lead.

As long as people are willing to trust their Twitter log-in information to third parties - and don't look carefully at URLs before they log into websites - and as long as a small number of bad actors want to pee in the social media swimming pool, this kind of thing will continue happening.

Apparently there's no substitute for ruthlessly and constantly policing your own feed, thoroughly investigating services before you sign up for them, double-checking the URL every time you are about to enter info into a form, and regularly purging your OAuth settings of services you no longer use.

Also, to be safe, change your password regularly... you don't have to be obsessive about it: every three hours or so should be enough. And because erring on the side of caution is always a good idea, fake your own suicide and change your identity at least once a year.

And you thought Twitter was going to be fun? Slacker.

More Noise to Signal.

None the less, there are some very interesting details available about the MySpace Platform. After all, that is where the action is - there's far more traffic to MySpace than Facebook.

• The best part of the announcement, as far as I'm concerned, is that MySpace apps will be allowed to include user admin/home page interfaces in addition to the part of the app that displays on the public facing profile your friends see. It will be drag and drop, making your admin page a lot like an AJAX start page. This is a big differentiator with Facebook so far.


• Developers will have one month to work on apps for the platform before users come in. It's open to all, something MySpace says will "democratize" the process and prevent any early-access favoratism given to a handful of select companies on the Facebook Platform.


• User security is high priority and apps will be limited in their ability to access information. Some critics allege that this is not the case at all over on Facebook, saying the Platform there gives total access to any app allowed to enter your profile. That said, see our earlier post today on MySpace and Google.


• There are three APIs, the Google-lead OpenSocial being the primary one, some MySpace extensions for fields like favorite movies is another. Though we've said that OpenSocial would be better described as OpenWidget, this instance at least will support social graph portability. Notable. Note also though that this is one more platform deploying "OpenSocial - Plus." Get enough Plusses in a room together and you have to wonder how much anyone is communicating with anyone else.


• MySpace's oAuth support, via OpenSocial, will - I believe - make MySpace by far the biggest user of oAuth on the web. That's great news for this open standards based authentication protocol. More oAuth = more and safter mashups all around the web.

The least convincing reply to my questions came when I asked MySpace CTO Aber Whitcomb what would keep MySpace apps from being as annoying as the ones that have lead Facebook users to complain that Facebook is now too much like MySpace. Whitcomb said that MySpace apps would be less annoying because developers would have more and equal time to develop them, this next month before users let in, and so there would be fewer trivial and poorly made apps.

Finally, I'd just like to add to this discussion that MySpace has solved the spam issue better than almost anyone else on the web. Have you noticed? At the end of September MySpace installed a Captcha requirement before a friend request could be sent and I feel like I haven't gotten a single spam request since then. That's great!

You can be snobby about your friends' noisy MySpace pages and the "classier" Facebook experience if you want, but many people are getting tired of the Facebook Platform already and it will be interesting to see what the leading social network online can do now.

By default, Twe2 will send you an SMS whenever you receive a direct message or a reply. In order to finance this service, Twe2 appends a short ad to all of its SMS messages.

Twe2, whose developers are also responsible for the popular FriendDeck app, has added a number of interesting features to its service that Twitter itself never offered. You can, for example, use the service to receive a message whenever a certain keyword appears in your stream, and you can even use relatively complex search queries.

In order to keep your Twitter SMS stream manageable, Twe2 lets you set the notification frequency (up to 100 messages per hour), and you can also specify if you only want Twe2 to send you messages at specific times during the day or only on certain days of the week.

Thanks to these features, Twe2 is even an interesting service for those of us who live in countries where Twitter's own SMS service is still available. Twe2 also promises that users in the U.S. will get a few extra features in order to distinguish the service from Twitter's own SMS updates.

One problem with Twe2, however, is that the service doesn't have access to Twitter's firehose feed, so that it can often take a while before it notices a new message and forwards it to you.

OAuth Coming Soon

Twe2 was approved by Twitter to test the company's forthcoming support oAuth, though this is not available yet. For now, you still have to provide Twe2 with your Twitter login and password.

Find Us on Twitter

If you'd like to befriend the ReadWriteWeb staff on Twitter here are our accounts - we'd love to meet you too!

The story is about a GMail archiving application being sold by an unscrupulous coder who programmed the app to forward all GMail usernames and passwords from customers to his personal GMail account.

Dustin Brooks is a reader of Atwood's excellent blog Coding Horror and sent Atwood the story of his sleuthing around the app, called G-Archiver.

"It didn't really have the functionality I was looking for," Brooks wrote, "but being a programmer myself I used Reflector to take a peek at the source code. What I came across was quite shocking. John Terry, the apparent creator, hard coded his username and password to his gmail account in source code. All right, not the smartest thing in the world to do, but then I noticed that every time a user adds their account to the program to back up their data, it sends and email with their username and password to his personal email box! Having just entered my own information I became concerned.

"I opened up a browser and logged in to gmail using his account information. It still worked.

"Upon getting to the inbox I was greeted with 1,777 emails with account information for everyone who had ever used the software and right at the top was mine. I decided to go ahead and blast every email to the deleted folder and then empty it. I may have accidentally changed the password and security question to something I don't remember as well, whoops, my bad. I also contacted google to erase this account as I didn't see a way to delete it myself."

Way to go, Dustin Brooks.

Authentication Standards and Best Practices: A Key to Innovation

How often have you given your usernames and passwords to various services, including webmail, to a new application you want to check out? I know I do that far too often. I decided I'd had enough last week when yet another application asked for my Twitter username and password. Twitter pays my rent, so I can't be giving my credentials out to just anybody. I don't need to get G-Archived.

New 3rd-party Twitter clients are just not going to get any attention from me until Twitter offers an authentication protocol that doesn't require me to provide my username and password. It's pretty insane if you think about it, given how central the Twitter API is to the company's viability. I guess if you're struggling to keep your pants up at a party, though (service up time), then there's no time to make sure your fly is zipped before meeting the other guests.

When users decide that they won't give out their credentials to random startups, the user pipeline is going to dry up and innovation is going to be slowed substantially. Maybe that's already happening and a world of potential support for innovation is already absent.

With the release of the Google Contacts API this week, developers don't have much excuse to ask for GMail username and password. Unfortunately, Google didn't build its API on a standard like oAuth, so that framework won't spread as far and wide as it might.

Niall Kennedy has written a great article about authentication best practices and the oAuth website is a good place to go to read more on this topic.