Achievers Tech Talk – Social Product Design Tips from Facebook

These are my long lost notes from the presentation. They are missing lots of context.

Why be social?

  • We talk to help
  • We talk to craft our identity like Rap Genius founder
  • We talk to build relationships over time
  • The amount we share is proportional to the value of sharing


  • Identity is multifaceted. Different apps and people show different slices of life.
  • Audiences inform content. You say different things to different people. A more specific the audience = more filters

Things Facebook notices

  • We choose pictures over words
  • Lightweight communications like Yo
  • Objective based networks like Nike+
  • Pick the right medium for what to communicate.
  • Augmenting offline experiences like matching blood donor s and AirBnB
  • Info about people traveled faster than people


  • Get inspired by Urban Planning books. Courtyard and cities are the social network
  • Check Munk Debates for an interesting debate between Alexis Ohanian and some dude from the CIA on surveillance

Social Product Design Tips from Facebook

Wednesday, Jun 18, 2014, 6:00 PM

Achievers InCenter
190 Liberty Street Toronto, ON

140 Members Went

What do the best social apps have in common? They understand how people communicate with each other and develop technology to better facilitate these natural interactions. Facebook has built and enabled some of the most powerful social apps in the past decade and in the process gained a better understanding of human behavior and where technology ad…

Check out this Meetup →

Safari, 3rd party cookies, and Facebook apps

The default settings for the Safari web browser block 3rd party cookies. This means that web apps hosted on will not be able to set cookies when displayed within an iframe in a Canvas App ( or Page Tab. Problems ensue when the web app relies on cookies for sessions and CSRF checks.

Here is an ugly but functional fix. When the page first loads within the frame, check if any cookies are set. For example, a Laravel-based site might use this PHP code in a before filter:

if (count($_COOKIE) === 0) {
     return '<script>top.location = ""</script>';

This will redirect the user out of Facebook and into a page on where the web application can set cookies as the 1st party instead of the 3rd party. With Laravel, the session token and payload cookies are set automatically at this time. Then page writes out the following code in the HTTP response to redirect the user back into the Facebook app:

'<script>top.location = ""</script>';

With a broadband connection and healthy web server, the redirect happens so fast on a speedy site that most people do not notice the URL changing to from a Facebook URL to an external URL and back. This time when the check for cookies returns a number > 0, the app continues as usual. In my experience, the app is able to make changes to the cookies now as well.


This quick fix does not cover situations where the user is landing on a page deep in your app. If user visits, they will be redirected back to after the cookie is set. This can be fixed by saving the full URL the user landed arrived at without cookies, and returning the user to that URL instead of

This fix will also put users who have intentionally disabled cookies into an infinite loop of redirects between the Facebook app and /cookieredirect page. Whether or not this is an issue for your app’s audience is up to you. A way to prevent the loop may be to store the number of times the user has gone through the redirect, and send the user to a page that doesn’t redirect them again if they have gone through it more than once without the cookie being successfully set.

An Alternative

An alternative to the redirect is to briefly open a popup window containing your own site, and use a similar behaviour as the /cookiefix URL to set cookies, and then close the popup. Use an interaction like a click to open this popup, otherwise Safari may block it.

Related links:
Discussion on Stack Overflow
Another discussion on Stack Overflow

fix FB.getLoginStatus() called before calling FB.init()

To fix this error, I had to take a second look at my FB.init code.

I had just moved a site to a new server, and started seeing the error in Chrome’s dev console. The all.js file loaded successfully, so that wasn’t the problem. I blamed Facebook for a few minutes and then spotted the problem after looking at my page’s source:

  appId      : '', // App ID
  channelUrl : '[an ok value]', // Channel File
  status     : true, // check login status
  cookie     : true, // enable cookies to allow the server to access the session
  xfbml      : true  // parse XFBML

appId was blank because the server-side code that defines it could not pick an appId after the move. When appId was corrected, everything worked again. Beware of the blank appId. It happened to this guy too.