I spent some time comparing different adblock and browser combos, adblocking DNS and pi-hole blocklists. In the future I’m going to test more services like NextDNS and put all this information into a spreadsheet. I didn’t use any automation for this, so there may be errors.
A few observations I noticed.
Tests on the same configuration can have different results, but they will only be off by a few points.
More blocklists caused speed and adblocking problems.
Control D Free performed better than the paid version.
Control D 3rd Party blocklist would have different results if the same blocklist is used in pi-hole.
You need to press Ctrl+F5 to clear the cache after each test, or the cache will cause the test results to stay the same.
d3ward acting weird. For example I was using Control D Paid + Hagezi Pro Plus and Strict Ad Blocking, and on the site it says AWS, Google and all other domains are blocked
I tested with Safari (17.4.1) on macOS Sonoma (14.4.1) with Wipr as the Adblock which uses EasyList, and Quad9’s 9.9.9.9 which only blocks malicious domains. It blocked 137/140 (98%). The only domains that were not blocked were ads.pinterest[.]com, ads.youtube[.]com, and ads.tiktok[.]com
Don’t use testing sites as a measure to choose tools for your browsers. They have very few experiences how websites’ ads works and have many flaws:
They cannot detect that the blockers redirect blocked connections to noop / neutralized “web accessible resource” of the blockers (which of course is the purpose of redirection: make websites think that the resource is loaded successfully to defeat breakages / anti-adblock…)
There are domains that are NOT used in real world websites. api-adservices.apple.com ONLY appears on Apple stores/apps, NOT on websites. ads.youtube.com does NOT appear on websites. /pagead.js was one of the most common BAITS of the websites to detect if users are using blockers or not. Any good blockers / lists won’t just block that path alone to prevent anti-adblock / breakages…
Yeah, I wasn’t saying that it was a great tool to test. I know Safari isn’t as good at blocking stuff by default compared to Brave, and Wipr isn’t as effective as uBlock. Just interesting to see. It’s just like EFF’s Cover Your Tracks isn’t actually that reliable to test how your browser does in protecting against tracking and fingerprinting.
I agree that they may not serve real ads or use the same URLs as real ads, but you don’t think any information from these test sites is useful?
For example, when I increased the Control D Paid DNS Ad Blocker from Relaxed, Balanced and Strict, you would see that the adblock test sites reflect more blocked trackers and ads.
If this is the case, what would be the best way to test different adblock configurations?
No test is better than monitoring via your real usage, and knowing what exactly each list is focusing on. Watching the domains stats on your DNS service is already lacking some information about which app fires which connections, let alone just watching some few fixed domains / paths in a test website that may not ever appear in your usage and lack a lot of other ads / trackers.
On android, tools like rethinkdns can help to see which domains come from which apps. On windows, there’s portmaster. I don’t know about linux and mac, but there’s opensnitch / littlesnitch iirc. On other platforms, better to separate browsers with a different DNS so you can focus on the connections of the softwares outside browsers. Blockers on browsers already have much more capabilities than DNS.
Any deviation from the above means you have bypass/redirect rules for some Services, which whitelist certain trackers in order for them to work. This is mentioned when you create rules for such services.
In fact, the Relaxed filter should give you the same score - 97, if you have no other service or custom rules (which would be the case with a Free version).
Relaxed filter does allow some Google domains (tagmanager, which is incorrectly shown as Google Analytics here) so sponsored search results work.
Thanks for the input. I think this method gives some strange results. I thought this might be a reliable way to test content blockers, but I think what @eqrlzo8t alluded to, the best way would be to monitor during real usage.
