Archive

Archive for July, 2011

Facebook OAuth 2.0, HTTPS, Credits : Implications for developers

July 23, 2011 Comments off

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

Categories: General

Google Checkout limited mechanisms of adding funds and its impact on monetizing freemium Android games

Mobile analytics firm Flurry has an interesting chart showing the rise of freemium games and its impact on the list of Top Grossing Games.

According to them, at the end of June 2011 65% of the revenue generated by the Top 100 Grossing games in the US App Store were freemium games. This is in large part due to Apple having access to over 200 million credit card on file. Apple also makes it convoluted to activate an iOS device without providing a credit card. There is also the ability to buy iTunes gift cards as well as link the iTunes account with Paypal

Compare this to the Android Market where Google provides in-app billing service via Google Checkout. Android usage is booming and activation requires a Google account. However there is no need to create or associate a Google Checkout account during activation.

Also, prior to it use for Android Market the only reason one would have funds in a Google Checkout account would be to pay for extra storage for Gmail or Picasa or buy a premium plan for Google Apps. That’s a fraction of the Android userbase.

If freemium gaming is going to be one of the big drivers for increased Android apps and particularly ports from iOS thereby  increasing usage of Google Checkout then it becomes very important to have lots of mechanisms to add funds to Google Checkout in a  relatively frictionless manner.

My personal example, I have handed down my old HTC Hero to my daughter and she has activated it with her own Google account but I can’t add any funds to her Google Checkout account which isn’t linked to a credit card.

Facebook has spent a lot of effort partnering with alternative top-up mechanisms and now Facebook Credit pre-paid cards are available in a ton of places particularly in South East Asia where credit card penetration is very low and there are established infrastructure for topping up funds to use for micro-transaction payment. Carrier billing is very expensive and this can easily be seen when buying Facebook Credits which cost 3x as much via mobile payments compared to walking to the neighbourhood shop and buying a scratch card.

Categories: General
Follow

Get every new post delivered to your Inbox.

Join 1,198 other followers

%d bloggers like this: