From Facebook Developer Wiki

This policy is going to be a problem for many useful apps. Is it possible to refine it further?

For example, I have a widget in mind (a crucial part of my product roadmap) that would work in an iframe on a hosting site. The whole *point* of the widget is to make it ridiculously easy for the hosting site to include this functionality: one script inclusion and some optional Javascript parameters to define the iframe and context, and it's off to the races. The host doesn't need to do anything except add that bit of boilerplate Javascript.

This iframe would be explicitly branded as my app, which provides communication services for websites and is a completely obvious Facebook Connect target. It would be quite explicit to users that they are working with this app -- indeed, that's a major part of the value proposition for the users. But there's obviously no way for that to show in the browser's address bar, since it's in an iframe. (Indeed, that URL in the address bar is the *context* that the app is working within, and is vitally important.) And my app's servers need to be connecting directly to Facebook in the context of this user: the user's identity is used to define his interactions with the conversation that we are mediating.

So what do we do? This is an app that is pretty clearly useful, opt-in, branded and non-abusive -- it fits with the spirit of what Facebook is trying to accomplish quite well. But it's absolutely hosted on my site: doing it as a code-provided plugin destroys the ease-of-implementation that is key to adoption.

So please: think through the iframe equation. I think it's quite possible to find a middle-ground option here, that allows iframe-based plugins to work without sacrificing user clarity...

708978571 09:26, 17 December 2008 (PST)