News for hackers. Stuff that matters.
Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by gkop on Thursday September 24, 2015 @10:44PM (#10276117)
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)

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by rcsorensen on Thursday September 24, 2015 @11:03PM (#10276167)
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.

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by gkop on Thursday September 24, 2015 @11:41PM (#10276271)
JavaScript has had try/catch since forever though?
Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by tempestn on Friday September 25, 2015 @12:13AM (#10276334)
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.)

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by nitrogen on Friday September 25, 2015 @02:29AM (#10276659)
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.

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by yAnonymous on Friday September 25, 2015 @10:54AM (#10278506)
>when sites can't handle the absence of their Adobe

When sites that require flash break, isn't that a win for the user?

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by nitrogen on Friday September 25, 2015 @01:58PM (#10279624)
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.
Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by myfonj on Friday September 25, 2015 @08:32AM (#10277743)
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

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by look_lookatme on Friday September 25, 2015 @05:03AM (#10277022)
You expect people to go out of their way to support ad blockers???
Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by Tepix on Friday September 25, 2015 @05:14AM (#10277062)
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.

Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by gurkendoktor on Friday September 25, 2015 @06:47AM (#10277356)
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.
Re:Mozilla fixed a 14-year-old bug in Firefox, Adblock Plus ... by yAnonymous on Friday September 25, 2015 @10:52AM (#10278492)
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.