Notice: This blog is no longer updated. You may find a broken link or two

You can follow my new adventures @mikeonwine

The Facebook API revolution

September 25th, 2007

No, this isn’t another “OMG, the facebook API IS AWESOME” post. I mean, it is, it’s pretty damn cool, I’ve played with it a bit this month. The real revolution with the facebook API are the server-side requests.

Traditionally widgets & plugins interfaced with social networks by placing snippets of HTML on profile pages. In the Facebook world no content can show up on a user’s profile without passing through Facebook’s servers first. Even your actual application pages must either be within an IFRAME or pass through Facebook. This process provides Facebook with an extraordinary level of control over what can and cannot be displayed on a user’s page. FB can perform a virus scan on all content and analyze any scripts for vulnerabilities or exploits. By directly serving content Facebook also eliminates cookie access — making it far more difficult to track or distribute data about their users.

Yet, the approach has it’s limitations for application developers. I tried briefly to build a “stalker tracker” application which using cookies would tell the user how many people regularly checkout their profile page. No matter what I tried, I couldn’t get access to the cookie without somehow initiating a click — rendering my application completely useless.

Why should you care? Well — advertising isn’t that much different from a traditional social networking widget — both are delivered via a snippet of HTML. Online ads have also been plagued by security issues this past year and I wouldn’t be surprised if the bigger players (Myspace, Yahoo, MSN, etc.) start to ask for server-side ad-requests soon. Server-side requests are the only way that a seller can technically guarantee the safety of third-party ads. Of course this will open up a world of technical challenges — server-side cookies storage, strict global latency requirements and a need for increased capacity to only name a few.

Related Posts:


Posted by Mike Filed in ad networks, adserving, facebook, online advertising
9 Comments »

  • Frank

    Nice post Mike! I have a question for you though.. Forgive my ignorance but what exactly do you mean by the statement
    “I wouldn’t be surprised if the bigger players (Myspace, Yahoo, MSN, etc.) start to ask for server-side ad-requests soon”
    I was under the impression the “server-side ad request” process was inherent in the ad serving process. Meaning an advertiser’s creative generally passes through a series of servers before reaching the publisher’s web page. So i envisaged an advertiser’s creative gets uploaded to an ad serving company’s server i.e Doubleclick before getting served onto the targeted web page through the publisher’s server.
    If this is the case, don’t you think one of these “pass through servers” would have some form of virus detection software embedded in them to detect these threats.

  • Mike

    Actually no, currently many servers may be involved but they all pass through the browser. For example, if Myspace shows an ad to a user via the Right Media Exchange which then redirects the user to Avenue-A using Atlas, the following would hapen:

    - Browser requests page from Myspace
    - Myspace sends back html with iframe to RMX
    - Browser requests ad from RMX
    - RMX sends back html with iframe to Atlas
    - Browser requests ad from Atlas
    - Atlas sends back img tag referencing ad
    - Browser requests ad from Akamai

    Notice that Myspace loses all control once the page content has been returned and has no log or audit trail of what the RMX or Avenue-A may serve.

    -Mike

  • http://www.anchiva.com Mike T.

    Mike,

    Following on that last comment, we developed an ASIC based anti-spyware/AV appliance originally targeting large enterprises and universities. We scan HTTP traffic at gigabit speeds for over a million types of malicious code. Recently an adserver company has contacted us to see if they can leverage our technology to help solve just this problem.

    But it sounds like for myspace to be safe, they would have to have all their adserver folks on board with this type of solution, one box in front of x-servers.

    Please excuse my ignorance, I’m doing some background research and found the blog. I think our product might be adaptable to help solve this current problem.

  • Mike

    Indeed, an appliance such as yours would require server side ad-calls. I covered the traditional method of ad calls a while back in this post — http://www.mikeonads.com/2007/05/01/the-ad-exchange-model-part-i/

  • Frank

    Mike,

    Thanks for the feedback! I gather from your comments the ad serving process exhibits a lot of redundancies.
    I did some research on this site http://www.webmonkey.com/webmonkey/e-business/marketing/tutorials/tutorial1.html
    and discovered there are numerous 3rd party softwares that could reduce if not eliminate the redundancies.

  • Mike

    Didn’t read the full tutorial but I wouldn’t trust it too much. That’s a VERY old article referencing doubleclick network & Windows NT 3.51.

  • Frank

    Mike,

    Do you have an opinion on the DoubleClick Ad exchange?

    Here is a link to their demo
    http://www.doubleclick.com/products/advertisingexchange/demo/demo.aspx

  • http://www.zip-repair.org/ zip recovery tool

    GReat information, very useful for all us

  • http://www.zip-repair.org/ zip recovery tool

    GReat information, very useful for all us