facebook

Via Slashdot I see that folks are finding new things to dislike about Facebook's privacy-threatening Beacon initiative. This PC World article relates that Beacon transmits data from Epicurious back to Mr. Zuckerberg & friends even when the user is logged out of Facebook.

My first thought was that this objection might be silly: if Epicurious is serving the Javascript that sends the AJAX request (via some sort of XSS technique) there should be no way for Epicurious to detect whether a user is logged into FB or not. Doing so would violate all sorts of other, more important security principles — the sorts of ones that prevent me from writing some Javascript to, say, have this page read that open Gmail session one tab over and report its contents back to my hidden lair.

But sure enough, the Beacon Javascript is being served from Facebook.com, which means that your session cookies are perfectly available to it. Epicurious pulls the Beacon code from the following URL:

http://facebook.com/beacon/beacon.js.php?source=5194643289

And yeah, it serves exactly the same code regardless of whether my browser is logged into FB or not.

So this story's legitimate: Facebook could turn off Beacon for logged-out users with something as simple as two lines in .htaccess. Based on this example, here's a snippet that would check for Facebook's h_user cookie, if they wanted to:

I haven't got a lot to add to this TechCrunch post other than to say that I find it immensely cheer-inducing. There are a lot of unknowns surrounding the OpenSocial platform, but its looming marketshare at least makes it seem likely that I'll be able to avoid learning any more bowdlerized web technologies with "FB" at the front of their names.

FBML, FQL, FBJS — it was getting out of control, and it all stinks of proprietary lock-in and a rather lame (but admittedly necessary from a security standpoint) attempt to wrap the LAMP stack under a layer of branding. That's not to say that every technology coming out of Facebook is worthless — I've heard some encouraging things about Thrift from people I respect (although if you're not in the market for an especially high-performance RPC framework, using something established like XML-RPC still seems like a better idea to me).

But Google's got a fairly good track record of only reinventing the wheel when they need to build a particularly enormous wheel. So cheers to this potential game-altering alliance. I want APIs, not languages; interfaces, not environments.