The main reason is because of how most online ad agencies and tracking companies name their ads/pixels.  It appears that the algorithm to determine if an item should be blocked is based on the filename.  If you take a look at a doubleclick request, it will look something like: (these are two live examples I found)

http://ad.doubleclick.net/adi/abtl.home/;kw=fms;info=22111;u=22111;sz=586×90;ord=23946755?

http://ad.doubleclick.net/activity;src=1142700;type=ivill675;cat=gotoi382;ord=8636919891878.148?

Notice the filename (the part in bold).  There is no similarity and in fact it looks like there never will be.  It looks like Doubleclick passes the parameters through the filename instead of the query string.  This means that DoubleClick is perfectly safe from inPrivate Blocking.

In fact, most of the trackers or ad agencies appear to use random or distinct file names.  The only obvious one that doesn’t appear to do this is google analytics.  Their requests are:

http://www.google-analytics.com/__utm.gif?

http://www.google-analytics.com/ga.js

http://www.google-analytics.com/urchin.js

So I first attempted to get the multiroot to work on a subdomain of the original domain.  This gave me a bit of grief as the original gallery2 install is in a subdirectory.  And so I had to set up a .htaccess rule that would redirect requests that weren’t caught be the normal multiroot template .htaccess and send them through a “fetch” script that would curl the files.

That took a bit of work because the template .htaccess was definitely a template.  I pretty much rewrote it in the end.

But once it was done, I then set up my other domain (on the other server) and created a rewrite rule (inside a .htaccess file) that caused all trafic to go through its own “fetch” file.  This would then fetch from the actual multiroot, which would then fetch from the real install.

In the end, I made it so that if you go to the other domain, the page shows no indication of what server it is pulling from.  It is a little slow because of all the extra network requests, but as it is only going to be used for family, I’m pretty happy with what I did.

I first played around with the trick that Abe Fettig came up with (http://www.fettig.net/weblog/2005/11/30/xmlhttprequest-subdomain-update/) but it had one problem.  It required the page to set the document.domain.  I was looking to using this in a very large code base that can not have document.domain set as it is close to impossible to find all the places that will require it.

I then played around with the xip.js file that is in dojo, but didn’t like it as it used polling and I don’t really want to use polling.

So I worked with those two ideas to see if I could get a working/non-polling solution.  I was able to successfully change Abe Fettig’s idea to work as a inner iframe of a parent page that doesn’t change its document.domain.  This worked correctly in FF2, IE6, and IE7.  Safari didn’t like it though.

I then found this bug request to dojo: http://trac.dojotoolkit.org/ticket/4306.  That got me looking at various events that I could fire.  The blur() and focus() didn’t work as it caused the focus to be lost.  But then I discovered onresize.  I could resize the iframe, which would call the onresize event inside the iframe.  And it worked perfectly in Safari (but not in IE).

So I’ve taken those two ideas, combined it with the window.postMessage event, and have created a plugin to Ajax.Request inside of prototype.  This only works for subdomain ajax requests because of the document.domain but that is what I needed.

Oh, and as for why I couldn’t just use a server side proxy, I was trying to get around the 2 requests per domain restriction.