When we heard a client’s Marketo forms weren’t showing for users of AdBlock Plus, our first thought was they were embedding forms using the old marketo.com domain, which is blocked by privacy plugins.

 

But no, that wasn’t it: the forms were on Marketo LPs, not embeds, and they were using a proper LP domain. (Also, for the record, AdBlock Plus doesn’t care about marketo.com. Only Firefox Tracking Protection and equivalent plugins care about that.)

 

So what’s the deal? Well, here’s what you see in the console in Chrome:

 

Pretty standard, just means a 3rd-party plugin did the blocking. Looking at the AdBlock-injected console tab shows the deeper reason:

 

Now that’s interesting. See, the client is a media company, so naturally their B2B product is ad time. Their LP domain is https://ads.examplemedia.com, which fits the business.

 

Problem: AdBlock Plus, uBlock Origin, and other plugins use the EasyList crowdsourced database to determine what’s an ad. And that database has the following long-winded blocking rule, using EasyList’s proprietary syntax:

://ads.$~image,~xmlhttprequest,domain=~ads.8designers.com|~ads.ac.uk|~ads.adstream.com.ro|~ads.allegro.pl|~ads.am|~ads.amazon|~ads.apple.com|~ads.atmosphere.copernicus.eu|~ads.band|~ads.bestprints.biz|~ads.bikepump.com|~ads.brave.com|~ads.buscaempresas.co|~ads.business.bell.ca|~ads.cafebazaar.ir|~ads.chewy.com|~ads.colombiaonline.com|~ads.comeon.com|~ads.cvut.cz|~ads.doordash.com|~ads.dosocial.ge|~ads.dosocial.me|~ads.elevateplatform.co.uk|~ads.finance|~ads.google.cn|~ads.google.com|~ads.gree.net|~ads.gurkerl.at|~ads.harvard.edu|~ads.instacart.com|~ads.jiosaavn.com|~ads.kaipoke.biz|~ads.kazakh-zerno.net|~ads.kifli.hu|~ads.knuspr.de|~ads.listonic.com|~ads.luarmor.net|~ads.magalu.com|~ads.mercadolivre.com.br|~ads.mgid.com|~ads.microsoft.com|~ads.midwayusa.com|~ads.mobilebet.com|~ads.mojagazetka.com|~ads.msstate.edu|~ads.mst.dk|~ads.mt|~ads.nc|~ads.nipr.ac.jp|~ads.olx.pl|~ads.pinterest.com|~ads.remix.es|~ads.rohlik.cz|~ads.rohlik.group|~ads.route.cc|~ads.safi-gmbh.ch|~ads.scotiabank.com|~ads.selfip.com|~ads.shopee.cn|~ads.shopee.co.th|~ads.shopee.com.br|~ads.shopee.com.mx|~ads.shopee.com.my|~ads.shopee.kr|~ads.shopee.ph|~ads.shopee.pl|~ads.shopee.sg|~ads.shopee.tw|~ads.shopee.vn|~ads.smartnews.com|~ads.snapchat.com|~ads.socialtheater.com|~ads.spotify.com|~ads.studyplus.co.jp|~ads.taboola.com|~ads.tiktok.com|~ads.tuver.ru|~ads.twitter.com|~ads.typepad.jp|~ads.us.tiktok.com|~ads.viksaffiliates.com|~ads.vk.com|~ads.watson.ch|~ads.x.com|~ads.yandex|~reempresa.org

 

That rule means:

  • block all embedded content from domains starting with ads., unless
    • the content is a static image, or
    • the content is an Ajax/XHR/Fetch request, or
    • the domain is a known exception: ads.8designers.com, ads.ac.uk, etc.

 

A <script> tag, of course, isn’t an image or Ajax. And ads.examplemedia.com isn’t in the exception list. So <script src="https://ads.examplemedia.com/…/forms2.min.js"> is blocked.

 

The long-term solution is to change domains: something like brands.examplemedia.com or business.examplemedia.com gets the point across as well as ads.

 

The short-term solution the client pursued was to ask EasyList to add them to that long list of exceptions — domains that market ad space/ad time, but aren’t themselves ads. The EasyList folks were attentive, and now they’re on the exception list. But better to not have to worry about that!