Tracking Blocked Scripts
chriscoyier.net
chriscoyier.net
https://codepen.io/cpe/puppies-and-kittens?id=<id>
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: https://github.com/gorhill/uBlock/wiki/Resources-Library
(I imagine a site like codepen, with its technical audience, sees a lot more users with ad blockers.)
If you're a business and you want to serve ads do it with plain text and images. If you need to track me do it with your server logs. You don't deserve anything else.
Lots of ads are text and images, but they're all placed client-side using scripts, because* nobody buys ads entirely untargeted (they're ineffective). If you're a business and want a purely server-side ad system to monetize your site with, you're going to be looking for a long time. What you're saying basically amounts to "ad-supported business models online should not exist." Which is an opinion you're entitled to, but if this is your stance I'd encourage you to at least try to, for a week, block all ad-supported sites, rather than the ads, to see what the logical conclusion to your policy would be.
*Note: Even without that reason, server-side would be unpopular with both publishers and ad networks because of the need to offer dozens of flavors of server-side SDKs that the publisher would have to integrate deeply into their SS code, rather than using the lingua franca of client-side JS.
So there is perhaps a bit of a balance to be struck. When Google Ads first started way back in the day they were simple fast text ads with content relative to the page you were reading. Since then ... a lot has changed, but I don't think the basic principle of it is necessarily wrong, just the implementation.
You can redirect people to porn sites without JS too by the way; via a HTTP header or a meta tag. If they can inject JS they can probably also inject one of those. Don't think you can really blame JS as such for that kind of stuff.
How? Genuinely interested to know how this attack happens without a click from the user.
See https://en.wikipedia.org/wiki/HTTP_302 and https://developer.mozilla.org/en-US/docs/Web/HTML/Element/me...
I liked this argument from idlewords:
https://idlewords.com/talks/what_happens_next_will_amaze_you...
"""Advertisers end up right back where they started,still not knowing which half of their advertising budget is being wasted. Except in the process they've destroyed our privacy."""
>The losers are small publishers and small advertisers
This is not true. In fact small publishers and advertisers are the ones that benefit the most from targeted advertising since it means they will have to spend less to get a customer. If it becomes too expensive for a business to get customers they will go out of business.
Somebody going out of their way to name a file erroneously with the intent bypassing a security and privacy control I’ve gone out of my way to deploy is not what I’d call humour, it’s disgusting.
I understand you might not even want to signal this to them. That's why I shared the endpoint it's hitting. I want people that really don't want even this type of logging to be able to easily add a block rule. I admit in retrospect a less hidden and more obviously named endpoint would have been more polite. Personally, I really think it's a stretch to call it 'disgusting'.
I think you have the right to track the usage of your product. And if you are ad-supported and not a sole proprietorship, you have an obligation to your business to at least know whether your monetization strategy is failing due to your users' ad-blocking preferences. The "% who block ads" figure is vitally important in deciding, for instance, whether to offer an ad-free paid tier.
If someone is using ad blocking, especially with custom rules, they are saying, loud and clear, they DON'T WANT most JavaScript running.
web developers should just respect that and move on, not try everything the browser allows in order to ram it down their throats. Theres really no excuse for it. with browsers essentially acting as operating systems these days, you're basically trying to justify malware.
IMO if users block ads then I imagine the websites are well within their rights to deny service or ask for other forms of payment.
Don't make something appear to be free, and then try and swindle someone down the road. Ask for money or don't. Painting a user going to an unsecured site as "taking without giving" is disingenuous. If the website is open to all, it is free, and there is no expectation of payment.
> IMO if users block ads then I imagine the websites are well within their rights to deny service or ask for other forms of payment.
If a site expects to be paid, make it a paid site. Block me from entering. If not, it's free, and don't put ads on it. If you want to appear free but try to force me to receive content I didn't request, I will block it. Simple as.
Creators and hosts are paying for the resources to serve to the public. They can block the blockers if they wish.
Making things only paywall-ed or entirely free will just lead to more 'native' ads disguised as content and less content available to the unbanked and less affluent.
And I'm free to turn the volume down on my TV or radio when the ads come on. They don't attempt to block me from doing this.
> Creators and hosts are paying for the resources to serve to the public. They can block the blockers if they wish.
You seem to have forgotten what we're discussing, so I'll quote it again
> Respect user's taking without giving anything in return?
This is what a free site suggests, and is not immoral. I am allowed to control the content on my machine, so I'll block the content that makes it to my screen as I see fit. If a website doesn't like this, they're welcome to make their content paid and I'll simply not look at it.
> Making things only paywall-ed or entirely free will just lead to more 'native' ads disguised as content and less content available to the unbanked and less affluent.
If you're saying "You must look at ads or advertising will get worse", I categorically reject both sides of your argument.
Now you say "they're welcome to make their content paid and I'll simply not look at it".
So people should pay their rent, how?
This reminds me of that YouTube discussion last week were people were up in arms that they might have to pay, and then the very same people were also up in arms that YouTube has ads.
Either come up with a viable alternative or accept one of those two options.
Yes.
> Now you say "they're welcome to make their content paid and I'll simply not look at it".
Ask for money and give me the opportunity to decline (which I will, for almost all content that currently contains advertisements).
> So people should pay their rent, how?
Is your argument seriously "Advertising is a proxy for UBI"? Injecting toxic content into your website and forcing me to look at it doesn't seem like a worthwhile strategy for either the consumer or the website owner.
> This reminds me of that YouTube discussion last week were people were up in arms that they might have to pay, and then the very same people were also up in arms that YouTube has ads.
I will not pay for YouTube, and I will not look at YouTube's ads. If they want to make the service paid only, they can, and I'll simply use a different service. Simple as.
> Either come up with a viable alternative or accept one of those two options.
You seem to misunderstand. My job is not to strategize for other people as to how they can skim money off unpaid content. I'm a consumer. My interests are very obviously self serving. I don't watch ads, I won't support content that pumps ads, and I'll continue to block ads very aggressively. I'm uninterested in brainstorming how people can try to deceive me for their gain and my loss.
It's not the end users job to answer that question.
Admittedly, the site could probably use CSS to make this decision as well, but I figured I'd mention it.
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