This is not mentioned in the article, so just to be more specific, the override of `XMLHttpRequest.open()` applies only for the Safari-specific code of the extension.[1]
It has been the case for years now that you really have to include ad and tracking blockers for browsers in your testing process somewhere, even if it's just a manual run-through in the smoke test section. Though I think that more than that is needed; e.g. adblock-enabled pools in your Selenium grid.
You really have to start from the bottom up assuming that things are going to get blocked for some people and build in graceful degradation of performance:
Though the problem in this article looks more in the way of something to be caught by a sufficiently well constructed QA process, followed by a bug filed with the ad blocker in question.
See, I don't agree with this - it's like saying as a site-owner, you need to cater to people who disable JavaScript, or who use Ghostery.
Sure, you can cater to them if you like (or if you think they're a sizeable portion of your audience). But if I was using one of those two, I certainly wouldn't go whine to a site owner and say "Your site doesn't work for me!". It's my choice to use those products.
Likewise for ad-blockers - sure, I use ad-blockers. But if a site breaks for me, I don't go whine to that site owner. I just choose to either disable the ad-blocker for that site (if the site has content I want), or I just don't frequent that site (if it doesn't).
Disabling JavaScript, or using an ad-blocker is an elective thing that some people choose to do (whether for paranoia, or because ads annoy them). It's not like say, accessibility for colour-blind people or people using a screen-reader, who can't really choose their disabilities. I have sympathy for people with disabilities (I myself am hard-of-hearing), however, I have less sympathy for people who disable JavaScript or use ad-blockers (Note that I myself use one - but if it breaks something, I debug it myself).
The problem is that the end user who has an ad blocker installed doesn't see a big "THIS FEATURE OF THE WEB SITE IS BROKEN BECAUSE YOU HAVE AN AD BLOCKER INSTALLED" message when things don't work. They just see things not work. Maybe a few of the more tech-savvy users will guess that their ad blocker caused the problem, but most users will just assume that your site is crappy.
If your site is monetized through something other than ads (e.g. purchases), it might be in your financial interest to make sure that your site works correctly even in the presence of a poorly-written ad blocker. Of course this depends on how many of your users are affected by the problem.
Now if your site is free, with no ads, then I can see how your philosophy could make sense.
The only time I think it makes fiscal sense to ignore a sizable portion of your potential user-base is when you're already making so much money that the potential income from those users would be negligible.
It seems that the average number of page-views for all sites that are ad-blocked is something like 9% (and on some sites up to 50%)[1].
would you really want to sacrifice a 9-50% of possible revenue?
I've experienced this, and it's a major pain the ass if we are talking about not just testing but making it work for AdBlocker users. In our case once we had to resort to rewording the method name in our REST AJAX API endpoint so it wouldn't contain the word "counter" for it not to randomly fail for adblocker users. Why would an adblocker be so incredibly aggresive as to block random words from urls is beyond me.
> Why would an adblocker be so incredibly aggresive as to block random words from urls is beyond me.
Because advertisers are so aggressive about shoving shit in our direction. It's an arms race, and unfortunately we sometimes suffer from collateral damage.
I don't think adblockers will be so naive as to block anything that contains "ad" in the URL, but then again, there's a name for the bug caused by this particular type of matching:
They don't usually match on something as silly as the regexp /ad/, no—but they _do_ frequently contain a regexp like /\bad\b/.
The problem being—and this is painful personal experience speaking—web frameworks will frequently also cater to directory inode limits of caching reverse-proxies in their cache-busting code by doing something like this:
"/#{sha[0..1]}/#{sha}.#{orig_ext}"
...which means that, for a SHA that starts with "ad", you get an "/ad/" in the URL.
I once had a ceo ask why the header image on a prominent section of our website was not showing on his machine.
I opened the page, and to my surprise,, the header image didn't show on my computer either, but it showed on my coworkers screen.
In my standard "eliminate all simple causes" method I switched to incognito, and the header image loaded.
Somehow, I was able to recognize that it was due to an extension that was not active in incognito, and that the header image was named ...ads.png and it was catching a rather generic Adblock matcher. We renamed the file and all was good.
We had a similar issue with our Hackerspace website - we have a section on the site that shows logos partners and sponsors, and at some point it disappeared. We found out that some class name in a div containing those images matched to some Adblock blacklist. We changed the CSS names to something silly and now everything is back to normal :).
Ive been burned on this enough times where I know that any weird error that doesn't have an explanation, automatically turn off adblock. 9 times out of 10... works
I would not recommend this as a default choice if you want to benefit from the security aspect of adblocking, as otherwise you might become too easily deceived into turning it off - along the same lines as those fake error message ads.
Since I have JavaScript disabled by default, I encounter plenty of such messages; but almost all of them I can safely ignore. It wouldn't surprise me if there are messages to the effect of "This site is not compatible with adblock, turn off your adblocker for a better experence" - and upon acting on such a message, the poor luser gets bombarded with all manner of popups and other crap. Incidentally, that's a similar experience to when I first started browsing with disabled JavaScript, and made me become much more wary of turning it on just because some site wants me to.
From the article: "The ad blocker replaces XMLHttpRequest.open() by its own code and checks the request URLs for keywords on a block list. If the URL matches it would throw an InvalidAccessError."
It sounds like the ad blocker misused a regular expression and matched the string "twitter" in the wrong context. Some ad blockers just use files of regular expressions somewhat blindly. If you're looking at URLs, parse them.
Interestingly, adblockers should be careful about doing stuff like this, as lots of sites would love a check as simple as "make a request to /twitter-sponsered-ad-paid and deny access if it fails"
If adblocking is all about user choice then it's only fair that sites have choice to serve that content too. Right now it's incredibly hard for sites to reliably know if someone is using adblock.
Attempting to purposefully disguise that usage goes beyond any accepted ethics of using adblock today.
You can do it yourself as well -- EasyList and some others have patterns that they check for on the page path and individual elements, not only known hosts.
Keyword "reliably". It sounds easy but it's not due to the all the different plugins, rules and levels of adblocking.
There are also constant updates to counter this. If you check the adblock forums, there are dozens of threads every day about how to get around checks on sites and even disable messages that specifically show up to adblock users.
Well, the other side of it is that, imho, the adblocker has no reason to purposefully expose itself. I was not commenting on the ethics of adblock, just the fact that sloppy checks and sloppy code are a bad thing. I personally don't use an adblocker, I just don't go to sites that I have had bad ad experiences on.
I've also hit this in the past. However I feel like I remember seeing that the error messaging had been enhaced in whichever version of Chrome came out next. I've forgotten the details now, but I feel like it explicitly said that an extension had blocked the request.
been seeing this trigger on equally safe / intentional / non-commercial endpoints. as a developer, it's almost an imperative to run with ad-blocking enabled.
makes me wonder, has anyone come up with headless ad-blocking for integration testing?
Eliminating all potential discrepancies usually revolves around testing the same scenario in multi configurations and seeing if they have the same outcome. If a outlier is identified then it should shed light on the source of the problem.
[1] See https://github.com/chrisaljoudi/uBlock/tree/master/platform/..., the code is in `vapi-client.js`, line 247.