search

PopupMaker / Popup-Maker

Popup Maker plugin for WordPress
https://wppopupmaker.com/
104 stars 39 forks source link

Try to bypass ad blockers setting should bypass the Ghostery ad blocker Chrome extension #989

Closed marklchaves closed 2 weeks ago

marklchaves commented 2 years ago

Describe the feature request

The Try to bypass ad blockers setting should support (meaning bypass) the Ghostery ad blocker Chrome extension.

Use case

When I turn on the Try to bypass ad blockers setting, popups should display even when visitors have Ghostery running and blocking ads on my site.

Example screenshots (if any)

Demo of the issue and temporary workaround.

https://share.wppopupmaker.com/p9u6pp4m

danieliser commented 2 years ago

Do you know how they are blocking it? Others prevented files from loading from our popup-maker or /pum folders. So we randomized them. Have to figure out what they are doing first to get around it.

marklchaves commented 2 years ago

I think that's the million-dollar question. All the searches on how Ghostery blocks ads came up empty for me.

BTW, when I was troubleshooting this, I tried the ole ads.js trick. That didn't work. That's when I punted for a workaround.

krystian3w commented 1 year ago

On 1.18.1 works custom name instead randomize name. I used Slavic words instead of Germanic ones:

https://domain-name.TLD/script-with-slavic-name.js

I would avoid naming the script with the word "window", "pop-up".

However, my plug-in's settings broke again with a generic error message: "There must have been an error, the settings were not saved successfully!". So I can't check too much what phrase Ghostery will respond to - I would probably have to do such tests on a fresh WordPress installation.

danieliser commented 1 year ago

@krystian3w - the default is a random string, but we fully allow and expect users to enter whatever they are comfortable with. The thing is if we enabled it by default and had random file names you might not recognize, admins might see those random files loading, and not know where they come from assume they are compromised. If they have to explicitly enable it and set the name, they will at least not think they are compromised in some way.

Further those settings are not meant for admin setting screens, only for front end assets attempting to bypass visitors blockers, not your own. Admin scripts are not dynamically generated/renamed, always load from the plugin folder.

In general you should simply disable the blocker on your own sites.

krystian3w commented 1 year ago

For myself I can turn it off but how do I turn it off for anyone who uses easy list cookies / fanboy annoyances? The developer of both projects is more likely to reject my request to fix the domain when the pop-ups are not attacking users or with another pop-up I am loading GDPR/CCPA.

I'm assuming the author is reporting a problem that a random name or built from your own words doesn't help (That is, as if the Ghostery module listens for JS files and, based on the content, does not allow the startup - Only if such a thing suddenly has Ghostery is it worth running the " obfuscate javascript" option before ad blockers?).

As it is possible, maybe I would add, an option to make the field on the name know how to convert the forward slash (/) to folders:

https://domain-name.TLD/dummy-folder/script-with-slavic-name.js instead https://domain-name.TLD/dummy-folder-script-with-slavic-name.js

danieliser commented 1 year ago

All of those lists block by path to the file, and they are not gonna remove any domain for our plugin, tried before.

The file is generated and stored in your uploads folder as that is the only legit place in WordPress you are supposed to be saving files. Anywhere else has risks & tradeoffs.

We could allow for sub folder, but is it really needed? Can you justify a use case within the uploads folder for needing a sub directory that a simple name prefix with - or _ couldn't solve?

Also not all ad blockers use asset path blocking, some do html scrubs (looking for specific html elements & class patterns). If that is what Ghostery is doing, we would have to rewrite a substantial amount of the plugin to dynamically write out different structures for each site so there wasn't a pattern, and of course they would have to still work exactly like they do now for the hundreds of custom integrations that exists with our popups and other plugins.

We do plan to do the latter set of HTML scrambling changes, but as part of a larger rewrite so I don't have an ETA currently.