Blocking AdBlock

I've been asked for suggestions for how one might go about blocking the AdBlock add-on/plug-in from working in Firefox.

My first reaction, (as an advocate of the people... oh boy, representin' for the peeps, just what theys need, another techno insomniac confusing social networking with the actual concept behind the word "social"), er, as I was saying, my first reaction is "POWER TO THE PEOPLE!". Let's face it, if ads weren't so damned offensive, and more importantly, intrusive, slow, uninspiring, sleazy, annoying, etc, etc, this wouldn't even be an issue. So all you marketing/ad-tech sphincters out there, shame on you for putting us all in this predicament in the first place! This is what happens when "the market" rises against you and adopts a variant on the spank-a-logical protocol! (Oh and P.S., You suck!)

OK, then after popping a Valium and digging into my vast knowledge of front end web development techniques (wow, the annoying sarcasm runs deep in this one--who wounded you so, oh jaded chum....p) it seems to me that perhaps a campaign of punishment might be poised to elicit the most effective response.

Here goes:

0. (Look Ma I'm zero indexing!) Create a script in a directory under the host you are serving your page from. This can be a client-side script, such as JavaScript (um, that's me giving subtle props to you poor schleps that think MS proprietary (or hell, ANY proprietary) "alternatives" qualify as client-side scripting at all... doh, did I just type that out loud).

Said script will need to set a session cookie, from the host your content lives on (so as to avoid cross-domain security issues). It should probably return nothing visible, just set the cookie and be done with it. It's most likely this puppy is gonna need to get called into a remote iframe not intended to be viewed by the ...er, viewing public.

1. Assuming your ad server is centralized on a "remote" domain and done so in order to facilitate ad serving across multiple domains, blogs, etc., you'll need to incorporate a means of obtaining the caller's domain. This can be done by adding a parameter to the query string requesting the ad from your source, or it could be trapped for in the referrer, (or "REFERER" for the sp3lling challenged amongst us, I call them sysadmins, but that generally gets me mysterious punitive restricted access in shells and/or loss of sudo rights, so I inevitably retract).

Note: If you pass the referring domain via query string parameter, you'll need to parse on the other end, so if you can use the built in referrer constructs in JavaScript that's a nice simplification.

2. When you create a new ad placement in your ad server, include a line of JavaScript to callback to the cookie setter script described above. Note: It's important that the cookie get set on the domain the ads are getting called from.

3. You need an additional line of script in your calling page to "evaluate" the cookie AFTER the ads have loaded. This can be a little tricky. I believe you can actually trap for the onload event, but if you belong to the "AJAX" generation... wow, what a load of crap, back in my day... er, nevermind... trapping for onload most likely won't work for you AJAX folks (or your forebears that use other methodologies for asynchronously including content).

For example, if you are calling your ads in via iframes particularly in a post-load scenario--which all "good", well "grey good" since it's still not really "good", banner serve scenarios do in order to allow the UI to be rendered and operable to the user prior to making the calls to your slugly (slow + ugly) remote ad server which ...holy cow... can take f-o-r-e-v-e-r to come back, which they eventually do, mostly. (Yip, sometimes they never come back... oh I said it!) Anyway, taking this approach can greatly improve UX and if you can't abandon ads as a monetization scheme all together, I highly recommend going a post load route.

As I was saying, in certain cases when using iframes, ajax, or even post-load + DHTML techniques to bring in ads, the onload event will fire before the remote ad is called in... meaning you can't use onload by itself to trigger a check for the existence of the cookie.

I suspect the most "reliable" (and I use the term as one does for virtually anything remotely complicated in the realm of web development) approach to ascertaining whether the "good to go" cookie has been set by the remote script is to assume a time to live of 5-10 seconds after onload (you'll see why evil marketing people everywhere love this technique in a minute). Check each second while the TTL is in effect to see if the cookie has been set. If it has, cancel the TTL and life is good... this means your ads were called in and your callback mechanism functioned to confirm it¹.

4. However, if after the TTL expires the cookie isn't set, then... (here's the evil part) bounce the location.href to http://adblockplus.org/.

The reasoning goes as follows: The visitor has obtained a plug-in from these folks that is designed to alter the experience of the user. By tantalizing a reader who is using this plug-in with a brief exposure to the content they were presumably after you create an angry customer. However, the customer doesn't get angry until he or she is viewing the adblock page pitching the virtue of using the plug-in. Yes, it's true, it's bad user experience... and I am, and always intend to be, a user advocate. It just seems to me in this scenario the user has changed the rules by being tricked into colluding with their new "preferred" partner--the adblock folks. It seems only fitting then to let the adblock folks themselves remind the user why they are unable to access the information they were after.

If this is too Machiavellian then perhaps you're on the wrong Internet. (Coming soon to an Internet near you, IPv6 and goodness for all. Super-man will be signing autographs in the foyer, ...for $25 bucks a pop.) Or, perhaps you can choose to do something else with folks failing the cookie check.

For the rest, peace out.


P.S. I'd very much like to entertain your suggestions for simplifying this, or what about it doesn't work, so on so forth. Yes, yes, what if they don't have cookies, or their browser doesn't support them. What if they're using lynx or God forbid, wget... perhaps worse still Safari (woah, I'm just kidding!). Anyway, I'd love your input.



Notes:


1. Well, so there's an additional caveat here. Since much of the ad code that gets cut/pasted into ad servers actually creates a call to yet another remote domain it's still possible that--that domain may be blocked. So, your check served to validate one step of the complicated journey home, but may not speak to the next leg which exists outside of it's scope. This could be overcome by a similar check between these end points, however at this point you are reliant on folks at CJ, LinkShare, or any number of other venues... and at least in my experience, they don't tend to be able to help at this level. Perhaps I just don't know the correct folks.