Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
marklchaves opened this issue Mar 4, 2022 · 6 comments

Comments

@marklchaves
Copy link
Contributor

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link

krystian3w commented Mar 21, 2023

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
Copy link
Member

@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
Copy link

krystian3w commented Mar 22, 2023

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants