Question

Answer: Time to set your clocks ahead for Daylight Savings Time. *

Answer: Barbara Feldon’s birthday **

Answer: IFrame apps will be accessed through HTTP POST instead of GET.

That’s right kids, as Facebook has been telling us for some time now, your IFrame apps will be accessed from your customer’s clients by a POST instead of a GET. This is significant because it is most definitely a breaking change, e.g. one that has the potential to make your application stop working if you aren’t careful, so pay attention.

So why is Facebook doing this? Well, it has to do with a little something we call privacy. The problem is that a customer’s Facebook userid used to be passed in the URL (as part of a GET) so that the application could know which user a request was coming from. The problem is that subsequent calls would retain this userid in the HTTP Referrer header, and possibly allow third parties to get access to it. Privacy advocates rightfully have a problem with this, so Facebook looked for ways to fix the problem.

The solution to the problem is not to use a GET but rather a POST and pass the customer’s userid as a POST parameter. If all access happens over a secure channel (like Facebook now allows us to do) there’s no fear of exposing userids to third parties. Good solution, except for the fact that if your application expects a GET and receives a POST instead, you’re hosed.

So what to do if you have an IFrame application? Well, test it before Saturday comes lest things break. To do this, you must go into your application’s settings and enable the POST for Canvas selection.

Once this is done, Facebook will provide different HTML to the client’s browser so that your application is accessed through POST instead of GET. Be very careful though if your application is already live. If your application is broken by this change, then selecting this will effectively knock your app off of Facebook. So to be safe, register a test application and use that instead.

More technical information about this change can be found here. Facebook offers some simple solutions for how to do this migration on popular development platforms. There’s also some feedback from developers who’ve experienced some problems, so it’s a good place to start if you find problems yourself.

Good luck.

* Yeah, technically this happens on March 13, but better do it before you forget.

** We loves us some Agent 99 so much we won’t give away her age.

• Is it a good idea?
• Can I make a lot of money this way?
• How do I make a lot of money this way?

Now the process for starting a startup is a very widely written about topic, and that’s where you should probably begin your journey. However, there are some specific Facebook-centric issues that make a Facebook based startup a bit different. Some issues make life easier, some issues make life more difficult. That’s what we’ll discuss here.

When you create any type of software startup, there are 3 key roles that need to be filled.  It’s important to understand the role each plays to help you understand where the real challenges are going to be. Let’s take a look:

1. The Idea Originator
2. Software Development
3. Marketing/Sales/Strategy

The Idea Originator

The most misunderstood thing about creating a software startup is the importance and value of the original idea. Here’s the grim truth: The original idea is worth $0.00. Why? A few reasons: When you begin to validate your ideas and have them exposed to customers, the original idea will change. But more importantly, the value of the idea is far overshadowed by the value of the execution of the idea. There’s far more work and creativity required to do things like drive customers to your product and monetize the idea than to come up with the initial ”Million Dollar Idea”.

There’s even a whole scene about this in The Social Network where Mark makes an impassioned speech to the Winklevii’s lawyer about why they don’t deserve a piece of Facebook. He rightfully says that Facebook’s value came from all of the good ideas and hard work that went into the product. Since the Winklevii weren’t even capable of participating in this work, they deserve nothing. Surprisingly, Hollywood got it right!

Still don’t believe me? Read on …

Software Development

Everyone who’s ever done development in a big company knows that they’re the company’s crown jewels. Development is the engine that everything else revolves around, and so it’s the major contributor of value for your company, right?

Well sure, software development is really important, but is it the most important aspect? In a startup you also need to consider …

Marketing/Sales/Strategy

Sure you need a solid development team, but as a startup that’s only the beginning. Your big company had loads of luxuries that your startup doesn’t have like brand recognition, distribution, existing customers, money in the bank, and other things that make a difference. These things are key, and how your startup deals with getting customers and making money will determine your success. You can conjure up all kinds of fantasies for how you’ll make money, but in the end only a rational plan will do.

Here’s what you’ll need to think about:

Distribution

Distribution is how you’re going to get your product into the waiting hands of the teeming millions. In the olden days that meant producing a box and getting some shelf space at the computer store. But no longer, this is 2011. Since you’re building a Facebook app, you’re going to use Facebook to deliver your great product. Distribution problem solved, until …

Attention

Getting people’s attention is a much harder nut to crack than simply having a distribution strategy on Facebook. How you choose to do this is really important. Perhaps you’ll say “Of course people will pay attention to my product because it will be so great and unlike anything they’ve ever seen, they’ll come to us in droves, and the app will go viral.”

Bad plan. How many apps do you think people have access to on Facebook? Currently, it’s somewhere around 17 gazillion. And yes, according to Facebook Statistics, people are installing 20M apps per day, but that doesn’t mean they’re installing yours (actually most of those are probably going to the latest incarnation of *Ville). Getting people’s attention is becoming harder and harder. Simple virality is a thing of the past as Facebook is taking away many of the tools and tricks that developers used to use. The problem was that many of those developers used spammy tactics to boost their numbers and customers rightfully complained. Things that used to work no longer will, and anyone who thinks they can recreate the success of an application that went viral two years ago will be sadly disappointed.

Of course, you can always raise your app’s profile and get some attention by using Facebook ads. These ads can be targeted to whatever demographic you like, but they cost money. If you need a large user base to effectively monetize your application, then you’ll need to spend quite a lot on ads to get that necessary attention. You do have a big pile of money to spend on advertising, right? Hmm, didn’t think so.

How about free publicity, like being picked up by the Wall Street Journal, TechCrunch, or even Inside Facebook? Great idea, but how do you get that done? The fact is this is possible but will require some really great traction, perhaps some connections, and perhaps a bit of luck.

Monetization

How does one monetize their Facebook application? Good question. When you come up with a good answer, perhaps you can share it with the world and help out all of the developers milling around the Facebook Developer’s Forum asking the same question. In short, monetizing your Facebook app, even a good one, is not so easy.

You could try to monetize through advertising. Facebook even has an approved list of companies that will help you do this. Will you make money this way? Probably. Will you make lots of money this way? Probably not. It all depends on how popular the app is. You do have loads of users, right?

An alternative way to monetize is through some sort of in-app currency. Of course, Facebook has their hand in this after introducing the concept of Facebook Credits last year. Credits can be used to do things like purchase virtual goods within a game. Think the idea of purchasing virtual goods is stupid? Think again, it’s big business. The problem with in-app currency though is that your application must naturally require it. Whatever you use the currency for must meld with the idea of the app or it will just seem like a random idea bolted on as an afterthought. There’s no money to be made in bolted on ideas.

Of course, you can come up with other ideas for how to monetize your application, but that will require a large dose of cleverness. And remember, whatever you do must also stay on the compliant side of Facebook’s TOU.

Funding

At this point you may be noticing a pattern: when it comes to various tasks for your startup you can either come up with some really clever ideas, or pay some money. Since inspiration for great ideas may be low, you might think about looking for some funding to pay for what you’ll need. You might even be thinking, “Hey, I’ve watched Dragon’s Den or Shark Tank a few times. My ideas are much better than what I’ve seen there – surely getting some Venture Capital or Angel money won’t be so hard.”

Uhhhh… yes it will. Getting anyone to put money into your startup is incredibly difficult, even if you have some traction. What, you don’t have any traction yet? It’s going to be harder.

Now something you should know about is that there are some special circumstances for receiving funding as a part of the Facebook ecosystem as many investors are looking to find the next Zynga. Long ago (well, long ago in Facebook years) Facebook created the fbFund which was a funding source meant to help young companies in the Facebook ecosystem. Depending on when you were looking, this help could have come in the form of a grant or an investment that took a piece of the pie. Right now, it’s all academic as the fbFund as an entity no longer really exists.

When fbFund ceased to exist, fbFund REV rose from its ashes. This incubator program was run by Dave McClure of Founders Fund, and provided exceptional startups money as well as mentoring and great access to everything and everyone a startup could need. Sadly, this too seems to have lost its steam.

But that’s okay. There are sources for funding Facebook ventures popping up all of the time. You just need to take a bit of time to learn what they are. But more importantly, you need to plan for something that deserves venture funding.

Alternatively, a good dose of cleverness is always welcomed to create your own funding strategy. Give me 15 minutes and buy me a beer and I’ll tell you the story of how we funded the development of FriendRunner with mostly other people’s money. You probably won’t be in a position to do exactly what we did, but perhaps we can inspire you. Learn where the money is and the rules for how to get it. Throw in some clever ideas, and see what you come up with.

So, is it a good idea?

Absolutely, it’s a good idea to build a business around a Facebook app.

However, to be successful it’s critically important to focus on the right things. Zynga’s FarmVille didn’t just spontaneously happen. You can almost imagine early meetings where they discussed:

• How people will learn about the game
• How Facebook’s social aspects will be used so that players can suck their friends into the game
• How money will be made
• Alternative ways that money will be made
• How to tie the game into the real world
• Partnerships that can be entered into
• What to do if Facebook changes the rules in midstream (oh yeah, something important to think about)

You can also imagine that at the end of the meeting someone asking “But what will the game be about?”. After a bunch of blank stares, someone else throws out “You can pretend you’re running a farm or something.”.

Please leave a comment with your thoughts about starting a Facebook venture.

Facebook application development teams have always needed to register who was on the team with Facebook, so that those people could access, build, and test the application before it was released to the greater public. The problem was that belonging to the team was binary – you were either in or out, and only those that were in could access the pre-released app. However, all of the team members could view and modify the Application Secret, change the app’s URL, or throw everyone else on the team off. It didn’t matter what your actual job was, if you were on the list you had absolute authority.

The new Developer's Role dialog

Facebook has now changed that by allowing you to define the roles for the people on your dev team, and thereby limit what they can and can’t do. Here’s a list of the roles you can assign:

• Administrator – complete access to the application and all its settings
• Developer – can modify all technical settings and access Insights but cannot reset secret key, delete application, or add additional users
• Tester – can test the application in sandbox mode but cannot modify the application
• Insights User – can access Insights but cannot modify the application

This is great news, and is a step in the right direction to show that Facebook application development is growing up. I’ve done some consulting on testing Facebook apps, and have always been uneasy when I’ve been added as an applications “Developer”. I always felt uneasy about getting exposure and access to a company’s crown jewels, and asked to be taken off the list as soon as the gig was up. Now, I can be added as a “Tester” and gain access to only those priveleges that I need.

So let’s hope Facebook continues along this thread and provides more tools and services that acknowledge that Facebook application development is being done by teams that have real needs. For example, a real development team will want to stage any code changes before making them live (just like what Facebook does with the Beta Tier). Unfortunately, the only way to test this beta code is to register another application with Facebook so that the production and beta code can run in parallel. But registering a new application will cause a new Application ID/Secret to be created. This means that once the beta code is proven to be good it will have to be modified in order to be run as production. Bad bad idea, but it’s the only way that Facebook will let you do it. It would be nice if Facebook would provide some easy ways to deal with things like this, as well as other difficulties that large dev teams certainly encounter. Facebook – give me a call, I have lots of other ideas.

So what would you change to help your development team interact with the Facebook Platform more easily. Leave a comment to let us know.

Never Mind*

Almost a year ago I wrote a post entitled Why is an Application Secret secret? (Part 1). You may ask, what happened to Part 2? The short answer is that I began writing Part 2 a long time ago and never quite finished as there were lots of things to say and my thoughts never really coalesced. The gist of the post was going to be a discussion about why Facebook should simply use SSL in many places where sensitive data is being transmitted. SSL is an established technology that developers know how to use, and Users recognize and trust. It seemed like the right thing to do, so I am very happy to see that today Facebook announced their commitment to using SSL to increase security and privacy. Instead of publishing my original Part 2 with the caveat “Never Mind”, let’s look at what was announced:

More security for Users

The biggest part of today’s announcement is that Facebook will now allow you to access their site at https://www.facebook.com instead of  just the normal non-https version. This will change the address bar in your browser to alert you that all communication will happen over a secure channel.

Given Facebook’s problematic history with privacy issues, we can all say a collective “It’s about time”. Using SSL will mean that we no longer need to worry about our private information being “sniffed out” by miscreants as it travels across the Internet between our browser and Facebook.  This includes hackers, ISPs, other people at the Wi-Fi Hotspot, rogue paranoid governments, etc. It’s like an instant privacy boost. For instance, users accessing Facebook over SSL will not need to worry about their sessions being hijacked by systems such as Firesheep.

So why didn’t Facebook implement this earlier? I honestly don’t know. Was cost a factor? SSL ain’t cheap, but come on, Facebook must have a few dollars in the bank. Performance hit? That’s people’s automatic knee-jerk reaction to SSL, but with modern hardware and software, it’s really not so much of a hit anymore. The real answer as to why it’s taken this long will have to remain a mystery.

More security for Applications

Modern SSL client implementations have the provision that if a page is served over https, then the entire page must be served over https, including all of the external parts. If not, the user is confronted with confusing dialogs warning of security problems.  This makes a big difference when you run a Canvas application in an IFrame (which is how Facebook dictates we need to run them now).  The “stuff” inside the IFrame is the result of the browser directly interacting with the application without going through Facebook. If  the Facebook page “container” was fetched over https, then your Canvas application must also be fetched over https.

This seemingly modest change was announced on the Facebook Developer Blog, and sort of hidden away. However it’s a pretty important issue. Facebook is essentially telling developers that they need to use SSL or risk freaking out their users and having them abandon the application when security-related dialogs start popping up. For the Zyngas of the world this isn’t much of a problem, but small developers will find that their deployment and hosting costs will rise because of this, and micro developers who rely on free hosting may start to just give up. Already, we can start to see a bit of backlash from the developer community. Facebook could offer some sort of http->https proxying service to relieve the burden, but that would defeat the whole spirit of SSL by simply providing the illusion of real security while allowing a large part of the data transmission to go unsecured.

Why not do away with Application Secrets?

Facebook’s announcements today had a very clear focus on data transmitted and received from the user’s browser. But that’s not the only data flying around when an application is being used. There’s also the data moving between the application and the Facebook servers – API calls and such. Shouldn’t we be securing them?

Well, the answer is yes, and in some cases they already are. Calls into the Graph API already happen over https. Calls into the old REST API don’t, but Facebook is ultimately going to deprecate this entire layer and probably doesn’t want to put any effort into it.

But since Facebook is already processing API calls over SSL, they could hypothetically use it for other purposes. Regular server-oriented SSL not only encrypts the channel, but also authenticates the server to the client. If you also use client certificates, the client authenticates to the server. A system like this could make Facebook’s system of Application IDs and Secrets unnecessary. They could be replaced by a system using SSL client certificates which would increase the security as well as providing a much larger degree of flexibility to make it easier to add features to it in the future.

* For the picture to accompany this post I was torn over whether to go with Emily Litella, Nirvana, or the Sex Pistols. I stand by my decision.

Here’s how you can test against the Beta Tier:

Run a second copy of your application

You’ll need to run a second copy of your application as a “regression test” in parallel with your “live” deployment copy. This is because you’ll need to make some fundamental changes to it that cannot be made to your deployment copy. In particular, any API calls that are made to *.facebook.com should be made to *.beta.facebook.com instead. This will allow you to use Facebook’s latest beta code, which is what you really want to test regression against. To do this, you’ll need to edit the libraries that you’re using to interface with Facebook and make this modification. Of course, this assumes that you have access to the source code of the library which interfaces with Facebook. If you don’t, then you’ll need to come up with something clever.

Running a second copy of the app will obviously mean that it must be hosted in a second location which means that it also must be registered with Facebook. Registering a second copy means that you get new Application IDs and secrets, which of course means modification to your sorce code.

At this point you’re going to need to be a bit careful because every time you make an update to your code, you should also update the regression test copy.  However, you’ll need to be careful that you don’t overwrite your changes that you’ve made to the ID/Secret or to the library. Perhaps you should consider stripping that code out into its own file so that it’s clear what should be overwritten and what shouldn’t. It’s also probably a good idea to copy things over automatically as part of your build/deploy process.

Choose an automation solution

Clearly you want the process of monitoring to be automated, so you’ll need to choose a solution to automate the monitoring. This can be a commercial solution or something you build yourself. The benefit of using a commercial solution will be that it can be done very economically and will be easy to use. Alternatively, if you want much more control, you can build your own solution around a system such as Selenium.

At this point you’ll also need to create a test user.  This is easy enough to do, but remember that you’ll need to add the user as a developer if the application is not public.

Create a test script

Creating a test script should be easy to do. How you do it, of course, will depend on the automation solution you’ve chosen. The difficult and more important thing to do here is to determine the list of actions that the script should contain. You should try to get coverage of all of the possible functions. If this isn’t possible, you should at least get coverage of all of the API calls that the applications makes, as well as all of the FBML tags used.

Execute, monitor and act

Now that you’ve got everything set up, sit back and let the monitoring begin. You’ll want to run your script whenever the Beta Tier is updated, so make sure you’re aware of when it’s going to happen.

Also remember that any changes you make to your app must be deployed to the beta test version also. Most importantly, when the system identifies some regression, stop whatever you’re doing and investigate.  Understand the reason for the regression and determine whether it’s real regression or simply a change in design and act accordingly.

Finally, watch the Facebook forums to see what’s happening and if other developers are experiencing any regression. If you find that your app has regressed, be a good community member and make sure you let others know so they can check their apps too.

Facebook changes that can break your application

Deprecated Functionality

Facebook does occasionally deprecate features in the system such as

• Methods (profile.getFBML)
• FBML tags (fb:add-section-button)
• FQL tables (The Metrics FQL table)
• Entire Functions (Datastore API)

Why does Facebook deprecate functionality? Well, we’ve already discussed that topic once, but the important thing to take away is that if they didn’t, the Platform would be a complete and utter mess.

It’s important to note that Facebook does give developers loads of warning when something is getting deprecated so that they’ll be able to fix it. It’s also true that when Facebook announces that they’re going to deprecate something, a grassroots outcry from developers can be successful in changing Facebook’s minds (e.g. admin.banUsers).

When Facebook does get around to formally removing a feature from the Platform it’s important that your application no longer uses it because it will break.

Modified Functionality

Something that typically flies under the radar is the fact that Facebook is constantly modifying Platform functionality in small ways every week. These modifications tend to be small: a changed default here, an added parameter there. Not huge changes, but changes nonetheless. Facebook even publishes this information in their Change Log.

So can these types of changes be breaking changes? Sure they can, depending on what your application does.

Bugs

Yes, it’s uncomfortable to think about it, but occasionally the Facebook developers introduce bugs into the Facebook Platform. This happens for many reasons, the most easily understood though is that the developers are people, and people make mistakes. Software development happens at Facebook at near breakneck speed, and occasionally bugs do enter into the code. Facebook also famously has no formal Quality Assurance team, relying on a system of peer code reviews instead. Depending on your development experience, you’ll probably have strong positive or negative feelings about doing things this way, but hey, it works for them.

Can something really break?

Uhhh… Yes. If you spend a little bit of time on the Facebook Forums or Googling for more information, you’ll easily find people talking about changes that Facebook made that broke their applications.

For examples, here are two that we easily found:

Facebook modifies a workflow that’s been in place for a while

Facebook introduces a bug in OAuth processing

The bottom line to all of this is that Facebook’s changes can cause regression and break your application even when you do nothing. In our next post we’ll look at strategies for using the Beta Tier to try to contain this problem.

My initial reaction is to answer “Huge!”, but I know that the question is really about quantity and not quality. Assigning numbers to these questions is often difficult, but the one “official” place to get statistics like this is Facebook’s Statistics page. Unfortunately Facebook updates the “big” statistics like the number of active users quite often, but the Platform stats has stayed static for quite some time. When I first began getting interested in the Platform two years ago, Facebook claimed that there were a million people worldwide developing for it. That number has stayed constant for a long time.

Until now. Facebook recently updated this page and now claims that 2.5 million of us are building on the Facebook Platform. However you look at it, that’s a pretty impressive number. They also claim that there are 20 million application installs done on the average day. Spread out over 500 million users, some quick math tells us that the average user is installing a new app once a month – also quite impressive.

Hopefully Facebook will update these stats a bit more often since they do show the viability for making a business case by working with the Platform.

Let’s contrast a Facebook app with a plain old Web Application. Imagine you’ve just finished designing and building your great new Web App. Before deployment you test every possible thing that could go wrong and you feel really confident about its stability and robustness. You’re so confident that it won’t break that you decide to relax and spend the next two weeks in Bora Bora without even a laptop. Things may go wrong, but if your app is really well-written, then all of the problems will be operational problems. Someone tripped over a power cord and knocked out a router, or spilled coffee into a server.  Things that are certainly problems, but they don’t need you the programmer to fix them. Go get yourself another drink and don’t worry about your app.

But Facebook development isn’t like that. You still need a good operations team to make sure your app stays online, but the stability and reliability of your Facebook app also depends on the invisible hand of Facebook, something that you have no control over. Before booking your flight to Bora Bora you’ll need to come to grips with the possibility that Facebook could very easily push out an update that changes an API in a way that breaks your application. If/when that happens to you, then you the programmer will need to do something about it to get your app back up and running again, even if it means getting up from the beach. And that’s the important point here: Facebook applications can and will experience regression even when they aren’t being changed because Facebook is always changing.

The first step to dealing with a problem like this is knowing that there is a problem. If you have a general Web App, knowing that it isn’t working isn’t so hard to do. You can simply set up a monitoring system to periodically hit the app and make sure that it responds properly. There are many inexpensive commercial services that make this really easy to do.

But what about Facebook applications? You can monitor the application to ensure it is up and running, but that won’t tell you if Facebook has done something to break it. That’s why Facebook’s Beta Tier is so valuable – you can find and fix potential problems before they get seen by users.

But how can we do this automatically? It would be great if we could set up an automated way to know that the next Facebook update will break your application. In our next post we’ll look at some strategies for how we can do this. In the meantime, leave a comment if you think this would be a good idea, and any thoughts you have about it.

The results of the poll should come as no surprise. Security/privacy is always a hot topic for Facebook, and saying that you’re not for better security is akin to also being against motherhood and apple pie. It’s true that there are malicious Facebook apps, but is a walled garden approach correct? I say no.

Let’s look at the facts. Apple has a great opportunity to wall off it’s garden with the App Store. If you’re a developer and want to distribute your app, you need to go through Apple. They’ll take it and verify (to some extent) that it isn’t malicious, as well as verifying that it fits into the Apple World View (i.e. no “bad stuff” or treading too close to something Apple wants for itself). Once done, it’s put on some server just waiting for people to download and use it on their iPhone.

That ain’t how Facebook works. Facebook apps are simply web applications that are proxied by Facebook. (I’ll just discuss Canvas apps here, as Connect apps REALLY can’t be policed) There’s no “server repository” for Facebook apps – they’re hosted by their developers on their own server equipment, Amazon AWS, Joyent, Rackspace, or any of the thousands of other places to host web apps.  It’s like this because that’s how the Platform is defined, and how it needs to be defined. If you don’t like that and want it changed, then you don’t understand how the Facebook Platform architecture works.

And that’s where the problems start if Facebook tried to “walled garden” its third-party developed Platform apps. Facebook cannot vet them like Apple vets iPhone apps because tomorrow the app can, and probably will change. Since it’s hosted externally, Facebook cannot control, or even know about this change. Even if Facebook threw lots of money at the problem and hired loads of people to vet every app that was put on the Platform, it would be really easy for malicious people to get around this.

So sorry Sophos, getting better security is what everyone wants, but Facebook cannot “walled garden” its Platform like Apple does because they’re very different. Comparing Apple to Facebook is like comparing apples to …. well, you get the idea.

FacebookCamp Toronto

Come on out, meet other developers, and learn a bit more about the Open Graph. We’ll be there hoping to talk with you about testing Facebook applications.