Looking at a few advertising companies (DoubleClick, Atlas), I've come across the concept of iframe buster files, that are hosted on the same host as the ad publisher (one example: http://www.adopstools.com/ibusters/atlas/atlas_rm.htm, and there's a lot of JS code that works with that page).
I read that they're used to dynamically resize the iframe. Is that all there is to iframe busters? Does hosting them on publisher's host help with JS cross-domain restrictions?
Added: I'm referring to the use case described here: http://blog.operative.com/?tag=iframe, and not just changing the iframe source document to the top level.
This is done for "take over ads". We use iframes (ADI - iframe vs ADJ - javascript) for a few reasons:
1 - they slow down the loading of your page content. 2 - they can break javascript on your page causing your page to stop functioning properly. 3 - worse case: they inject malicious code.
Using the iframe (ADI) approach the ads are isolated into their own document and can't interfere with the main web page.
However, there are cases when your marketing team wants to run take over ads. They are ads that expand outside their iframe window. For these ads the "iframe busting" approach was setup by most of the top advertising vendors. This approach requires you to host a file on your side that the ads can interact with and by pass the cross-domain restrictions of browsers.
Here is a comprehensive list of these files: http://www.adopstools.com/?section=miscellaneous&page=iframes
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With