Adblockers as the reason for InvalidAccessError | Hacker News Reader

Adblockers as the reason for InvalidAccessError

wwwtech.de

102 pointscjk10101044 comments

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]

[1] See https://github.com/chrisaljoudi/uBlock/tree/master/platform/..., the code is in `vapi-client.js`, line 247.

Direct link: https://github.com/chrisaljoudi/uBlock/blob/master/platform/...

Thanks for the pointer. You are right, but blocked gets the request in all three browsers nonetheless.

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:

https://www.exratione.com/2014/12/practice-defensive-javascr...

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.

Do you really?

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 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?

[1]https://www.quora.com/What-is-the-percentage-of-Internet-use...

Or when the potential income from those users is less than expected expense coming from not ignoring them.

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.

I don't believe you need to be particularly tech-savvy to observe that the ad blocker extension you installed breaks the Internet.

...and that it does "break" sites, but most of the time in a good way.

Can you intercept errors and display this banner if error is thrown and adblock is in use?

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.

It makes sense if there's an image with the word "ad" in the url. Probably something similar to that.

A bit frightening to think about: SHA hexdigests (as used in, e.g., cache-busting) can contain the two-character-sequence "ad".

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:

https://en.wikipedia.org/wiki/Scunthorpe_problem

...so maybe some of them do have rather silly rulesets.

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.

> 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 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 :).

Most of Microsoft's MSDN web site falls over with the same problem as well.

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 thought it was standard to open up an incognito window with everything disabled when debugging.

I thought it was standard to assume everything I do is standard.

Yeah, that's non-standard behaviour.

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.

I'm referring to debugging my own stuff, not using other people's sites.

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.

Are you sure it blocked the url because the string "twitter", not "sponsored"?

Perfectly possible, I am not sure.

I've had parts of a website blocked over a word "sponsor" in a CSS class, so I'm willing to bet it's not "Twitter" that's the cause.

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"

Why?

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.

> Right now it's incredibly hard for sites to reliably know if someone is using adblock.

no that's not true - it's "easy", as long as you have cooperation from the advertising network. Their ads could do some callback onto the main page.

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.

It's very easy for a site to detect if a user is using an ad blocker. There are tons and tons of possible ways to check.

Since it's like playing whack-a-mole, I think most ad blockers simply don't care if their presence is known.

Oh, it's very easy:

  <img src="/an_existing_image.jpg?&ad_box_" onerror="alert('You are using adblock')">

How it's made:

1. Look into the most popular filter's used by adblock extensions: https://easylist-downloads.adblockplus.org/easylist.txt

2. Choose for example a querystring rule from the beginning (from the "General advert blocking filters")

3. Append it to the url of an existing image

4. Use the onerror event to detect if it wasn't loaded

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.

You are right. I just tested it, Chrome states `Failed to load resource: net::ERR_BLOCKED_BY_CLIENT`. I updated the article, thanks for the hint!

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.

I really don't understand why advertisers just don't require website to host those ads instead.

this is why when i test out my app i turn off ad blocker but since ublock no problems

Reply on news.ycombinator.com