Don't have a sabot handy? Here, take one of mine.

Mon, 26 Nov 2007 11:39:28 +0000

RadiantCore do a thorough deconstruction job on Facebook Beacon with a detailed explanation of how it works under the hood.

A couple of things occur to me based upon their detailed analysis:

1. It wasn't implemented this way purely because of engineering effort.

Q: How much harder is it to make a web service call than to embed a javascript call and metadata in your pages? A: No harder at all.

Since I am doing this myself at the moment in an application I am building I can tell you it's absolutely no harder to make a web service call than embed a javascript file.

What using a web-service would have done, however, would have been to make it far harder to adopt the opt-out approach they have taken. Breaking XSS to make opt-out possible should tell you something.

2. URL based blocking of beacon is not a proper answer.

Smart users of Firefox can use URL blocking to prevent Beacon requests from being made. But the Beacon URL format is not fixed in stone, not every browser can do this, and I think it creates a sense of false safety.

One other thing that is less clear but may be possible:

3. Instead of following an opt-in, web-service based, approach Facebook have gone out of their way to circumvent browser cross-site scripting protection. I'm not saying this creates potential problems but it seems to me there is a risk that Beacon could be exploited. We'll have to wait and see. If there are problems then telling people to "Log out of Facebook" sounds pretty weak to me.

The way Beacon has been designed, the choices they made, seems to me to highlight an intent to make it as easy as possible for Facebook to exploit its users whether they want to be exploited or not.

For those people who are happy to trust Facebook go head, but don't say you weren't warned.

Curiouser and Curiouser! on beacon

Don't have a sabot handy? Here, take one of mine.