Understanding Facebook Application Privacy, Part 1

Written by theharmonyguy, 26 July 2009

Geek Level: A bit technical at times, but written for a general audience.  Don’t get hung up on details.

Information Access

When you use a Facebook application, you let that application access most of the information on your Facebook profile.  But how does an application get that data, and how does the application use it?

Applications are special sets of web pages that interact with Facebook, but are not actually written by or controlled by Facebook.  Most of the games, quizzes, and polls you see your friends using on Facebook are applications.  Anyone can write an application and put it online without having to get approval from Facebook.  But an application does not have access to your profile until you click “Allow” on the install page.

Now imagine that Facebook is a special kind of warehouse of data, and applications are members who which to access parts of that data.  Most controlled facilities require you to show some sort of ID or a keycard to authorize your access, and many make you sign in to record your visit.  In a similar fashion, applications have to “sign” their requests for your profile.  Instead of checking an ID card, Facebook checks the signature against a special code known as a secret.

Keeping Secrets

Every application has its own individual secret, called an application secret.  This code is kept on the computers that run the application and should never be given to other people, as one can modify the application itself using the application secret.  Whenever an application asks for your profile from Facebook, they use their application secret to sign the request, proving they’re an application with legitimate access.

Figure 1: An application secret lets an application properly sign requests for your profile.

Figure 1: An application secret lets an application properly sign requests for your profile.

If a program tried asking Facebook for your profile without having any secret, they would not be able to give the right signature to gain access.

Figure 2: Without any secret, an application cannot give a valid signature.

Figure 2: Without any secret, an application cannot give a valid signature.

Facebook lets applications use one other kind of secret, though, called a session secret.  When you are actually using an application, Facebook creates a temporary code that can also be used to sign requests for your profile.  This proves handy for certain types of applications, as they are actually two different ways to structure a Facebook application.

Figure 3: A session secret is only temporary, but also provides a valid signature.

Figure 3: A session secret is only temporary, but also provides a valid signature.

Two Structures

The first kind of application is known as an FBML application.  “FBML” is simply a name for certain kinds of code used in such an application.  Figure 4 illustrates how this style application works.  When you request a page for the application from Facebook (1), they let the application’s computers know (2).  The application can then use their secret to ask Facebook for your profile (3), and Facebook gives the application whatever data it asks for (4).  The application uses that information to create the page you wanted, and sends the page back to Facebook (5).  Finally, Facebook sends the page back to you (6).

Figure 4: When you open an application, the pages you see often go through Facebook before reaching you.

Figure 4: When you open an application, the pages you see often go through Facebook before reaching you.

This setup lets applications have Facebook do part of their work for them.  When the application sends the page you want back to Facebook (5), it can ask Facebook to fill in more data or add boxes that look like the rest of Facebook.  Also, Facebook can check the page for code that might mess things up.

The second type of application is called a canvas application.  When you visit these applications (1), Facebook sends the application a request (3), and it again interacts with Facebook using the application secret to load your profile (3, 4).  But when the application is ready to display, it sends the output directly to your computer (5) instead of going through Facebook first.

Figure 5: Some applications talk to your computer directly when you open them.

Figure 5: Some applications talk to your computer directly when you open them.

If every interaction with an application required Facebook to call the application, which then loaded your profile again, then sent the output back, it could get annoying.  To save time, many applications include code that runs on your computer once it loads a page.  If this code included the application secret, anyone could find it on their computer, and the application would not be secure.  Instead, this code uses the session secret to load data from Facebook.  Figure 6 illustrates how this works for a canvas application.

Figure 6: Applications can run code on your computer that employs the session secret; this illustrates the process for a canvas application.

Figure 6: Applications can run code on your computer that employs the session secret; this illustrates the process for a canvas application.

Third-Party Code

Applications often include code written by people other than the application developer. This includes code to makes common tasks easier and code to load advertisements.  Frequently, the code is stored in a file on a separate web site, and the application simply calls it from there.  In this case, the outside code does not have access to any secret, and thus no direct access to your profile.  An application could send data to the other web site, though that would violate Facebook’s rules for applications.

Figure 6: When an application uses code stored elsewhere, the third-party code does not get any secret.

Figure 7: When an application uses certain files stored elsewhere, the third-party code does not get any secret.

Another way to access outside code involves creating a file stored on the application’s web site.  Since this file is stored on the application’s web site, it automatically has access to the session secret.  If the local file then calls for outside code, that code can also access the session secret.  The third-party web site can then load your profile from Facebook using the session secret.  This setup also violates Facebook’s rules for applications, but it can still happen.

Figure 7: An application may include code stored locally that gives a session secret to a third party, which could then request your profile from Facebook.

Figure 8: An application may include code stored locally that gives a session secret to a third party, which could then request your profile from Facebook.

Finally, developers often use one more method to use third-party code, shown in Figure 9.  After you open the application (1, 2), it asks an outside web site for code (3), but the code is sent directly to your computer (4).  From there the code can talk with Facebook using the session secret (5, 6).  As with the session secret, this code is temporary, and stops running on your computer when you close the application.

Figure 9: The application can have third-party code sent directly to your computer.

Figure 9: The application can have third-party code sent directly to your computer.

This setup helps an application use outside code in many ways without breaking Facebook’s rules for applications.  Since the third-party code runs on your computer, all of the data it requests from Facebook goes straight to your computer and not the outside web site.  Of course, the code could then send information to other web sites.  This would again violate Facebook’s rules for applications, though since the application developer does not fully control outside code, it could happen without the developer knowing it.

In part 2 of this series, we’ll look at what specific pieces of your profile applications can access.