A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js' • Hacker News Board

Re: A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js'

#81

Post by rsj_hn » Mon, Jul 10, 2017, 6:06 AM UTC

seangrogg wrote: post #73

rsj_hn wrote: post #49

Earlier quoted context omitted.

The thing is, the software does suck some of the time. Here too, I'm not saying your software sucks, but web developers have developed several bad habits that put users at risk for no particular reason other than sheer laziness. here are some examples: 1) Instead of putting third party scripts under your own version control and hosting them yourself, you host them from a "free" CDN which then stores tracking cookies…

WRT #1, while it certainly isn't difficult to serve libraries from your own server taking advantage of a CDN allows you to take advantage of browser caching and offloads bandwidth. I'm not saying that CDNs should be setting tracking cookies, mind - I'm just pointing out that as a developer a CDN helps me improve the experience of my users and as a user a CDN helps you reduce my costs to provide whatever value I am to…

Well, that's the thing -- there are good CDNs out there, but they expect you to pay. But why is the developer making the decision of making the user pay for it with their privacy? Without any kind of notification or agreement, or even discussion, really, with the people who should be deciding this stuff.

Now perhaps I'm wrong, and this is not a developer decision at all but a decision from the business side, where they weighed the privacy issues against the slower performance against the cost of paying for a CDN, and decided this was the right way to go, then they instructed their developers to start loading all these scripts from third party free CDNs.

Except, I've been doing this thing for over a decade, and developers keep sneaking this shit in, and then acting surprised that it's not OK to pull jQuery from ye-favorite-free-CDN, but they need to stick the thing into static resources where it will be served from our CDN. And I keep finding devs doing this also when I do pentests of third party sites, and the response from the security POC is usually "we had no idea this was being loaded from the free CDN. We even have a contract to use Akamai, we just didn't know".

At the same time, I keep seeing this in open source software, even in examples and tutorials, where supposedly the user speed is not so crucial, as well as stackoverflow, and I also know there is a lot of cut and paste going on, so I still think this is just bad hygiene on the part of the developer community, where people are just very cavalier about letting third parties inject javascript into your origin.

But you do have a fair point. End of rant.

Re: A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js'

#82

Post by ddalex » Mon, Jul 10, 2017, 8:58 AM UTC

jakub_g wrote: post #7

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 adblock…

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

Re: A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js'

#83

Post by Doxin » Mon, Jul 10, 2017, 11:31 AM UTC

carrier_lost wrote: post #48

This seems like a good case in favor of Privacy Badger's model, where content blocking is based on the number of times a domain tries to track you across websites, rather than a blacklist of URL patterns and file names.

Privacy badger has a nasty habbit of breaking login for sites using a login subdomain though. In my experience privacy badger has vastly more false positives than ublock for instance.

Re: A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js'

#84

Post by chillydawg » Mon, Jul 10, 2017, 4:37 PM UTC

Ajedi32 wrote: post #60

chillydawg wrote: post #41

Earlier quoted context omitted.

As one of an extremely large group of people who will never use that library but DO get protected from some ads and tracking by blacklisting beacon.js, I disagree that it's an issue with ad blockers. The internet is a toxic place, to put it mildly, and if you're getting into any kind of public facing service on it, you need to know exactly what you're doing.

Wait, you're saying that a false positive in an ad blocker is _not_ an issue with the ad blocker? Of course it is! Blocking files based solely on their names is a brittle and error-prone way of doing things, and this false positive is a clear example of that.

For sure it's a false positive and I wish it didn't happen. But it does happen and there's no way I'm ditching my ad blocker just because of some small number of false positives.

Re: A JavaScript browser library fails due to an adblocker blacklisting 'beacon.js'

#85

Post by OJFord » Wed, Jul 12, 2017, 6:08 PM UTC

jakub_g wrote: post #69

Klathmon wrote: post #30

Earlier quoted context omitted.

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

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?