back
9 comments
Ad blockers truly are the new virus scanners. They monitor everything that goes into and out of your computer and randomly break stuff just for kicks. And if that happens, it's somehow the fault of the software provider and not the ad blocker vendor.

You can't test against ad blockers (or virus scanners) because the lists keep changing, so you end up applying ridiculous alchemy like not calling your API endpoints "/analysis" but "/computation" and then you just hope for the best.

In the grand scheme of things, I agree that the people behind ad blockers are fighting the good fight, but in practice it's become a cat-and-mouse game of "who can break the internet the most". I don't know a solution.

I don't use any ad blockers, instead I only use Ghostery, which seems to work in a lot more sane way.
Oh man - thank you. I was getting reports of the same, and now I know why. Fixed.
Still broken for me. Turns out I have div#ads filter enabled that comes from one of the uBlock 3rd party sources.
(To the OP)

Maybe change "ads" to "posts" globally in the frontend?

Adblockers are are always going to block anything called "ads", even if it's a legit component of your site

I suppose it's a philosophical question: if you go to a job ads site, and the adblocker blocks it, is that really unexpected behavior? :)
That's one of those cases where you can be right and broke or cave.
Well, you could also go to a job postings site. ;)
Same for 'analytic', 'tracker' and related keywords.
This is a good reason to never prefix generated Javascript with hex hashes, at least without swapping out vowels. We rolled the dice one and had this happen on Wikispaces once; it was utterly infuriating to debug.
Nice catch, never thought about it. Is it more problematic with preffixes (vs. suffixes etc.) or should we generally avoid any random string? Appending a hash to the script is very convenient to force the download of the new version of an asset (but maybe we have better solutions now, haven't considered this issue in a while).
In your site's code, reference the asset in a path that includes the timestamp the asset file last changed.

e.g.

/js/1476929634/myscript.js instead of /js/myscript.js

Then use your webserver to rewrite /js/<any number>/myscript.js to /js/myscript.js

You can also do /js/myscript.js?v=1476929634 -- this generally works without any server-side changes. A CRC32 might work better, since controlling mtimes can be annoying.
You can, but that can cause issues with browser caching (http://www.stevesouders.com/blog/2008/08/23/revving-filename...) and in any case I prefer the cleaner urls :-)

Plus, once it's configured you never have to worry about it again.

Or just use a decimal hash, rather than hex? Eg in python3:

  import hashlib as h
  int(h.sha256(b" ").hexdigest(), 16)
> 24725091799402603688614593151141908335745916334489781770578761787218146381928

  h.sha256(b" ").hexdigest()
> 36a9e7f1c95b82ffb99743e0c5c4ce95d83c9a430aac59f84ef3cbfab6145068

It's longer, but even a 256-hash isn't that long? (and sha1 would probably be fine, obviously)

Why is there a problem exactly? It seems even if hash contains "ad", uBlock origin is not blocking it. Does this problem exist for some specific ad blocking software?
This has bitten us in the backside before.

We never understood why certain pull requests wouldn't load in Atlassian Stash/BitBucket Server - turns out our adblocker was blocking the page from loading due to having "ad" in the title.

I've run into that as well. I'm amazed that popular ad blockers still do that, since it's obviously trivial to work around for actual ads, and will result in so many false positives.
They do it because it works.
That's a hilarious comment, and a good point. But you can tell when your ad blocker is messing with site functionality beyond just blocking ads (i.e., the false positives your parent comment mentions). And at a certain point, this is a differentiator among the ad blockers.
+1 for the minimizing into one bundle thing. Sets of assets are loading sequentially which is slowing page load down.

Your code in each js file seems self-contained, so a simple in-order file concatenation into one .js file as a build step would help. gulp and gulp-concat would do it in a few lines of node, and you'd push the built output to your site.

If you end up wrting so much script that a concatenation approach stops scaling, look into webpack and web modules.

The one that should be fixed here is a buggy blocking plugin.
uBlock is really good at blocking ads, and a lot of other things that aren't ads too.
If enough people use ad blockers I think they should just make ignoring files and divs with "ad" in their name part of the HTML specification.
Hah! This is great.

"Wait all descriptors containing the letters 'ad' are ignored?"

"Madness."

"This is HTML!"

> "Madness."

Blocked by ad blocker.

Haha..just my pint its freaking html
It's incredible that people put up with how buggy these adblocker extensions are. Seriously, blocking an arbitrary URL with "ads" in the path?

Can't they just stick to blocking domain regexes instead of actually breaking the web?

The web is broken by all the intrusive ads. I don't mind breaking 1% of the pages I visit if that means blocking ads in 99% of the internet.
And that's one of the reasons I don't use an ad blocker. Not even uBlock Origin, which receives all the praise, is reliable in that sense.

I don't understand the crusade against people not using ad blockers by the way. I believe I have good reasons not to. Why do people seem to have a problem with that?

What "crusade?" I don't care if other people don't use ad blockers; in fact, it's probably to my benefit.
I was getting downvoted before adding the second paragraph and it always happens when I say similar things.