On October 1, 2011, Facebook will make a mandatory change to all applications, as per the Facebook Developer Roadmap. Any affected application not updated before the change will become inoperable.

It is imperative that you audit any/all client Facebook apps/experiences in order to ascertain if they will be affected by these changes. Again, these changes must be made to existing Facebook applications (or inserted into current build plans for applications) – if not, these client applications will be rendered inoperable as of OCT 1.

We are sending this out now as the supported toolkits from Facebook were just updated and released and are now ready to be implemented against.

Recommended Audit steps:

1. Identify and list all programs with Facebook integrations.
2. Identify programs that will continue to be live after September 30, 2011.
3. Work with your program’s associated tech resources to identify if program will be affected.

Facebook Security Update FAQ

Why is this happening?

Facebook has recently been the subject of many concerns about the level of security around the exchange of personal information with applications. This is an effort by Facebook to shore up their interfaces to prevent any exploitation.

Is this optional?

Unfortunately, Facebook has made this non-optional. Historically, Facebook has basically had the approach that changes like these have been part of the ‘cost of doing business on Facebook.’ They move fast, and expect you to also.

What will be affected?

Any application on:

• Facebook Pages
• Facebook Canvases
• Non-Facebook site (minisite, client’s .com) using Facebook Connect

and using:

• IFrames
• OpenGraph
• Facebook SDKs
  • Official
    • PHP
    • Javascript
  • Unofficial
    • Java
    • .NET
    • Ruby
    • Etc.

What will not be affected?

1. Much older FBML applications – predating IFrame switchover.
2. Site integrations limited to Facebook Social Plugins (Like buttons, Send buttons, etc.) that don’t do deeper Connect/OpenGraph integration.

What changes need to be made?

All applications must have valid SSL certificates and be configured to use HTTPS. This requires acquiring certificates and working with associated IT resources to install on the servers where the program is hosted. These certificates cannot be “self-signed” and must work with any modern browser without it complaining.

Integration code must upgrade to OAuth 2.0 and associated new Facebook authentication:

• Apps using PHP SDK update to latest official Facebook PHP SDK and make minor code changes.
• Apps using Javascript SDK update to latest official Facebook Javascript SDK and make minor code changes.
• Apps using other SDKs must update in whatever manner appropriate.

In the Facebook developer console, under “Settings -> Advanced”, enable “OAuth Migration”.

What do we do if our app is hosted by a social app vendor (Involver, Buddy Media, Wildfire, Vitrue, etc.)?

Reach out to the vendor and ask them if they have a plan in place for the “Facebook OAuth 2.0 and SSL changes”.

It might be an annoying change to have to make but it’s nice to see Facebook putting some thought into privacy protection. What are your thoughts on the upgrade?

A new application hit Facebook called the Friend Network Optimizer sponsored by SAP. It has grown in popularity even though it is such a brand new application. The tool works by telling users how active they are on their Facebook compared to a portion of a social graph. While it may not seem like much at first, this tool is quite interesting to use. It has spread so quickly because it immediately posts feed stories when a user installs the application, therefore generating more users to sign up.

The fact that this Facebook app has done so well is due to the way that it has worked around the Facebook permission tools. Users now need to accept all or none of the app’s usage at the time of installation. Could this be good for developers? Yes, it most certainly is. This allows for a way to grow application demand without spending a small fortune on ad buys.

Friend Network Optimizer is interesting itself because it does provide some data including status updates and photo upload data that can help users to determine where they rank. It is also interesting to check out active other users are, too.

According the the Facebook Developers blog, Facebook is now granting developers on Platform the ability to request (or require) users to hand over their email addresses. By doing so, developers can begin sending periodic messages directly to users.

This actually doesn’t come as a surprise: Facebook initially talked about e-mail requirements last October and has kept developers updated on the timing in its Developer Roadmap. All of that said, this is a big deal!

Up until now, Facebook applications have used the notifications window (that slide up panel in the bottom right hand side of the screen) to engage users on an ongoing basis. Facebook is removing that functionality in the next thirty days. Moving forward, Facebook will no longer be the gatekeeper for communications between developers and users.

In order to collect Email addresses, Facebook developers will prompt users through an extended permission box. For those concerned with potential spam, they can elect to only share a proxied Email address – similar to the ones you can get when posting items on Craigslist.

Below is an example of what a developer e-mail can look like: