Privacy Browser Android

You need to make the domain name *.gitlab.com, which applies the domain setting to all gitlab subdomains. Your screenshot shows *gitlab.com (missing the first period).

Note that it takes a few seconds to get past the screen in your screenshot above. If waiting doesn't work, please delete all your domain settings that relate to GitLab. Then record a video similar to the one linked below. Watching all the steps will help me figure out where it is going wrong for you.

https://nextcloud.stoutner.com/s/p6f9JBYSiHfjELF

• videos
  • successful cloudflare verification on samsung internet v 22.0.3.1 and jquarks viewer [ f-droid repo ] v 1.0-19_ https://commons.wikimedia.org/wiki/File:Jquarks_viewer_1019_samsung_internet_22031_okay.webm
  • failed cloudflare verification on privacy browser [ f-droid repo ] v 3.15.1_ https://commons.wikimedia.org/wiki/File:Privacy_browser_3151_fail.webm

Perhaps Cloudflare doesn't like some aspect of the WebView default user agent on your device. Try using domain settings to set a custom user agent to be the following:

• still no luck_ https://commons.wikimedia.org/wiki/File:Custom_user_agent_cloudflare_verification_failure_privacy_browser_3151_fdroid.webm

• i have no issues with samsung internet, jquarks viewer; when i created this issue & now also
• to be on safe side, upgraded chrome to latest version
• i am wondering why two browsers depending on same_ webview, behaving vastly differently

It is very odd, because everything I see indicates that your setup is functionally similar to mine, but Cloudflare lets me log on to GitLab and blocks you.

As a curiosity, try switching the WebView provider from Chrome to Android System WebView (after you do this you will want to install the updates for Android System WebView). There is a video showing how to do this at https://www.stoutner.com/webview/.

It seems there is something about your setup that makes Cloudflare more suspicious of you than of any of the devices I have tested.

The only two possibilities I can think of are that either 1) Samsung has made some modification to Android on that device that makes WebView behave differently than it generally does. Or, 2) there is something about your IP address that makes Cloudlfare extra suspicious of your device.

There are a couple of things that make 1 unlikely to be true. The most significant is that jQuarks works, which also uses WebView. Additionally, as a test to see if Samsung devices in general have problems, I used a Samsung Galaxy Tab A7, and it didn't have any any with loading GitLab in Privacy Browser.

The principle difference I can see between Privacy Browser and jQuarks is that they use different ad blocking lists. These don't generally cause problems with GitLab, but it might be worth checking to see if disabling EasyList, EasyPrivacy, Fanboy's annoyance list, Fanboy's social blocking list, UltraList, and UltraPrivacy in Domain Settings for *.gitlab.com makes any difference.

The second possibility is that Cloudflare is particularly suspicious of your IP address. Do you have the ability to try a different device from your IP address or your current device from a different IP address?

• unable to complete verification after disabling all lists
• failure apps from fdroid: * foss browser v 9.11 * einkbro v 10.11.0 * monocles browser v 1.7.1 * smartcookieweb v 16.3 * fulguris web  browser v 1.9.8
• success apps from fdroid * jquarks viewer v 1.0-19 * mull v 116.2.0 [ etp: strict, standard ] * fennec fdroid v 116.2.0 [ etp: strict, standard ]

For the record, I also tried to display the GitLab's login page, and was also stuck in the same infinite loop.

Tested on Privacy Browser Android v3.15.1 "standard" (prod) and "alt" (test), recently downloaded, with my VPN client enabled and then disabled.

• JavaScript
• Cookies
• DOM Storage
• User Agent set as suggested in #note-9

• all filter lists

Out of curiosity, I tried logging in with jQuarks. For me, it didn't work (see the linked video below). I was using the app's default settings. When you were able to log in using jQuarks, did you have to make any changes to the settings first?

https://nextcloud.stoutner.com/s/B3teiSHkNNdXWJk

When you were able
to log in using jQuarks, did
you have to make any changes
to the settings first?

yes, disabled location access.
for any app immediately after
installation i disable all
other permissions except
storage.

@v ... @jindam vani The issue was strangely Images. Browserwide I've disabled it & enabling it for gitlab worked. Other configs like JS/DOM/Cookies/Filters have no effect on this.

The issue is probably different for different people over time as Cloudflare is constantly changing their algorithms. Sometimes there might be nothing a user can do to get through, but other times there are unexpected things that work, like enabling the loading of images (something bots often don't do, so a check Cloudflare is interested in).

If anyone finds something that is helpful, putting it here (or in the forum) is beneficial so that other users have a list of things they can try.

I'm sorry but if this issue is not in FOSS Browser or other webview wrappers, I donno how this is not specific to PB.
https://linuxiac.com/
Works on FOSS Browser, but stuck in cloudfare human verification on PB. Ticking the box doesn't even let me in either. It's just recursive.

FOSS Browser behaves differently than Privacy Browser Android, which Cloudflare can detect. If Cloudflare chooses to let FOSS Browser through there is nothing I can do about it because Privacy Browser doesn't mimic those behaviors on purpose.

For example, FOSS Browser sends the following header, even if you have disabled the X-Requested-With header using WebView DevTools.

In the end, Cloudflare wants to spy on you. They don't like browsers that won't let them spy on you. As Privacy Browser gets better and better they will move from sometimes blocking it to always blocking it. At that point, users have two options. 1) Use a different browser that lets Cloudflare spy on them to access websites hosted on Cloudflare. Or, 2) don't visit sites hosted on Cloudflare.

Got it. I believe option 2 but I mean, literally more & more articles started hosting their sites using cloudfare DNS servers. It's just getting exhaustive each time I'm encountering it on PB.