5 ms·

An interesting related anecdote on this is that at least in Chrome, adblockers can also interfere with extensions' attempts to load scripts, load stylesheets, o

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 (packed into the extension, not on a web server!) containing the word 'popout' caused it to get killed silently, and renaming it made it work. Naturally you can troubleshoot a lot of this with 'does it work if you disable adblock?' but it's a real pain to have to convince users that they can't use your software along with their broken adblocker.

vbrandl 9y ago
Shouldn't adblockers whitelist local request to prevent something like this?
- mp3geek 9y ago
  Why whitelist, when its easier to rename a file?
- mp3geek 9y ago
  Also the filter in question "/beacon.js" is 3 years old in Easyprivacy, to be exact "Feb 23, 2014". I could understand if it was a recent commit but its not, the onus shouldn't be on the List authors to fix it, but the site owner (yourself) to fix it.
  - kiallmacinnes 9y ago
    Is this meant to be sarcastic? becaon.js is a perfectly valid name for a JavaScript filename, being forced to name your files something different from their content just to placate ad blockers dodgy blocklists is not right. Even more not right though, is every developer having to check every blacklist to see if their component name happens to also be used in advertising. Is this really what your suggesting? Then there's the whole *ad.js blacklist another commenter brought up, this is frankly just a sign of a terrible blocklist. And new entries that are just as bad get added all the time, so now every developer has to check every blocklist every single day if they want to keep their site running smoothly. (A happy user of an ad blocker, who is aware that 9 time out of 10, when a site I'm using is broken, it's the ad blockers fault - not the sites)
nsgi 9y ago
> it's a real pain to have to convince users that they can't use your software along with their broken adblocker The reality for most extension developers is that our extension is less essential to users than their adblocker, and if they had to choose between them they would choose the latter.
- vbrandl 9y ago
  To be honsest, I might do the same. Surfing the web without an adblocker nowerdays isn't much fun, to say the least
Doctor_Fegg 9y ago
Yes. We seem to have moved from a position of "four different browsers with differing behaviour" to "four consistent browsers with consistent behaviour, each with hundreds of potential content-rewriting extensions that may arbitrarily break your site in unexpected ways". I'm not convinced this is an improvement.
- Spivak 9y ago
  It seems to be an improvement for the user.
- makecheck 9y ago
  Well we also used to have mostly non-HTTPS, where wifi networks and ISPs could and did insert crap into pages. I much prefer now being able to guarantee that what the user downloads is what the site provided. At least then the "turn everything off and see if it works now" option should be viable.
goodplay 9y ago
Can you really blame them? Websites became hostile to users and users reacted. I don't know what your software is, and this certainly isn't directed at you, but if I'm forced to make a choice between using an ad blocker or using some software, I'll always choose the ad blocker (unless I was forced to use said software), especially if there are alternatives. There are no real alternatives to using an ad blocker.
- DanBC 9y ago
  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 ad-blocker. You can also see how it must be a bit frustrating to have people saying "ZOMG why can't I use both? Fix your software so that I can use both!", when the fix needed is only achievable by the ad-block creator.
  - pwg 9y ago
    > when the fix needed is only achievable by the ad-block creator. It seems to me that there are two possible fixes. One, the ad-block creator updates their list, yes. But the other is the extension writer renames the file that is triggering the ad-blocker so the ad-blocker is no longer triggered. The only one of those two fixes that is within the direct control of the extension writer is renaming the file within the extension that is triggering the ad-blocker.
    - deleted 9y ago
      [deleted]
  - akvadrako 9y ago
    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.
bangonkeyboard 9y ago
If extensions can interfere with each other's internal resources then the real breakage is in the browser's extension mechanism.
- PrivWeeble 9y ago
  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.
gorhill 9y ago
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, my understanding is that should not be possible. You mind disclosing what is your extension?
- nsgi 9y ago
  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.
- kevingadd 9y ago
  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.
kmfrk 9y ago
Using Little Snitch can be pretty eye-opening; I wouldn't for the life of me have imagined that my terminal installations of packages with stuff like Homebrew would send calls to Google Analytics. It's bloody everywhere.
- vbrandl 9y ago
  That one is actually documented in their repository: https://github.com/Homebrew/brew/blob/master/docs/Analytics.md https://github.com/Homebrew/brew/blob/master/docs/Analytics....
  - throwanem 9y ago
    And aroused considerable controversy, here and elsewhere, when it was new. The two major active discussions here, 7 months and a year ago respectively: https://news.ycombinator.com/item?id=13034936 https://news.ycombinator.com/item?id=13034936 https://news.ycombinator.com/item?id=11566720 https://news.ycombinator.com/item?id=11566720 I'm not too terribly fussed over it, especially considering what it must cost to support Homebrew - if analytics data helps the maintainers make more effective choices around how to allocate limited resources, that seems to me like a good goal, and I'm not sure how providing information on packages I've installed via Homebrew, to be included in anonymized reports on packages ~everyone has installed in Homebrew, poses any meaningful risk to me. That said, if you feel otherwise, see https://github.com/Homebrew/brew/blob/master/docs/Analytics.md#opting-out https://github.com/Homebrew/brew/blob/master/docs/Analytics.... on how to make Homebrew not send analytics data any more.
f4rker 9y ago
Users can setup your domain on a white list

vbrandl 9y ago

Shouldn't adblockers whitelist local request to prevent something like this?

mp3geek 9y ago
Why whitelist, when its easier to rename a file?
mp3geek 9y ago
Also the filter in question "/beacon.js" is 3 years old in Easyprivacy, to be exact "Feb 23, 2014". I could understand if it was a recent commit but its not, the onus shouldn't be on the List authors to fix it, but the site owner (yourself) to fix it.
- kiallmacinnes 9y ago
  Is this meant to be sarcastic? becaon.js is a perfectly valid name for a JavaScript filename, being forced to name your files something different from their content just to placate ad blockers dodgy blocklists is not right. Even more not right though, is every developer having to check every blacklist to see if their component name happens to also be used in advertising. Is this really what your suggesting? Then there's the whole *ad.js blacklist another commenter brought up, this is frankly just a sign of a terrible blocklist. And new entries that are just as bad get added all the time, so now every developer has to check every blocklist every single day if they want to keep their site running smoothly. (A happy user of an ad blocker, who is aware that 9 time out of 10, when a site I'm using is broken, it's the ad blockers fault - not the sites)

nsgi 9y ago

> it's a real pain to have to convince users that they can't use your software along with their broken adblocker The reality for most extension developers is that our extension is less essential to users than their adblocker, and if they had to choose between them they would choose the latter.

vbrandl 9y ago
To be honsest, I might do the same. Surfing the web without an adblocker nowerdays isn't much fun, to say the least

Doctor_Fegg 9y ago

Yes. We seem to have moved from a position of "four different browsers with differing behaviour" to "four consistent browsers with consistent behaviour, each with hundreds of potential content-rewriting extensions that may arbitrarily break your site in unexpected ways". I'm not convinced this is an improvement.

Spivak 9y ago
It seems to be an improvement for the user.
makecheck 9y ago
Well we also used to have mostly non-HTTPS, where wifi networks and ISPs could and did insert crap into pages. I much prefer now being able to guarantee that what the user downloads is what the site provided. At least then the "turn everything off and see if it works now" option should be viable.

goodplay 9y ago

Can you really blame them? Websites became hostile to users and users reacted. I don't know what your software is, and this certainly isn't directed at you, but if I'm forced to make a choice between using an ad blocker or using some software, I'll always choose the ad blocker (unless I was forced to use said software), especially if there are alternatives. There are no real alternatives to using an ad blocker.

DanBC 9y ago
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 ad-blocker. You can also see how it must be a bit frustrating to have people saying "ZOMG why can't I use both? Fix your software so that I can use both!", when the fix needed is only achievable by the ad-block creator.
- pwg 9y ago
  > when the fix needed is only achievable by the ad-block creator. It seems to me that there are two possible fixes. One, the ad-block creator updates their list, yes. But the other is the extension writer renames the file that is triggering the ad-blocker so the ad-blocker is no longer triggered. The only one of those two fixes that is within the direct control of the extension writer is renaming the file within the extension that is triggering the ad-blocker.
  - deleted 9y ago
    [deleted]
- akvadrako 9y ago
  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.

bangonkeyboard 9y ago

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

PrivWeeble 9y ago
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.

gorhill 9y ago

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, my understanding is that should not be possible. You mind disclosing what is your extension?

nsgi 9y ago
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.
kevingadd 9y ago
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.

kmfrk 9y ago

Using Little Snitch can be pretty eye-opening; I wouldn't for the life of me have imagined that my terminal installations of packages with stuff like Homebrew would send calls to Google Analytics. It's bloody everywhere.

vbrandl 9y ago
That one is actually documented in their repository: https://github.com/Homebrew/brew/blob/master/docs/Analytics.md https://github.com/Homebrew/brew/blob/master/docs/Analytics....
- throwanem 9y ago
  And aroused considerable controversy, here and elsewhere, when it was new. The two major active discussions here, 7 months and a year ago respectively: https://news.ycombinator.com/item?id=13034936 https://news.ycombinator.com/item?id=13034936 https://news.ycombinator.com/item?id=11566720 https://news.ycombinator.com/item?id=11566720 I'm not too terribly fussed over it, especially considering what it must cost to support Homebrew - if analytics data helps the maintainers make more effective choices around how to allocate limited resources, that seems to me like a good goal, and I'm not sure how providing information on packages I've installed via Homebrew, to be included in anonymized reports on packages ~everyone has installed in Homebrew, poses any meaningful risk to me. That said, if you feel otherwise, see https://github.com/Homebrew/brew/blob/master/docs/Analytics.md#opting-out https://github.com/Homebrew/brew/blob/master/docs/Analytics.... on how to make Homebrew not send analytics data any more.

f4rker 9y ago

Users can setup your domain on a white list