Armed with this information I discovered the endpoint codepen hits when it detects that the ad-serving script is blocked!<p><pre><code> https://codepen.io/cpe/puppies-and-kittens?id=<id>
</code></pre>
It looked so innocuous it took me a sec to notice. You can definitely tell it's named in a way to avoid blocking rules. I appreciate the little humor too.<p>Codepen plays nice and just uses this for logging purposes. But when other sites take more aggressive anti-ad-block measures your ad-blocker can still defeat them by silently redirecting some analytics/ad-serving JavaScipt to an internal no-op resource. That way the error handler isn't called but the JS doesn't actually run. Or the JS is replaced with a no-op equivalent. See uBlock's resource library here: <a href="https://github.com/gorhill/uBlock/wiki/Resources-Library">https://github.com/gorhill/uBlock/wiki/Resources-Library</a><p>(I imagine a site like codepen, with its technical audience, sees a lot more users with ad blockers.)
“Hey the user clearly doesn’t want this. But I’m a web developer in 2023 and the user is my enemy! How can we do something the user explicitly does not want us to do?”
Amusingly, when javascripts are blocked on his site it is a black background with white text which is easier for me to read than the color scheme with javascripts allowed
hmm - i think the author is confusing all scripts from not being loaded as explicitly blocked.<p>there are other reasons the script may not be loaded and categorizing them as 'blocked' is not an accurate label. first example would be to curl the main page; and that is certainly NOT blocking the script
What’s the difference between this, and doing an XHR request to the same script with try {} catch {}? That is what we are currently doing. I guess it’s one request fewer if you need the script anyway, is there any other difference?