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.