4 ms·

Honest question: is it really that difficult to make your site not broken by ad blockers? (Your response worries me in that it is an exceptionally convenient a

by gkop 11y ago

Honest question: is it really that difficult to make your site not broken by ad blockers? (Your response worries me in that it is an exceptionally convenient argument for sloppy developers not to fix their sites)

rcsorensen 11y ago
Yes. In the final analysis this question is equivalent to "Is it difficult to make a site that can have any piece of it fail to load or be removed at any time?" since website developers have no control over what may or may not make it onto the list of an adblocker.
- gkop 11y ago
  JavaScript has had try/catch since forever though?
  - tempestn 11y ago
    Ad blockers don't just block third party things though. Or even necessarily sane things. Our site is a classified ad aggregator. At the time at least, we learned that Adblock Plus would just blithely delete any element with 'ad' as part of its class. (A major section of our results page had the class 'ad block' (ironically) and was blocked.) Yes, these things can be worked around, but not every site maintainer will bother. (Especially since those adblock users likely don't earn them any direct revenue.)
    - nitrogen 11y ago
      The most egregious site breakage from ad blockers is when sites can't handle the absence of their Adobe or Google JS. Some sites have large amounts of content that is only loaded via three levels of third-party-JS indirection. Others will try to fire an event to Google Analytics on every click, but if GA doesn't load, an error is thrown that prevents the click's default action. I was making a $1000-range purchase on an ecommerce site that was utterly broken by my refusal to be tracked in intimate detail, and their product manager was basically, "eh." So I worked around it by catching the errors for them in the browser inspector. This is the type of breakage that site developers absolutely should be fixing.
      - yAnonymous 11y ago
        >when sites can't handle the absence of their Adobe When sites that require flash break, isn't that a win for the user?
        nitrogen 11y ago
        Adobe makes more than Flash. They have a number of user tracking, profiling, and A/B testing systems, plus an email delivery and segmentation system. Some or all of those things started as Omniture. Google also has Google Tag Manager, which is a third-party JS for injecting more third-party JS. When half your site's content is loaded by Adobe into "mbox"es, triggered by JS loaded by Google Tag Manager, it's a nightmare for real developers and end users alike even with everything working.
- deleted 11y ago
  [deleted]
look_lookatme 11y ago
You expect people to go out of their way to support ad blockers???
- Tepix 11y ago
  Do you want your shop to work despite people blocking the tracking? Do you want to sell stuff in your shop or did you build it to track people? Ad blockers don't just block ads.
- gurkendoktor 11y ago
  Depends on what their business is. Apple's $99-a-year developer portal recently broke because I block Adobe's Omniture tracking. The same happened to me on an ad-free, crowdfunded news site that I've backed. In these cases, "does not work with ABP/ublock/Ghostery" is a valid bug report.
myfonj 11y ago
There are situations when it is difficult or at leas annoying: sometimes blocking rules are too loose that generates false positives. Few examples from my personal memory: - "Block any image on any domain that has `/ad/` in its path." (Encountered in certain local block list, not present in such pure form at time of writing.) Found this one while inspecting bugreport of our client who complained he cannot see some images on his presentation we maintained. Our CMS serves static binary data with "folderized hash paths" where occurrence of `/ad/` is not completely avoidable. Even now Easylist [1] inludes many general `adsomething` rules that FMOPW could do many false positives. - "Block any flash that has `clickthru` parameter." This rule is still present in aforementioned easylist [1]: `.swf?clickthru=`, but amusingly is very easily avoidable (rule insists that this parameter is first). Back in times this parameter was de facto standard for embedded flash serving as hyperlink to tell it where to link to. Found this one when another client complained that his flash-based part of main navigation (supplied by third party studio) does not work. - Even now the question "Have you disabled your adblocker?" often relevant response to general WTFs during web-development. [1] https://easylist-downloads.adblockplus.org/easylist.txt https://easylist-downloads.adblockplus.org/easylist.txt
yAnonymous 11y ago
If the site has a proper layout and the ad blocker does its job, i.e. blocks only elements with ads, you won't have to do a thing.

by gkop 11y ago

rcsorensen 11y ago

Yes. In the final analysis this question is equivalent to "Is it difficult to make a site that can have any piece of it fail to load or be removed at any time?" since website developers have no control over what may or may not make it onto the list of an adblocker.

gkop 11y ago
JavaScript has had try/catch since forever though?
- tempestn 11y ago
  Ad blockers don't just block third party things though. Or even necessarily sane things. Our site is a classified ad aggregator. At the time at least, we learned that Adblock Plus would just blithely delete any element with 'ad' as part of its class. (A major section of our results page had the class 'ad block' (ironically) and was blocked.) Yes, these things can be worked around, but not every site maintainer will bother. (Especially since those adblock users likely don't earn them any direct revenue.)
  - nitrogen 11y ago
    The most egregious site breakage from ad blockers is when sites can't handle the absence of their Adobe or Google JS. Some sites have large amounts of content that is only loaded via three levels of third-party-JS indirection. Others will try to fire an event to Google Analytics on every click, but if GA doesn't load, an error is thrown that prevents the click's default action. I was making a $1000-range purchase on an ecommerce site that was utterly broken by my refusal to be tracked in intimate detail, and their product manager was basically, "eh." So I worked around it by catching the errors for them in the browser inspector. This is the type of breakage that site developers absolutely should be fixing.
    - yAnonymous 11y ago
      >when sites can't handle the absence of their Adobe When sites that require flash break, isn't that a win for the user?
      - nitrogen 11y ago
        Adobe makes more than Flash. They have a number of user tracking, profiling, and A/B testing systems, plus an email delivery and segmentation system. Some or all of those things started as Omniture. Google also has Google Tag Manager, which is a third-party JS for injecting more third-party JS. When half your site's content is loaded by Adobe into "mbox"es, triggered by JS loaded by Google Tag Manager, it's a nightmare for real developers and end users alike even with everything working.
deleted 11y ago
[deleted]

look_lookatme 11y ago

You expect people to go out of their way to support ad blockers???

Tepix 11y ago
Do you want your shop to work despite people blocking the tracking? Do you want to sell stuff in your shop or did you build it to track people? Ad blockers don't just block ads.
gurkendoktor 11y ago
Depends on what their business is. Apple's $99-a-year developer portal recently broke because I block Adobe's Omniture tracking. The same happened to me on an ad-free, crowdfunded news site that I've backed. In these cases, "does not work with ABP/ublock/Ghostery" is a valid bug report.

myfonj 11y ago

There are situations when it is difficult or at leas annoying: sometimes blocking rules are too loose that generates false positives. Few examples from my personal memory: - "Block any image on any domain that has `/ad/` in its path." (Encountered in certain local block list, not present in such pure form at time of writing.) Found this one while inspecting bugreport of our client who complained he cannot see some images on his presentation we maintained. Our CMS serves static binary data with "folderized hash paths" where occurrence of `/ad/` is not completely avoidable. Even now Easylist [1] inludes many general `adsomething` rules that FMOPW could do many false positives. - "Block any flash that has `clickthru` parameter." This rule is still present in aforementioned easylist [1]: `.swf?clickthru=`, but amusingly is very easily avoidable (rule insists that this parameter is first). Back in times this parameter was de facto standard for embedded flash serving as hyperlink to tell it where to link to. Found this one when another client complained that his flash-based part of main navigation (supplied by third party studio) does not work. - Even now the question "Have you disabled your adblocker?" often relevant response to general WTFs during web-development. [1] https://easylist-downloads.adblockplus.org/easylist.txt https://easylist-downloads.adblockplus.org/easylist.txt

yAnonymous 11y ago

If the site has a proper layout and the ad blocker does its job, i.e. blocks only elements with ads, you won't have to do a thing.