The issue raised by the reporter might be in https://challenges.cloudflare.com/ being also used by the page.

Let us use this issue to track Cloudflare issues in general. I will add quotes from e-mails archives:

Websites that use the cloudflare JS challenge or cloudflare under-attack-mode
(with the captcha) don't work while JShelter is on.
It requires WebWorkers at the minimum and some other stuff i didn't track down
yet. They only work with JShelter being off...

Examples of affected pages (not necessary updated):

• https://www.zabbix.com/forum/zabbix-help/
• https://check.spamhaus.org/
• 4chan, which asks for a cloudflare verification captcha in an embed before posting.

One JShelter user said:

The verification itself happens inside an iframe with an https://challenges.cloudflare.com/... URL. Would there be a possible approach to detect that iframe?

• Click on JShelter badge icon -> click "Global settings" in the popup.
• You should see the option page
• Locate "Fingerprint Detector" section neear the bottom of the page.
• Click "Manage exception list ⤵" (it should be the lowest button on the page).
• Add "challenges.cloudflare.com" to the list.
• Click "JS Shield details" in the menu
• On the top, add "challenges.cloudflare.com" and select "Turn JavaScript Shield off" (or test other level if you see fit).

But the user said:

Thanks, i tried that, it didn't work with any kind of cloudflare challenge.

I can only pass the challenge if i disable shield and fingerprint detection on
the domain that is behind the cloudflare challenge.
Like on https://check.spamhaus.org/, i have to whitelist check.spamhouse.org,
not the challenges.cloudflare.com from the iframe.
Same at https://www.zabbix.com/forum/zabbix-help/

There is a script on the challenge page that talks to the iframe, that seems
to be the relevant one.
I think it's not possible in any other way. Every website that is behind that
horrid challenge has to be fully whitelisted or won't work at all.

Is there a way to whitelist the cloudflare scripts only, without having to whitelist the whole domain?

Short answer: no, JShelter patches the JS environment that is common to all the scripts included in the page. There is currently no way to say that a script injected from domain X should see function X as Worker while another script should see function Y as Worker.

Long answer: technically, there are two approaches to solve the issue.

Approach 1: Intercept HTTP replies containing scripts from some domains and patch the code, like replacing all calls to Worker with calls to WorkerJShelteraabbccddeeff... I see at least two downsides of this approach. Firstly, an obfuscated code is not possible to patch this way. Secondly, we would need to create functions that these privileged scripts would call. However, these scripts should be available to privileged scripts only. My proposed way contains the string aabbccddeeff... for this reason. By creating a random value for each page refresh, we might try to hide from other scripts, but malicious scripts could try to brute force the search for the current value. With sufficient length of the random part, we could motivate the adversary not to try brute force. However, malicious scripts could go for more clever ways to uncover the current unwrapped name like:

for(var prop in window){
  if (prop.startsWith("WorkerJShelter")) {
      console.log(prop); // Replace with some malicious code
  }
}

Approach 2: Current wrapped function can learn the identity of the callers and detect the origin of the scripts (see https://pagure.io/JShelter/webextension/issue/52). However, the approach is slow. So a possible solution to the problem is to let users explicitly ask to apply lower protection for some scripts with the warning of receiving performance hit? Additionally, the question is how to design the UI and actually implement the functionality.

Suggested first step in trying to close the isue: The problem is in Cloudflare detecting that some fingerprinting protection is being applied. Maybe the first step should go in the direction of studying Cloudflare way of detecting fingerprinting and finding way to prevent the detection.

That is true there are a few settings that breaks Cloudflare however fingerprint detection alone also breaks the Cloudflare captchas, even the detection behavior set to "passive".

How Cloudflare detects the fingerprint detector?

https://academy.patika.dev/sign-in
on the website, i clicked on the email login option. i turned off jshelter extension javascript schield and fingerprint protection for the website. but cloudflare "verify you are human" gives error. jshelter gives error even though i turned off protections. i have to disable/close jshelter.

error:
"Your browser is out of date. Update your bowser to view this site property.

Click here for more information"

https://developers.cloudflare.com/fundamentals/get-started/concepts/cloudflare-challenges/#browser-support

Disabling it from extensions is annoying. it also turns off javascript shield in other tabs. then you have to turn it back on.

Put a special jshelter verify for human block on-off button for cloudflare.

Or a button to disable and enable the plugin only in that tab.

I tried a lot of experiments. I tried about 30 combinations of settings. I refreshed the page every time. Most of the time I clicked on the Remove button next to JShelter > Global Settings > JS Shield details > A list of websites with redefined JavaScript Shield: > I clicked the Remove button next to websites's , I changed the settings, refreshed the page. I tested many combinations. I also manually tested the settings one by one.

Then I decided to report back here.
the problem persists even if you turn off javascript schield and fingerprint protector. If I turn off or uninstall JShelter from the Manage Extensions page (chrome://extensions/?id=ammoloihpcbognfddfjcljgembpibcmb) the problem should be fixed.
It is completely caused by JShelter.
Turning JavaScript Shield off doesn't help. Setting JavaScript Shield to Recommended doesn't work either. Manually weakening the settings doesn't work either. Turning off JShelter works.

FingerprintingActivity⤵
Definition of fingerprinting behavior by FPD module.
BrowserProperties⤵
Fingerprinting methods based on simple information gathering by accessing certain APIs.
NavigatorBasic⤵
Basic information about browser and system.
- Navigator.prototype.userAgent (17)
- Navigator.prototype.language (9)
- Navigator.prototype.languages (4)
- Navigator.prototype.platform (9)
- Navigator.prototype.productSub (8)
- Navigator.prototype.product (9)
- Navigator.prototype.vendorSub (8)
- Navigator.prototype.vendor (9)
- Navigator.prototype.appVersion (9)
- Navigator.prototype.appCodeName (9)
NavigatorHardware⤵
Hardware information about device.
- Navigator.prototype.hardwareConcurrency (8)
- Navigator.prototype.deviceMemory (8)
NavigatorMobile⤵
Information about features supported by mobile devices.
- Navigator.prototype.maxTouchPoints (8)
LocalizationInfo⤵
Localization details and keyboard layout.
- Date.prototype.getTimezoneOffset (1)
WindowInfo⤵
Information about screen from root Window object.
- window.devicePixelRatio (8)
- window.innerWidth (12)
- window.innerHeight (8)
- window.outerWidth (8)
- window.outerHeight (8)
StorageInfo⤵
Availability of WebStorage technology.
- window.localStorage (13)
- window.sessionStorage (7)
- window.indexedDB (7)
NavigatorFlags⤵
Binary browser settings.
- Navigator.prototype.cookieEnabled (5)
- Navigator.prototype.doNotTrack (9)
TimeInfo⤵
Information about exact time values.
- Performance.prototype.now (979)
- Date.now (5)
CrawlFpInspector⤵
APIs often abused for fingerprinting according to FP-Inspector study.
- Navigator.prototype.languages (4)
- Navigator.prototype.productSub (8)
- Navigator.prototype.vendorSub (8)
- Navigator.prototype.appCodeName (9)
- Navigator.prototype.hardwareConcurrency (8)
- Navigator.prototype.maxTouchPoints (8)
- Navigator.prototype.doNotTrack (9)

Time precision 1000+ number of the calls
Device memory and CPU 16 number of the calls
Others 0

Click on the Modify button next to the JavaScript Shield label.
What is the highlighted level button text?

I tried Strict. It didn't work. I tried Recommended. It didn't work. I tried Ecperimental. It didn't work. I tried others. It didn't work. I changed the settings manually, still didn't work.

This comment cannot be deleted

This comment cannot be deleted

@universish Please read https://pagure.io/JShelter/webextension/issue/148#comment-961474 and do not clutter this issue.

@hardenedsteel :

How Cloudflare detects the fingerprint detector?

This is something worth investigating and an important answer to learn.

Also regarding https://pagure.io/JShelter/webextension/issue/148#comment-961474, a possible start for investigation is to see if turning off JS Shield and FPD for challenges.cloudflare.com allows the verification to complete.

Another affected page is Gitlab.com, see #83, specifically https://pagure.io/JShelter/webextension/issue/83#comment-971364.

I repeated the test in that comment for https://www.zabbix.com/forum/zabbix-help/ and https://check.spamhaus.org/:

1. In Chromium with default configuration, both pages behaved as expected. I saw a human-confirmation page. After completing the human test, I proceeded to the site-specific page.
2. Now focus on Firefox, visit one of the pages.
3. Globally set challenges.cloudflare.com to no JSS protection.
4. Disable FPD for the affected domain (even if it is in passive mode).
5. Set Worker protection to Strict for the domain.
6. I was allowed to enter.

It would be great to learn stricter settings for step 3. The question from the previous post remains, why do we need to disable FPD? Also, it is worth investigating why Firefox and Chromium behave differently.

The question regarding Strict and Remove Worker settings is already opened at #156.

Click on JShelter badge icon -> click "Global settings" in the popup.
You should see the option page
Locate "Fingerprint Detector (Main Settingsin the menu > Fingerprint Detectorin the path)" section neear the bottom of the page.
Click "Manage exception list ⤵" (it should be the lowest button on the page).
Add "challenges.cloudflare.com" to the list.
Click "JS Shield details" in the menu
On the top, add "challenges.cloudflare.com" and select "Turn JavaScript Shield off" (or test other level if you see fit).

I did what was written.

I refreshed https://academy.patika.dev/sign-in . I tried human verification. It gave me an error:

Error
Having Trouble?

Then I clicked on the JShelter icon on the https://academy.patika.dev/sign-in web page and turned the JavaScript Shield and Fingerprint Detector buttons OFF.

I refreshed the page. I tried again. It gave me an error again:

OS: Windows 11 Pro 64-bit 24H2 26100.3915
Browser: Ungoogled Chromium 136.0.7103.49 64-bit

I have the same problem with the catcpha with the photo. the catcpha that says cern and the atoms hit. I don't know the name.
Disabling the jshelter extension solves the problem.
Adding fingerprint detector to white list doesn't work. Javascript was changed and setting Fingerprint detector to off doesn't work either.
I had this problem with the standardnotes app website (https://app.standardnotes.com/).

Hi, first issue comment so before anything, great project! I discovered it via NLNet and it's (sadly) much needed on the current Web.

Anyway, just wanted to highlight, without contributing much unfortunately, that this is my main challenge with JShelter and the rising popularity of CloudFlare makes it worst day by day. A lot of websites (probably due to AI bullshit scrapping) rely more and more on CloudFlare to "verify" that I am indeed human and that triggers JShelter. Typically the only way I found to "go through" is to disable JShelter on that page entirely.

If there is any way I can help (adding here websites where it happens?), happy to try.

Hello @utopiah,

please see https://pagure.io/JShelter/webextension/issue/148#comment-971371. I tried with the three websites mentioned there and a better configuration is:

1. Globally set challenges.cloudflare.com to Strict JSS protection with Strict Worker protection.
2. Disable FPD for the affected domain (even if it is in passive mode).
3. Set Worker protection to Strict for the domain.
4. I was allowed to enter.

I have not checked https://academy.patika.dev/sign-in listed later in this issue and https://app.standardnotes.com/ (https://app.standardnotes.com/ does not look like Cloudflare so it does not belong here).

Thanks @polcak I'll try this and report back. I hope others who have similar issues will find this suggestion too.

Also I don't know if it's a good idea to check for CloudFlare specifically, because then it's making it quite specific to a commercial "service provider", but since they became so central maybe a hint on FD toggle if CloudFlare has been detected as the "offender" could help newcomers like me. I worry that if people don't dig deep (and end up here) they might just disable everything (bad) or even remove the extension entirely (even worst)*. I insist here just a bit because, maybe pessimistically, I expect CloudFlare and such "human" detection to keep on growing.

• : few years ago a friend removed his ad blocker precisely because of this. He did acknowledge it was better when it worked but the lack of predictability made it too risky for him.

I started a discussion in our mailing list, see https://lists.nongnu.org/archive/html/js-shield/2025-09/msg00007.html