Some folks will recall back in November I wrote how OpenSocial was irrelevant as a platform for social networking applications. I’ve been working with it for the last three days on MySpace and have to say, over the last few months the folks at MySpace have been working hard to bring OpenSocial to a usable reality. I’ve had some time this week to experiment with it and I must say – while certainly not “done” it’s come a VERY long way. Warning: This is going to get kinda lame for those who don’t care about Social Networks and application development.

Signed Requests / Security

OAuth which allows the providers proxies to sign requests using a pre-shared secret key – limited docs on the MySpace implementation are available on the developer site but your best served looking through the forums. This is so huge I don’t even know where to begin. Essentially, prior to this – anyone could make a request, watch it go over the wire and then manipulate the parameters at will. This type of untrusted injection was problematic for any application that needs to maintain integrity of their users data. Consider the following request:


// AJAX request

While 99% of users would never see this request go, the 1% of users who are more aware of what’s going on could see that by simply calling the file directly in their browser would let them write unlimited messages to anyone – virtually unchecked!


// False AJAX requests

Imagine if I wrote a script to automatically call that page incrementing the ‘t’(target) value by one each time. I could eventually send a message to every user on that social network. In case your wondering the level of difficulty of this, it’s not hard. OAuth changes this by signing the request.


// Pseudocode to sign
secret_key="password"
oauth_signature=sha1("m=write&t=1&s=1&c=Hi+friend&oauth_secret="+secret_key)
params="m=write&t=1&s=1&c=Hi+friend&oauth_signature="+oauth_signature

Now on the server side, we can validate the source of this data to be trusted because we can recalculate the oauth_signature value by reconstructing the string using the same calculation using the shared secret on the server side. If the keys match, the request is valid! So why not just “unsha1″ the value? SHA1 is a hashing algorithm that is generally not reversible. SHA1 is also implemented in most modern web languages so it’s easy to integrate. Only a full public key infrastructure would be more secure! BTW: I know this signature is invalid – it’s for illustrative purposes.

Developers, wherever you are, keep those keys secure and hard to guess!!!

Where MySpace is Still Failing

I commend MySpace for adopting a standard for their implementation of OpenSocial, however, there’s a critical flaw in the execution. It’s OpenSocial based, not a true OpenSocial application. For some unknown reason, I have to upload 3 different versions of my code (1 per “surface”) that are then bascially cached on the MySpace server. While this is great for load and scalability for a startup, it leaves me little room for tweaking and makes testing VERY difficult unless I work in their very small textarea. Thank God for Apple’s Safari which allows for scaling of textarea elements in real time. This also means I need to create a new version of my application for MySpace. It could have accomplished the same means to an end by having their responsibility for the application end with the directory registration process. In that process we could establish a shared key (see OAuth above) and any particular differentiations from the standard OpenSocial format. Furthermore, the write once – run anywhere mantra of Java OpenSocial could be preserved!

Developers Define Space

The Data Portability working group has been formed and has gained some mass acceptance among social network providers triggered mostly by actions of blogger Robert Scoble who downloaded all of his Facebook contacts using a script and sent the entire Social Networking community into an uproar. While nothing has actually come to the users as a result of the group … I’m hopeful that Social Networking will allow us to select the tools we wish to use without alienating our friends.

App Directory

At least in the MySpace arena, there will be a directory of applications that users can choose from. Other social networks also host their own directories and I suspect that will be the case for some time to come. I could see a future state where an automatic discovery tool worked its way in (like RSS for apps) but it may be trivial if developers are continuing to craft their applications for each individual network.

OpenSocial, is a new open standard for applications to integrate with some of the largest social networks in the world. On the surface, OpenSocial is a great move forward for application developers. The learning curve for FBML and FQL at Facebook is trivial at best, but just as learning many similar languages at once, having one simple API to reference is ultimately much easier. The portability of write once, run anywhere brings back to mind the panacea called Java. However, in reality, OpenSocial promotes frivolous time wasting applications that lack any real utility. This may change (and I sincerely hope it does) in future iterations, but for now, Facebook has the social networking platform to beat.

To begin with, there is no security model in place to authenticate communication between servers outside of the API. For example, if a friend is going to record an action on my profile, such as leaving me a message, and the widget provider wants to record that in a database for business reasons such as allowing portability of those messages, all that is provided is an unencrypted, insecure method for doing so. The application passes the message via HTTP along with both user Ids and that’s it! Any hacker with 10 minutes of time can easily spam a huge number of ID’s inserting ads for online gambling, pharmaceuticals or worse? There is an alternative – sorting the data on the individual social networks servers – but to what end? There is limited space and this does little for the portability of data that Google seems to be trying to achieve.

Second is screen area. Facebook profiles allow users to decide how much real estate an application can have on a profile. Using free market economics, folks who dislike large presences on their profiles will likely not use an application, forcing developers to decide how much is too much on their own. The Orkut code sets the size of the profile presence as well as the canvas, limiting applications to play in a very rigid and confined space. Leaving aside the argument of space for PPC advertising, this leaves very little space for the applications interface and more over thwarts the users ability to select the tools that fit their personal style the best. Developers who are doing testing to decide if there’s a viable business model behind an application are left to swallow a huge opportunity cost because of limited space for the PPC advertising. Instead, to monetize traffic early on, they much leverage partnerships that are often more costly and difficult to broker, leaving less time to actually build their application. If the OpenSocial model leaves an unclear revenue model for an developers, it will be left up to hobbyists to build and support applications in their free time.

Third, naked source, this is not just open, but naked. There is very little to keep another one company from swallowing ideas from another company, but lack the resources to execute it fully, or afford the lawyers to protect their intellectual property. Early in the days of Facebook apps, some folks were burned by sharing their source before they had established market dominance. With OpenSocial, anyone can read your source and do with it as they wish. Really, I’m not kidding, it’s all right there for the world to see (unless you insecurely store data on external servers and keep some of the business logic there!) While in theory, this can lead to more secure code, it does not foster a strong platform for business to develop innovative applications. I’m sure that when Google and the rest of the OpenSocial partners provide authenticated communication with the Application providers external servers (like Flickr and Facebook do) this will become much less of an issue.

Fourth, portability of user data. A big problem with social networks today, is the portability of a user’s data; it’s not. As I mentioned earlier, user generated data is not secure when it’s sent off of the social networks server. Additionally, there is no structure in place to make the users data really portable – not just for applications – but for the users themselves. Access to the social networks contact list is limited at best and only accessible to someone willing to write a specific application to fetch it. Some content can be taken as a feed to other services (if the network allows it) but that does not equal real portability for the user. Perhaps there is yet another standard needed here that dumps a users profile content in a portable way? I’m thinking something like RSS for social networks. If I don’t like my ISP, I can change from Cable to DSL and back again, why can’t I do that with my social network provider?

Last but not least, there is no central directory of applications. I am sure there are a few developers out there right now working to remedy this, but I wish they would launch an alpha of some sort so independent developers (ie, not Slide and RockYou) could start getting the word out about their applications.

I’m looking forward to seeing where OpenSocial takes the social networking community at large, but generally, I think we’ve got a long way to go. Who knows, it might be December before this stuff gets addressed! So much for panacea.