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
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
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.