K&R and thoughts on the Graph API

With this post I’m going to do something I promised myself I wouldn’t do while writing this blog - kvetch like an old grumpy man. But there’s a point:

While I was in San Francisco for f8, I had the good fortune to attend an informal meeting of Facebook developers to discuss the changes to the Platform that were announced at f8. It was graciously hosted at the offices of one of the leading Facebook development companies in the city. They were beautiful offices high up in an historical building with great views, and more Red Bull than a developer could drink.

While there, I noticed a copy of the iconic Kernighan and Ritchie (K&R) book on the C language sitting on a desk. What transpired was a short conversation between myself and one of the employees of the company:

Me  : Very impressive, someone still reads K&R.
Him : <Blank Stare>
Me  : The Kernighan and Ritchie book on C – it’s a classic
Him : <Blank Stare>
Me  : You should read this book, it’s so beautifully written. Look how thin it is, and the whole language is thoroughly described with examples and exercises.
Him : Yeah, the Rails documentation is much thicker
Me  : <Blank Stare>
Him : That’s our CTO’s desk – it’s probably his book

Okay, so the point here is that I’m realizing that you can actually get a degree in Computer Science without ever reading K&R. Without learning C. Without really understanding what goes on at all levels inside the computer without it all getting abstracted away. I was starting to feel bad that this whole drag-and-drop Rubyization of the world was creating developers who weren’t grounded in the basics. Who didn’t deeply understand how to properly analyze an algorithm. And who probably didn’t read stuff from guys like Joel Spolsky who kvetched about it all.

But then something else crossed my mind. The reason I love C and K&R so much is because it works on so many levels. You can use it to develop (practically) on the bare metal. You can use it to write customer-facing applications. You can use it to build a server. However, it’s becoming true that the higher off the metal you get, the harder it is to use C (or even C++). Web apps, Application Servers, Multi-tiered architectures, virtualization – all of these things are so much easier to do with more “modern” languages. And you know what, I’m okay with that.

So here’s my wish: Go get a copy of K&R and read it. I used to own 3 copies: one for work, one for home, and one for lending out. Even if you never plan to use C, please read it. It’s the best technical documentation you’ll ever read, and something you should aspire to. And the reason this is true is that the language is robust and, most importantly, simple.

Which brings me to the new Facebook Graph API and the way it simplifies everything. I think we should all say Hurray. K&R reminds us that simple does not have to mean not powerful. And what the Facebook guys did with this API reminds me of what Dr. Kernighan and Dr. Ritchie had done previously. Go read the book so you too can be inspired to continue building things that are both powerful and simple.

Postscript

For sheer entertainment value, you can’t beat the first version of the Java Language spec. In particular, check out the index entry for index entries to see all of the great references they included, and see how many you can understand. Their description of multiple inheritance (Section 20.3.5) is inspired, obscure, and absolutely brilliant.

The new Facebook Graph API

I’ve been listening very closely to the sessions at f8, and you know what? No location API. I’m not sure why, perhaps it will get released later. So what did we get instead?

The Graph API.

Very very cool. You need to read up on this, it changes the way that Facebook development happens from here on in. You no longer need to read a whole PHP API. You don’t even need PHP! Everything is based around RESTful APIs, so your favorite language + curl (or just use Java where everything is already included!) is all you’ll need to be a Facebook developer.

The old API will still work, as will FBML, FQL, etc. However any new development should be done in the new style API, it will be much easier.

Check it out – you’ll like it.

Why is an Application Secret secret? (Part 1)

Facebook Application Secrets, along with API Keys, are familiar to Facebook developers – we copy them into our source code so that our apps can connect to the Facebook servers, but do you know their role in the Facebok platform, and how they work?

What’s an Application Secret for?

The Application Secret has two main purposes:

• Mutual authentication between the Facebook servers and your application
• Ensuring the integrity of the data passed between them

These benefits look a lot like the benefits of using SSL, although SSL adds the additional benefit of data encryption. And yes, SSL is typically authenticated only one way (server to client), but client-side certificates allow that authentication to be mutual. If you’re a little shaky remembering what SSL is all about, you can refresh yourself here.

So why did Facebook engineers choose not to simply use SSL to communicate with applications? Why did they instead create a rather baroque system that relies on Application Secrets?

Why is authentication important?

Clearly, ensuring that any passed data has provable fidelity is very important. But why do we authenticate? Who would try to impersonate the Facebook servers or an application? Let’s take a look at the reasons to authenticate in each direction, and we’ll see why it’s so important.

Authenticating the Facebook Server to the Application

There’s very little value for a hacker to try to convince your application that his server is a part of the authentic Facebook infrastructure. In fact, the only reasonable attack is a Denial-of-Service attack to try to shut your application down (from perhaps a competitive application). If a hacker  who learns the URL of your Canvas application (i.e. the Canvas Callback URL) pretends to be the Facebook server, he could launch loads of requests to your application until it becomes saturated and crashes. Of course, your app can detect this because only the real Facebook server can authenticate itself to your application with your Application Secret.

Aside from this, it’s hard to imagine why anyone would launch an attack pretending to be a Facebook server. Perhaps hackers are more creative and will come up with reasons to do this, but they won’t get past the authentication stage.

Authenticating the Application to Facebook

In contrast, there are many reasons  that a hacker can try to impersonate a popular Facebook application. Without authentication, the hacker can easily run a man-in-the-middle attack by positioning his application between the Facebook servers and the authentic application. Then the hacker can alter any data that the application creates that is destined for the application user’s browser. If the attack and data is malicious, this can damage the user’s computer, as well as the application developer’s reputation if the modified data displeases the application user. Of course, since all the mischief goes on behind the scenes, disconnected from the user’s browser, there’s no simple way for him to know that anything has gone wrong.

Additionally, without authentication, a masquarading application could asynchronously query the Facebook server to get all of the private information that a user has shared with the application. The user opts in to share this information with a known and trusted application – he doesn’t expect it to be available to some hacker who gets it by devious means.

So keeping your Application Secret secret is pretty important. Important enough that Facebook forbids you to share it (Section 3.7 of the Developer Policies). In our next installment, we’ll discuss the dangers of Application Secrets, and how hackers can attempt to get yours.