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.
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.
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.
There are no real alternatives to using an ad blocker.
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.
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.
At least "sucking" is better than being totally useless.
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 in the origin of the user loading the script. How hard is it to serve all the js libraries you need from your own server?
2) You like some nice widget, like Google Maps. But hey, to use this widget, you need to load a third party script in your origin. No biggie, it's better than paying for a maps widget, right? Except now the user has a tracking cookie in your origin and you didn't disclose this or give the user an option to opt out. What you could have done is loaded that map inside an iframe that is served from a content domain or throwaway domain, so that there is a separation between your cookies and your scripts and the third party cookies and their scripts. This goes for all other widgets as well.
In the above two examples, the developers aren't being paid or are receiving revenue in exchange for installing tracking cookies in their origin, they are just letting it happen because they don't care and they want things to be easier on them.
I get that there are ad supported websites, and if this is your business model, then you are free to give it a go -- but I get upset when the justification for the tracking cookie is developer convenience rather than any kind of business decision to drive revenue.
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.
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.
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?
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.
https://news.ycombinator.com/item?id=13034936
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.... on how to make Homebrew not send analytics data any more.
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)
This, like some other special powers, is something that the user should have to explicitly grant to an extension via permissions interface.