Positive Privacy News From Facebook

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.

Facebook Platform as walled garden – How Sophos got it wrong

Graham Cluley from Sophos, a leading internet security company, recently published a piece entitled Facebook users call for application “walled garden” to protect against attacks. In it, he asks the simple question: ”Should Facebook follow Apple’s example, and have a ‘walled garden’, verifying all apps?”. 1025 of his blog readers responded to the poll, 95% of them with YES!

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.