Referer Guardian Launches Tonight!

Referer Guardian launches TONIGHT at 11PM EST!

Just a quick update for everyone waiting for Referer Guardian to launch.

We made a great discovery yesterday during the final round of testing. We’ve tested and scrutinized the human generated clicks themselves extensively without ever having a leak, but had never seriously abused a Referer Guardian guarded iframe. So, a good friend was kind enough to lend us a 1×1 iframe on a site that gets hundreds of thousands of hits a day. We routed this iframe through Referer Guardian and to a tracking page where we recorded the referer as well as the header information (which carries browser information, among other things.) What better way to do a final test than to put it through some insane abuse?

The results were very, very good and we learned something that, as far as we know, no one else has ever discovered. After well over 100,000 iframe loads, we had a leak rate of ~0.03%. That means that for every 100,000 visitors that hit the iframe, we recorded 30 leaks. Now, leaks are a scary thing when you’re developing (or using) something to hide your referer, but this isn’t a surprise. Iframes are notoriously hard to deal with because each browser handles them a little bit differently.

When we began to analyze the logs, we saw a very clear pattern for the tiny amount of referers that did leak through; they were all (as in 100%) based on the Apple WebKit browser framework, which is used by both Safari and Chrome. What was even more strange was the fact that there were literally thousands of other users, using the same browsers and operating systems, whose referers were cloaked perfectly. Our first thought was security software, but the fact that a majority of these leaks were from iPhones and Mac users indicates otherwise.

We also noticed that almost all of these leaks happened in pairs in very close succession to one another. After putting some serious thought into the issue, what we’re almost positive is occurring is the result of pre-fetching and caching. Under certain, rare circumstances (such as an extremely fast refresh or back button hit) some browsers will load the end result of a series of redirections rather than follow the redirection path itself. We have been unable to recreate this event using the same browsers (including the iPhone) after many, many, many tries, but we’re almost certain this is the case.

Since we are unable to control browsers’ behavior at the system-level, we’ve added the option to block all WebKit-based browsers. The referer is checked all along the cloak path, so it isn’t possible for a browser that either sends no referer or an unexpected referer to actually pass through Referer Guardian directly. We added the option specifically for people who choose to iframe.

For the sake of comparison, we also tested the currently most popular referer cloaking plugin, CPA-Redirector, and found that a little more than 5% of referers passed through during the same iframe test with very little pattern to the browsers or operating systems of those leaks. This means that under a strenuous iframe test, CPA-Redirector was 167 times more likely to leak the referer than Referer Guardian.

How is that for extensive research?