Live data from Hacker News

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

github.com

71–80 of 85 posts

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

#71

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

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"

[deleted]

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

#72
post #37
post #32

Earlier quoted context omitted.

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.

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

#73
post #49
post #9

Earlier quoted context omitted.

Don't assume most people are polite and reasonable like you. Many people are arseholes. You're choosing to use either the ad-blocker, or the software, and you've chosen the ad-blocker. You can see how tiresome it would be to have a flood of rude people saying "your software sucks", when there's nothing wrong with the software. There's a problem with the ad-blocker that the user has. The bug report should go to that a…

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

Honestly, if browsers were able to quickly determine that my "reactXX-X.min.js" was the same as Facebook's I would probably just eat the occasional edge costs.

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

#74
post #47

Earlier quoted context omitted.

Except software which doesn't work with an adblocker does "suck". Sure, potential users could phrase it more politely, but for many of them (me included), it's a minimum requirement. At least "sucking" is better than being totally useless.

But in the example given the reason the software doesn't work isn't because it needs ads. It's because the ad blocker is broken.

It's applying a heuristic that triggers a false positive in many cases. Most ad blocking rulesets do tend to include very basic rules like that. I don't know how many ads they actually still catch but if it's a significant number then it's probably a justified one.

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

#75
post #21

An interesting related anecdote on this is that at least in Chrome, adblockers can also interfere with extensions' attempts to load scripts, load stylesheets, or open windows. I maintain an extension with a smallish active userbase (~20k people) and a couple different times I've encountered mysterious failures that were the result of clumsy keyword blocklists in ublock/adblock/etc - for example an extension asset (pa…

I'm puzzled. Content blocking extensions can't interfere with your extension's internals, and can't interfere with network requests made by another extension. If your extension injects resources in the DOM, than a content blocker can interfere with the proper loading or rendering of these resources. However I am very surprised about your statement that a content blocker extension intefered with your extension assets,…

You can't inject a content script into another extension's page but the last time I used it the webRequest API could intercept internal requests, including those from extensions. Although they're planning to crack down on e.g. extensions redirecting search requests from the new tab page and the omnibox.

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

#78
post #21

An interesting related anecdote on this is that at least in Chrome, adblockers can also interfere with extensions' attempts to load scripts, load stylesheets, or open windows. I maintain an extension with a smallish active userbase (~20k people) and a couple different times I've encountered mysterious failures that were the result of clumsy keyword blocklists in ublock/adblock/etc - for example an extension asset (pa…

I'm puzzled. Content blocking extensions can't interfere with your extension's internals, and can't interfere with network requests made by another extension. If your extension injects resources in the DOM, than a content blocker can interfere with the proper loading or rendering of these resources. However I am very surprised about your statement that a content blocker extension intefered with your extension assets,…

Most Chrome extensions need to interact with content, so if you want to do that you have to run code inside the content context. Adblockers can intercept any requests you make, even if it's to extension content (i.e. not over the internet, not to an ad/tracking server). This goes so far that they will silently block attempts to open a popup window (in this case, in a click handler to open extension-specific UI for the user.)

The content was under chrome-extension:// and was just an html file. Incidentally I use ublock. I'd be happy to help you troubleshoot this if it's possible to fix the issue.

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

#79
post #67

Happened to me as well when I published the source for a analytics browser extension on github ( https://chrome.google.com/webstore/detail/google-analytics-l... ) Anything to do with JavaScript on the page would fail. Thankfully, github's support team was very helpful in pointing out that uBlock was the cause.

Funny you mention that: I can’t access this page due to my adblocker :P

Which adblocker do you use?

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

#80

An interesting related anecdote on this is that at least in Chrome, adblockers can also interfere with extensions' attempts to load scripts, load stylesheets, or open windows. I maintain an extension with a smallish active userbase (~20k people) and a couple different times I've encountered mysterious failures that were the result of clumsy keyword blocklists in ublock/adblock/etc - for example an extension asset (pa…

If extensions can interfere with each other's internal resources then the real breakage is in the browser's extension mechanism.

Well normally you wouldn't want one browser extension to interfere with another extension. However, there are contexts where that is very beneficial. Take a security or privacy extension which correctly identifies a harmful resource load. It doesn't matter whether that resource is being loaded in a content tab, loaded by another extension behind the scenes, or is local vs remote. It it still a harmful load. So a protective extension should be able to detect it, then inform the user and/or perform an appropriate blocking action.

This, like some other special powers, is something that the user should have to explicitly grant to an extension via permissions interface.

Post reply on HN