Yusuf Goolamabbas

Facebook is migrating to OAuth 2.0 (an open standard for authorization) and HTTPS to provide better security on the world’s largest social network. This has some implications for Facebook developers and users, and there are also some items of concern and others that require clarification.

As announced in May on the Facebook Developer Blog, by October 1, 2011, all Canvas apps on Facebook must have completed transition from the old Facebook authentication system and HTTP to the newer and more secure OAuth 2.0 and obtain an SSL Certificate.

Facebook released updated PHP and Javascript SDK’s to provide OAuth 2.0 support. There is a small snafu that after releasing the Javascript SDK, the PHP SDK which supposedly had OAuth 2.0 support didn’t work with the new cookie format so an updated one is to be released next week.

One of the ambigious requirements for developers is that they “obtain” an SSL certificate for Facebook Canvas and Page Tab apps. It’s not clear what “obtain” mean.

Are developers just to buy an SSL certificate and prove to Facebook that they bought one or are they required to host the Canvas or Page Tab app under HTTPS

Assuming developers have to host their apps under HTTPS, other questions which arise are

• Will Facebook default to as well enforce HTTPS access for all users on Oct 1 ?
• Will developers have to cater to both HTTP and HTTPS access to their apps ?
• Will Facebook ‘map/redirect’ HTTP traffic to HTTPS ?

Whatever it means, Facebook app developers already have a lot on their plate: viral channels on Facebook are diminishing fast and users are getting more expensive to acquire every day. Additionally, the trend to spend more time on mobile channels results in a reduction of time spent on Facebook Canvas games (many of which are built using Flash/Unity and are thus not available on a large number of mobile devices).

Will these changes hurt small to medium developers in particular? SSL has a reputation of being expensive to deploy and, although a lot of work has been done recently to lower this cost, the software tuning and the know-how for high performance SSL stacks typically exist primarily in large corporations.

Advertising snags

Canvas apps can incorporate advertising from Facebook-approved providers, but unfortunately Google AdSense – which offers some of the best eCPM rates – is not one of them. A number of developers have been clamoring for Google AdSense to be included in Facebook’s list of approved ad providers, however nobody seems to be holding their breath waiting for Google and Facebook to come to an agreement.

To ensure a good user experience, all elements in a Canvas page will have to be served over HTTPS; to do otherwise will result in browsers popping up mixed-content warning dialogs that interrupt and bewilder many users.

Additionally, Google’s browser Chrome is moving toward blocking mixed scripting, which is likely to affect non-SSL advertisements on Facebook Canvas pages that are served over SSL.

Are advertising networks ready to serve ads over SSL ? Or will app developers be forced to find some other way to monetize their products if Facebook-approved ad providers are not able to serve ads over SSL?

What will be the impact on their costs if Facebook app developers are forced to use content delivery networks (CDNs) to serve assets over SSL ? Developers also need to be aware that name based virtual hosting is not possible over SSL unless browsers, SSL libraries and server stacks support Server Name Indication.

If Facebook requires developers to provide both HTTP as well as HTTPS access to Canvas apps then that will increase complexity and cost of deployment.

Facebook Credits and impact

Any company or person deploying a game on Facebook must already cope with the mandatory requirement of using Facebook Credits instead of a proprietary currency. Before the requirement to use Facebook Credits, companies offering games and apps via Facebook’s Canvas system would determine their own currency and product pricing, selecting third party payment providers of their choice. For example, a vendor like PayPal used to provide a payment gateway for your Facebook app for a few percent commission on every transaction. The commission on the (mandatory) Facebook Credits system is a whopping 30% on every transaction. So much for the cost advantages of a unified currency!

Facebook Credits provide a fairly liquid unified currency – and that’s good. What’s not so good is that this currency still has a substantial number of zero-value credits in circulation, and users who pay with these “free” credits provide no revenue whatsoever to developers.

Options ?

One option Facebook app developers can consider is to host the application outside of Canvas and use Facebook’s Graph API to access Facebook platform features. Given that Facebook’s own FBML is deprecated and that almost all Canvas apps today are in iframe, the Graph API workaround is relatively easy and does not constrain developers with various rules (including the need to have the app hosted under SSL).

The ability to use Facebook Credits is obviously not useful or available outside of Facebook Canvas but there are alternatives, including the upcoming Google In-App Payments for the Web (5% fee on every transaction). Perhaps the rise of Android will increase the proliferation of Google Checkout accounts and if Google could address the issue of increased mechanisms of adding funds to Google Checkout accounts this can be a good beginning for the much rumored Google+ Games