Hacker News Reader

Comment by jakub_g | Hacker News Reader

Another protip: don't name your images "banner.jpg"; "ads.js" and "analytics.js" etc are also not exactly great names.

Another protip: Always make sure that critical flows in the app won't fail if analytics event fails. You probably want to wrap calls to analytics provider with your own function, and in that function check for existence of global analytics object like "window.ga" which may fail to load due to adblockers and similar tools. In other words, don't 'ga("send", ...)' all over your code.

I had airplane ticket booking fail mysteriously because "pay" button had a analytics listener bound to it, and it would throw an exception when adblocker was on. Without devtools, I would not understand what's going on.

View on HN

This shit drives me up a goddamn wall.

I had a web app a few years ago that I was using webpack to build the JS with, and the output filename was just a SHA hash of the contents.

After an update, I started getting reports that it wasn't working for some people. Turns out they had adblockers that were blocking *ad.js and it just so happened that the SHA hash of the file ended in ad.js

Medium had the same problem where hash-named paragraph divs would disappear if they contained "ad".

Wow. Thank you for this story. Word that this could happen should get out there. I would have never thought to look for hashes that happen to end in "ad"

Hmm I wouldn't think of this aspect but it's really insidious!

Looks like it could be interesting to submit a PR to some popular hashing libs to have a 'adblock-safe' mode (append some postfix if hash ends with 'ad' etc) or at least document the thing so that more developers are aware!

> Looks like it could be interesting to submit a PR to some popular hashing libs to have a 'adblock-safe' mode (append some postfix if hash ends with 'ad' etc)

Why is that preferable to a PR that fixes the bad regex?

I would suggest `[^A-Za-z0-9]ad.js` is better - it's not just hashes that would fall foul of this, any word that happens to end in 'ad' is going to break. If it's actually about ads, the prefix is probably going to be something like 'blah-' or 'main.' or whatever, surely?

In making a card game site (http://www.goodloesolitaire.com/), I got bit by ad.png; the "ad" was referring to ace of diamonds. Fixed it by using a single image for the whole deck and changing the position of the image to show the card that was picked. But man, tracking down that bug was a head scratcher for awhile. That was in the early days of adblockers.

>Fixed it by using a single image for the whole deck and changing the position of the image to show the card that was picked

Couldn't you have renamed the file?

Probably did do that at first (10ish years ago makes it a bit of a haze), but it was being served up by a PHP script that was creating the card name dynamically.

I wanted to move it off being tied to a server anyway and since anyone playing this would probably see a lot of cards, it made since to just download it all as one file rather than 52. At the time, it was all the rage to do such things.

Good excuse to refactor I'm sure.

> Another protip: don't name your images "banner.jpg"; "ads.js" and "analytics.js" etc are also not exactly great names.

This is good advice even if you are designing banner ads or intrusive analytics!

I often wondered how many ads get blocked by the very simple rules usually seen at the top of adblock lists: /ads/ etc. Ads vs adblockers is an arms race, and it seems like renaming the ads files to a random per-deployment name would have been the first escalation by the "bad guys". But maybe many developers of ad software don't even bother to fight adblock, preferring to optimize for users who don't use one.

They do.

I've recently encountered a video ad startup that runs a proxy wrapping VAST responses into a VMAP. So, a website would request an ad not from DFP, but from an inconspicuous CloudFront URL. These CF distributions are deployed for each publisher and you'd have to block them one by one, not being able to block the whole ad platform.

They said that some adblockers can discover ad servers by parsing responses. If a response, say, is a VAST tag, they tag and blacklist a server.

Adblockers are starting to employ heuristics to analyse what a server does, rather than relying on just URL pattern matching. Just like Virus VS. Antivirus arms race.

Fascinating!

I blogged about a fun one a while ago[1], pornhub using WebSockets to dodge adblockers.

[1]: http://blog.bugreplay.com/2016/11/pornhub-bypasses-ad-blocke...

Like all arms races, one day it will all blow up in our faces. Since it is not a literal arms races, it will metaphorically blow up in our computers. Hope somebody resolves it before it really does. (Not gonna happen though)

Arms races are ubiquitous , from US Vs China to bats Vs the moths.

How exactly do they blow up?

Usually for money reasons?

Yup, had an "analytics.js" in a project recently (related to an app dashboard, nothing to do with tracking) and it got blocked. Luckily I caught it right away because I have uBlock installed in the same browser I do development in.

Moral of the story: blocklists are a bit shitty and prone to overblocking due to excessively generic rules. Take that into consideration when naming things.

IMHO it'd be much better to just mock it than to litter your code with if() all over the place, similar to how polyfills do it (but without the actual functionality):

    if (!window.ga) {
      window.ga = function(){};
    }

Always make sure that critical flows in the app won't fail if analytics event fails.

Monoprice's site won't allow checkout with uBlock unless you define a function they're trying to call: _satellite = { track: function(){} }

With inventions like Google Tag Manager that allow marketing departments to inject JS into the production site, things like this may not even be the developers' fault.

The user is running an extension that breaks random pieces of the web page. Obviously that's not the developer's fault.

Monorprice is a business. At the end of the day, anything that stops an order is their PROBLEM. The fault doesn't really matter. No sale = no payday.

If it prevents you from making money it is still a problem.

If you develop for something that is not ad based you need to be aware of and test for these issues.

> I had airplane ticket booking fail mysteriously because "pay" button had a analytics listener bound to it, and it would throw an exception when adblocker was on. Without devtools, I would not understand what's going on.

This is likely intentional - break the website if viewed with ad-blockers, the consumer thinks 'the adblocker must be buggy', and disable the adblocker for the site.

In fact, I'd love to have analytics and as such on sites where I'm the paying customer, such as airline sites, amazon, etc - this enables the website developer to get the website code in a better shape.

CloudApp had this type of problem where the CPU would crank up to 100% usage after my Pi-Hole blocked their segment.io code from functioning.

Yup. I have to manually screw around with doordash URLs because the login button on their site breaks when I block analytics libraries.

Reply on news.ycombinator.com