Facebook can and should do more to proactively protect users

A few days ago, the Wall Street Journal revealed that Facebook apps were leaking user information to ad networks. Today, Facebook proposed a scheme to address this issue. This is good news, but I’m concerned that Facebook’s proposal doesn’t address the underlying issue fully. Facebook could be doing a lot more to protect its users, even without giving up on their highly-targeted advertising business model.

what, exactly, is going on

First, let’s spend one minute describing the problem, because the WSJ’s description was somewhat inaccurate. Harlan Yu at Freedom To Tinker does a good job describing the situation: Facebook loads some apps in IFRAMEs, which means they embed the web page of the app within their own. The user ID is included in the URL of the IFRAME, so that the app might know who is actually using them. The app might then include another IFRAME with ads, or some JavaScript from an ad network. When your browser fetches that ad IFRAME or JavaScript, it includes, in its request, the URL of the page that referred the browser to the ad network. In this case, it’s the app’s URL, which unfortunately includes the user’s Facebook User ID, which reveals all of the user’s public information, including their name and possibly more.

So, to be fair to Facebook and the apps: they probably didn’t do this on purpose. The WSJ’s specific wording, “transmitting”, is misleading, because it assigns intent where there probably wasn’t. That said, I don’t think Facebook is off the hook: when you run a 500M user platform, it’s your responsibility to protect your users’ privacy before the story breaks. To their credit, Facebook is taking this seriously and is proposing a way to remedy this problem that is not cheap for them, as it requires changing the way that they interface with applications.

encrypting the user ID

Facebook is proposing encrypting the user ID before adding it to the app URL. The app’s backend server then must decrypt the user ID before it can use it to retrieve more information. That way, if that encrypted user ID is leaked, the ad network won’t be able to make sense of it. Interestingly, the encryption changes every time an app is launched, so the ad network won’t even be able to correlate two visits by the same user (unless they set a cookie, of course, so maybe that’s not a very strong defense.)

Now, a couple of points in this proposal worry me, because they might indicate that no trained cryptographer reviewed the proposal (Chris Shogoian asks this very question on twitter). First, the same key is used for HMAC signing and AES encryption. That’s bad practice, because AES and HMAC have been analyzed in isolation, not when both are used with the same key. It’s not that there’s an obvious attack, but it’s sloppy because it uses AES and HMAC without following the strict specifications under which we have strong evidence that they are secure. Second, AES-256 is used with a key that is effectively a 128-bit key expanded to 256 bits by hexadecimal encoding. That’s just ugly. Oh of course it’s because apps already have a hex-encoded 128-bit key, so it’s easier that way, but again, AES-256 has not been strictly analyzed for security in the case of a key with only 128 significant bits. Crypto algorithms are not magic black boxes you can use any way you please. It’s best to use them as prescribed. So that’s a bit concerning mostly because of what it implies: this proposal has not been seriously reviewed by a cryptographer.

But there’s something else that bugs me.

hiding the user ID from apps altogether

Clearly, Facebook is only addressing the threat of accidental data breach. A malicious app could easily decrypt the user ID and communicate it to the ad network if it wants to. Of course, that violates the Facebook terms of use, but as we’ve seen already, who’s going to check? The same privacy expert who missed this problem in the first place?

As long as Facebook is redesigning its API for privacy reasons, why not consider a more complete threat model? Two companies, each with their popular Facebook app, might connect their databases and correlate what users are doing on both sites, thereby learning more about the user than he/she may realize. Encrypting the user ID prevents accidental leakage, but in the end the apps are able to decrypt the package and store the one and only official facebook user ID for each user. Leaking the real user ID, accidentally or because of evil intentions, remains eminently possible.

Instead, Facebook should provide a different user ID alias to each app. The app never receives the real unique ID for each user, only the app-specific alias that cannot be correlated against a different app-specific alias for that same user using a different app. Then, the app can make API calls into Facebook using this alias, and the alias, if leaked, is useless to any other party, since it is only meaningful as part of API calls signed by the original app.

Aliasing of user IDs is not new: OpenID uses it to provide different identifiers to different sites where you log in, and in the specific case of Facebook this aliasing idea was described two years ago by Adrienne Porter Felt. Now, that alias may be obtained by encryption, but in any case the decryption key is not available to the app. To the app, the alias is the only user ID available.

proactively protecting users

With their reach and impact, it’s just not good enough for Facebook to blame the browsers or the state of the Web for privacy leaks. There is much they can do to ensure that, even if apps screw up or even turn a little evil, the platform is proactively protecting users from potential privacy leaks. Sure, the WSJ article wasn’t fair in its wording. But users are entrusting Facebook with incredible amounts of data. Facebook can and should do a lot more to stay ahead of potential privacy leaks on their watch.