Monday, April 13th, 2009

oFrameBust: Proposed Protocol for iFrame Choice

Category: JavaScript

We’ve all seen iframes used in an attempt to allow you to surf away from site A to site B whilst still allowing site A to inject some sort of presence into the experience. As Marcus Westin puts it:

“iframing” by some, e.g. facebook and digg, adds value to your site; iframing by others, e.g. meebo.com.br, detracts value. There is no way for the user to pick and choose, because of cross domain policies.

Marcus has an idea for solving this problem:

Say digg.com wants to iframe http://blog.narcvs.com/?p=55. I permit this, along with say facebook.com and marcuswestin.com, but I don’t want anyone else to iframe my site. On blog.narcvs.com, I just include the oframebust script and list the domains I want to allow:

  1. <script type="text/javascript" src="http://oframebust.com/oframebust.js">
  2. oFrameBust('digg.com', 'www.facebook.com', 'www.marcuswestin.com');
  3. </script>

Then when digg wants to iframe me, they pass in the oframebust parameter declaring their domain:

http://blog.narcvs.com/?p=55&oframebust=digg.com

The oframebust script automatically detects the oframebust GET parameter, and uses it to create an iframe to http://digg.com/oframebust.html – since this page lives on the digg.com, it is allowed to read the top.location.hostname – if the top frame indeed is digg.com!

Read more about it in Marcus’ announcement post. As he explains in the post, his protocol succeeds only if the iframers and the iframees both pick up and run with the idea.

oframebust succeeds or fails with the community, and I would love to see if we can get people to start using it.

Posted by Ben Galbraith at 11:00 am
6 Comments

++---
2.7 rating from 20 votes

6 Comments »

Comments feed TrackBack URI

@Schill I think you’re right – I completely overlooked referrer while playing around with this, and assuming that it work reliably for iframes across browsers and cannot be spoofed, there is really no need for oframebust!

One problem it could still potentially solve is the issue of removing the bar once the user navigates away. Could we perhaps use it to communicate to the top frame that the user has navigated away to a new page?

Cheers,
Marcus

Comment by narcvs — April 13, 2009

Check refer[r]er header on the server. If it matches a blacklist entry, add simple frame escaping Javascript code along with a backup to apply the necessary CSS to hide the page and replace it with whatever.

Comment by Darkimmortal — April 13, 2009

Ugh — I’ll just stick to my old-fashioned frame breakout for all sites — I can’t stand when sites do this, as it breaks NoScript’s functionality for me.

Comment by mdmadph — April 13, 2009

@narcvs: For removing the bar on links within your site when framed, assigning links’ targets to point to _top might(?) work if you really wanted to break out of the frameset only when leaving the present page.
 
Placing sites in an iFrame is also part of how clickjacking attacks are set up, so it’s probably a good thing that NoScript blocks them. (Presumably only when they point to 3rd-party domains, I’m not familiar with how it works.)

Comment by Schill — April 13, 2009

“‘iframing’ by some, e.g. facebook and digg, adds value to your site”

It does? Is that greater than the value it detracts by link stealing?

Comment by jtresidder — April 14, 2009

Anyone?

Comment by jtresidder — April 15, 2009

Leave a comment

You must be logged in to post a comment.