Google dominance of the search market along with their current moves to monetize the average users second click seems to leave other web content producers at a disadvantage. Perhaps there is nothing to worry about but when you own the primary entry point to the web that so many use and when there is so little transparency…

Amazon now provide pretty much have all the infrastructure that a web application might need – hosting, storage, database, message queuing. This stuff is utility SaaS in its rawest form. Nick Carr has a timely piece about what Google are up to in this space. (Update: Joe Gregorio, now of Google, has an interesting megadata view).

If you are looking for primers then you need go no further than Simon Willison’s How To use OpenID screencast (5 mins) and Explaining OAuth.

That said, minimal OpenID implementations won’t solve all authentication headaches. Phishing is a problem so I suspect OpenID enabled sites will need to employ white list providers as Tim and Dare highlighted this a while back.
.
Now we (the web community that is) need two things to happen.

1. We need the big online identity silos like Google, Yahoo!, Microsoft Live, Facebook and MySpace – the sites whose login page average web users trust – to step up to the plate and act as OpenID providers.
2. We need the big API sites like Google Maps/Charts/Base/…, Microsoft Live, Yahoo!/Flickr, Facebook to start working on enabling OAuth access to their APIs.

Note the overlap in the two lists above – yep, those guys own this part of the web. Which will be brave enough to move first? With final specifications in hand, no excuses, please go forth and implement and lets end this www account/data access hell we all live in.

the top 1% of searchers performs a full 13% of all searches in a given month. If you extend this to the top 20% the number of queries increase to roughly 70%

I suspect I’m in that top 1%, CTRL-K is probably the Firefox keyboard shortcut I use most of all. This does imply that search engine usage stats would swing dramatically if these power-searchers were to switch engines…

• Terms (Shelley Powers) – comments on the very important issue of the terms and conditions attached to usage of the OpenSocial APIs – I had completely overlooked this. T&C are normally attached to proprietary products, not open standards. So it looks like we are really looking at Google APIs, not open standards here.
• Where the hell is the Container API? (Russell Beattie). Short, to the point, and bang on the money. I’m not in a rush so I’m happy to wait for important web API specifications to be drafted, discussed, refined, voted upon and published via a credible authority. But the OpenSocial development process is not open (a newsgroup of pleading users does not make it so).
• Google OpenSocial: Technical Overview and Critique – Dare Obasanjo. Too much to summarize here, go read it.

All in all I’m beginning to think the use of the term Open in OpenSocial is terribly misleading marketing speak. I’d like to think this is an accident (after all Google care about the continued growth of an open internet right?) but there is such a monstrous gap in the process behind and the function of OpenSocial and how other open APIs and standards are developed that I can only assume that this is all a marketing exercise to misdirect attention away from Facebook at the cost of ushering out a half-baked alternative. The Campfire One video only re-enforces this – it is incredibly corny and lacking in substance!

APIs and standards are sometimes hacked together by partnerships in order to try address immediate market share concerns – this is beginning to look like yet another of these efforts. Hopefully I’ll be proven wrong when the Container API documentation is published but I’m not holding my breath…

Update: Miron highlights another potentially critical problem – track it here

I hinted that authentication was a concern at the end of my previous post on the topic.

According to the OpenSocial documentation I can only surmise that the only authentication mechanisms prescribed by OpenSocial are the Google Authentication APIs. The application user gets redirected to Google Login and once done the application gets a token that it uses when calling the OpenSocial APIs. This implies that every OpenSocial application user has to have a Google Account.

There are no references to open alternatives such as OAuth or OpenID in the documentation. It’s worth bearing in mind that the existing documents are very Orkut centric so perhaps they are focusing too much on explaining how it works within the Google/Orkut world but I can’t find any alternative info. This really doesn’t seem very Open!

I’m wondering how this this will work for applications that they are deployed into Ning or MySpace. Do the application have to detect that it is not in Google-land and use the local container’s authentication/delegating authority mechanism? Or do they continue to authenticate against Google Accounts? Am I missing something obvious here?

Hosting
Here things get fuzzier. One of the main things I wanted to find out was how I might host an OpenSocial application on our servers, in the same way that we host some of the Facebook applications that we have developed for clients. (Facebook authentication is described here for those are curious about where I’m coming from here)
The docs only talk about Google Gadgets. There isn’t any reference a callback API that the OpenSocial container calls when it wants the content for the application – this concept doesn’t seem to exist (or at least is not documented). The AuthSubRequest API does take a next parameter but is that it?

Applications
Here things even fuzzier. Again the Open Social docs are very Google-land centric so all they talk about is Google Gadget based social applications. I initially thought that they were just using Google Gadgets to illustrate how JavaScript based widgets would interact with the OpenSocial APIs but then I noticed that the OpenSocial home page states:

OpenSocial is built upon Google Gadget technology, so you can build a great, viral social app with little to no serving costs.

Uh-oh. Why create a dependency between an open social network API and a proprietary widget platform? I can see that some OpenSocial applications might be built as Google Gadgets but what if I want to create an OpenSocial application that isn’t?

Update: Simon Willison has some similar concerns and questions.

• The People Data API exposes people (viewer, owner, friends) via Atom feed documents and Atom entry documents. However, there is no AtomPub support for this feed so people cannot be created/updated/deleted via API. I suspect this will cause some debate as it means some fairly critical data remains locked into the underlying OpenSocial containers
• The Activities Data API exposes activities (news feeds etc) as a Atom feeds. The Activities data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.
• The Persistence Data API exposes name/value pair data (e.g. configuration params) as a Atom feeds. The persistence data feed can be fully manipulated (CRUD) via Atom/AtomPub requests.

I’m off for a curry but more later today. Here’s a teaser though – authentication is a concern….

Update2: Bebo and MySpace are also joining. That leaves just Microsoft and Facebook out in the cold.

No wonder Google didn’t invest in Facebook, they were busy setting up OpenSocial (site goes live tomorrow) with a who’s who of companies that are not Microsoft, Facebook or MySpace.

It’s an admirable and ambitious project and it kicks Facebook right in the FBML-tender-spot but as ever the devil will be in the detail. There seems to be some concerns about how truly portable applications would be but I’m far more interested in portability of user data. I’m looking forward to reviewing the API details when they are published, hopefully they will also incorporate some of the emerging de-facto standards like OpenID and OAuth.

Facebook’s next major move will be interesting. Some of their key application developers (Rock You, Slide) will of course divert resources to work on OpenSocial based applications.

While on the road I download mail from GMail to my PDA (an N800) via POP. However, when I subsequently checked the same GMail account from my laptop (via POP) it would skip over the previously downloaded email, leaving me with emails in two places.

Today, I discovered if you change your GMail login name in both your PDA client and desktop mail applications to recent:<username>@gmail.com then GMail will download all incoming email to both. The only side effect is it seems to download emails that you sent to others via the GMail web UI but I can live with that as I don’t use the web UI often.

NOTE: A word of caution – before you change your login name in your desktop mail application make sure you empty/archive your inbox first as it (Apple Mail in my case) will re-download your last 30days worth of email again leaving you with duplicates to delete. It behaves nicely from then on though.

See the GMail Help Center for more.