art19.com

[ZiggyTheHamster]

Hi!

I'm a software engineer for ART19, and we're having some false positives that are causing issues. When our users work with advertisements, the API calls all go to URLs containing advertisements. This gets blocked, which causes the app not to function. We also have URLs with ad-rep, ad_rep, and advertiser in the URL. All of our ads are audio files which are embedded within other audio files which eventually come from a CDN, so blocking these endpoints in EasyList causes us to get support calls rather than ads blocked.

How can I get some whitelists? I'm happy to submit a PR if there's a documented process for that. I definitely don't want to do an annoying "disable your adblocker" thing, especially since these are just the API endpoints that represent the abstract concept of an advertisement, advertiser, or ad rep and not actual ads themselves. From reading the EasyList policy, I think that it should be policy to fix these false positives, but feel free to correct me if I'm wrong.

Thanks! I really appreciate what you guys do, as an EasyList user myself

[smed79]

Hi,

how to reproduce the issue?

[ZiggyTheHamster]

You cannot; this is something that our customers are running into. If you were a customer with the appropriate roles, you would get an error toast notification and a broken app whenever you navigated to any campaign or advertisement related pages. The current advice/support ticket script is to have them disable their ad blocker for our domain, but some of them have routers which have ad blocking enabled and they don't know how to turn it off.

I would be happy to screen share a failing example with you if you need proof this is breaking something and not me trying to sneak in ads that aren't blocked

[fanboy]

I'd recommend changing it on server side.

[ZiggyTheHamster]

I really don't want to make my API endpoints different because EasyList has a blanket *advertisement* rule. It also would be a breaking API change unless I hook up two routes to the same controller, which is not preferable.

I also don't want to prompt our users to disable their ad blocker either. I personally use EasyList and ABP and find the "disable your ad blocker" messages annoying. And in our case, we're not even trying to render ads, so almost nobody thinks the error messages they get when fetch requests fail are due to their ad blocker.

Is it possible to whitelist based on what the Accept request header is? All of our API calls are application/*+json

[smed79]

Read this thread to get an idea.
viewtopic.php?f=64&t=35937

[ZiggyTheHamster]

So what you're saying is that there is no way that I can get a whitelist to fix EasyList mistakenly globbing API endpoints that our single page application accesses?

This leaves my options at:

1. Use a different name, with no guarantee that EasyList doesn't add a rule to break our application again.
2. Add a warning that the application will be broken if we detect an ad blocker (this is obnoxious and I hate it).
3. If possible, check if a failed request was blocked, rendering a better error message than "Sorry, an unexpected error occurred." This isn't awesome because I'm not sure that every combination of ad blocking software and browser will detect blocks this way.

I read the VMware threads - one thing different here is that the domain name doesn't change.

[fanboy]

If it applied to a site, thats testable, then its fine we'll whitelist for that site.

When you're using the unfortunate name "advert", "advertisement" or even "ad". Its not for us to change after all you're using a common adblock term. I wouldn't expect anything else but for Easylist to block it.

[ZiggyTheHamster]

I can look into getting you an account to test with if that's the only impediment. These resources are so named because they are the object that represents an ad creative (advertisements), the object that represents the account which "owns" ad campaigns/creatives (ad_rep_accounts), or the section of the site corresponding to the tools used by ad rep accounts (ad-reps). For the first two, I could theoretically change the endpoint to something obfuscated and maybe not hit EasyList, but the last one is in the URL bar and Ember Engine name, so that entire section of the app may end up not working.

Like I said earlier though, these are just the JSON objects that describe these advertising concepts. The actual ad serving, where EasyList is able to block, is unaffected by whitelisting these endpoints.

I would love to get this fixed via a whitelist - if our customers are using EasyPrivacy for example, I would want that to continue to function without needing to be disabled so the application works. If you need a login to make that happen, I can check with my team to see what we can accommodate.

[fanboy]

If you give us a site to whitelist, then it can happen. But we're not going to whitelist all the sites.