AdBlock Detection [anti-AdBlock]

AdBlock Detection [anti-AdBlock] [Paid] v2.0.5

No permission to buy ($15.00)
Overview FAQ Updates (29) Reviews (2) History Discussion
Is there a reason why this cannot be purchased? It is in my cart and I click to pay [NEXT] (PayPal) and nothing happens. I've tried both Chrome and FF -- same result. I click to pay and nothing happens, churns and dies.
 
We are running Anti-AdBlock and AdBlock Tracker. Both are set up so that they ignore paid members. Paid members are still seeing ads. Also, the add-on is not ignoring the login page as established in the settings. Also, is there an expected percentage of participation DECREASE we should expect after implementing the add-ons?

Are these designed to be run together?
 
vtcnc said:
We are running Anti-AdBlock and AdBlock Tracker. Both are set up so that they ignore paid members. Paid members are still seeing ads.
Also, the add-on is not ignoring the login page as established in the settings.
Click to expand...
Anti-AdBlock Detection Usergroup settings - turns on and off the anti-Adbock message from being seen by specific usergroups - not the ads.
AdBlock Detected Tracker Usergroup settings - turns on and off the tracking/logging for specific usergroups - not the ads
Anti-AdBlock Detection page settings disables the Anti-Adblock message from showing on certain templates - not the ads.

To turn off ads for a specific usergroup you must edit the Display Criteria options for that specific ad, within it's settings in XenForo 2 under AdminCP - Setup - Advertising.

To turn off ads on certain templates you need to use the XenForo 2 built in setting, again this is under AdminCP - Setup - Advertising.

vtcnc said:
Also, is there an expected percentage of participation DECREASE we should expect after implementing the add-ons?
Click to expand...
I personally didn't notice any significant decrease in users. The main analytic that should should keep an eye on is "Bounce Rate" (the percentage of visitors to the website who navigate away from the site after viewing only one page). If after turning Anti-AdBlock Detection on and the "Bounce Rate" number increases significantly, then it is likely that visitors are choosing to leave year site versus turning off their adblocker. There are options withinh the add-on you can adjust to help lower the "Bounce rate". I think the wording of your anti-adblock meassage can also have an impact of those who choose to stay and turn off their ad-blocker also. You also can adjust the add-on settings to delay the adblocker a few seconds so visitors can at least see the content first, this way they can at least see if the content is something valuable, then you can display the anti adblock message. The key is to be sure to know your average "Bounce Rate" prior to turning the add-on on so you have something to compare to so you know what adjustments you make get you as close to where you were prior to turning it on.

vtcnc said:
Are these designed to be run together?
Click to expand...
Yes, they work well together, but aren't dependent on each other.
 
While testing some code for an add-on I'm working on, I happened to come across a small issue related to the css code of this add-on which creates an error when testing with W3C.

In template wutime_adblock_styles.less on Line 21:
CSS: 
background: fade(rgb(183,28,28), 90%);
I changed it to
CSS: 
background: rgba(183,28,28,.9);
and the error was cleared.

Possibly something to look at before the next release.

P.S. It also invalidates the <style> block within the page <body>, not sure if there is an easy way to inject it into the page <head> but that would clear that invalidation also.
 
Last edited:
It would be nice to be able to use colors from style, such as @xf-borderColor in wutime_adblock_styles.less.
 
Thought I'd share this Adblock Plus "threat" message I received about an hour ago...

email.webp

It appears at this time they have not defeated this add-on nor is there any sort of "endless reload" of pages occurring. I'll keep an eye on it, but at this time it is still working perfectly as it always has. I think @Wutime's randomization of page elements will be harder to crack than they have time to deal with. I think they'll just move along and go after easier anti-adblock targets. As for the message they sent, I think it was just a last attempt standard threat they use in hopes they can scare someone into removing anti-adblockers they haven't been able to defeat. Why else would they actually announce they have "defeated" your anti-adblock, seems they would want to go unnoticed as long as possible.

Thanks again for the great add-on!

...anyone else gotten a message like this?
 
@bzcomputers where did you receive this message?

Such a strange message, why would someone threaten you? Seems very odd and unprofessional.

"We will have browsers endlessly re-load your webpage" <- what is the point of this and how does this help end users of a website?
 
Wutime said:
@bzcomputers where did you receive this message?

Such a strange message, why would someone threaten you? Seems very odd and unprofessional.

"We will have browsers endlessly re-load your webpage" <- what is the point of this and how does this help end users of a website?
Click to expand...

It came through the XenForo "Contact Us" message link.

I thought it was quite odd too. It could have been anyone who sent it, but not sure why anyone would claim to be Adblock Plus if they weren't. Just odd all around.
 
Not sure if this is an issue only I'm having, but some of the users on my forum have complained that the "Adblock Detected" overlay is showing up even though they don't actually have any sort of adblock extension installed on their browser - is this because some browsers have in-built adblockers these days or is this a fault with the detection list?
 
In web access log seeing a small percentage of /wutime-adblocktracker/0/1 and /wutime-adblocktracker/0/0 requests returning 400 HTTP code. The vast majority are returning 200 HTTP code.

When analyzing those 400 HTTP code requests, the majority is related to the following user agents:
  • Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.92 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  • Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko; googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19
  • Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/80.0.3987.92 Safari/537.36
Please advise.
 
@Wutime did you have a chance to look at the reason behind those 400 Bad Requests? It keeps getting larger and larger. 10,000 such requests yesterday.
ivanp said:
In web access log seeing a small percentage of /wutime-adblocktracker/0/1 and /wutime-adblocktracker/0/0 requests returning 400 HTTP code. The vast majority are returning 200 HTTP code.

When analyzing those 400 HTTP code requests, the majority is related to the following user agents:
  • Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.92 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
  • Mozilla/5.0 (Linux; Android 4.2.1; en-us; Nexus 5 Build/JOP40D) AppleWebKit/535.19 (KHTML, like Gecko; googleweblight) Chrome/38.0.1025.166 Mobile Safari/535.19
  • Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Googlebot/2.1; +http://www.google.com/bot.html) Chrome/80.0.3987.92 Safari/537.36
Please advise.
Click to expand...
 
@ivanp the 200 HTTP codes are the proper AJAX POST calls.

The 200 HTTP codes would be the proper response for the AJAX POST calls.

I haven't seen any 400 requests. Do your logs provide any additional information?
 
You must log in or register to reply here.
Top Bottom