January 27, 2008
@ 02:34 PM
Comments [1]
The Facebook Javascript Library: Learning from the Beacon Fiasco

Two seemingly unrelated posts flew by my aggregator this morning. The first was Robert Scoble’s post The shy Mark Zuckerberg, founder of Facebook where he talks about meeting the Facebook founder. During their conversation, Zuckerburg admits they made mistakes with their implementation of Facebook Beacon and will be coming out with an improved version soon.

The second post is from the Facebook developer blog and it is the announcement of the JavaScript Client Library for Facebook API which states

This JavaScript client library allows you to make Facebook API calls from any web site and makes it easy to create Ajax Facebook applications. Since the library does not require any server-side code on your server, you can now create a Facebook application that can be hosted on any web site that serves static HTML.

Although the pundits have been going ape shit over this on Techmeme this is an unsurprising announcement given the precedent of Facebook Beacon. With that announcement they provided a mechanism for a limited set of partners to integrate with their feed.publishTemplatizedAction API using a Javascript client library. Exposing the rest of their API using similar techniques was just a matter of time.

What was surprising to me when reading the developer documentation for the Facebook Javascript client library is the following notice to developers

Before calling any other Facebook API method, you must first create an FB.ApiClient object and invoke its requireLogin() method. Once requireLogin() completes, it invokes the callback function. At that time, you can start calling other API methods. There are two way to call them: normal mode and batched mode.

So unlike the original implementation of Beacon, the Facebook developers aren’t automatically associating your Facebook account with the 3rd party site then letting them party on your data. Instead, it looks like the user will be prompted to login before the Website can start interacting with their data on Facebook or giving Facebook data about the user.

This is a much better approach than Beacon and remedies the primary complaint from my Facebook Beacon is Unfixable post from last month.

Of course, I haven’t tested it yet to validate whether this works as advertised. If you get around to testing it before I do, let me know if it works the way the documentation implies in the comments.


 

Categories: Competitors/Web Companies | Platforms

« Digg Undermines Its Social Networking Fe... | Home | Microsoft Proposes Acquisition of Yahoo!... »
Sunday, 27 January 2008 21:42:04 (GMT Standard Time, UTC+00:00)
Dare, sure, this is an improvement, but still not very good.

These kinds of delegated authority mechanisms (OpenID, etc.) might solve the problem of ID proliferation, but, IMHO are fundamentally less secure.

These mechanism, regardless of how technically secure (SSL, sign-in seals, etc.), make Social Engineering that much easier. How hard would it be for a Phisher to spoof the Identity Provider? Trivially simple when the context of the interaction varies with each app.

More here..

http://whohastimeforthis.blogspot.com/2005/07/easy-pickings-for-bank-robbers.html

It’s bad enough when a site I know (LinkedIn/FaceBook/etc. for example) asks for my credentials to check my address book etc. It’s entirely different when a familiar widget app shows up someplace unknown to me. The number of users that would get Phished from this would be astonishing.

I don’t trust the sites I know about let alone some random site purporting to be running Scrabulous.

I don't think there is an easy answer to this problem. If there was, it would have already been solved.
Chris Marino
Comments are closed.