1909961 - privacy.resistFingerprint breaks Cloudflare Verification

Status: RESOLVED FIXED

(Core :: Privacy: Anti-Tracking, defect)

Description

[dundir]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0

Steps to reproduce:

Setting privacy.resistFingerprint to true causes Cloudflare Verification to infinitely loop or fail, repeatedly (forever).

• This also occurs in a number of other configurations where this setting may be set to false.

Actual results:

I visited https://community.cloudflare.com, clicked signup. The verify widget fails forever. Several other additional websites have the same thing happen (i.e. pathofexile.com/login being one, they have a number of players who have had this ongoing issue in their technical forums going back 2 months).

This seems to have started about two months ago, the apparent cause is cloudflare challenges now requires access to APIs which may or may not have the fingerprinting facilities available (unrelated but also an issue for other browsers, PS5,Safari,etc).

Cloudflare's default policy appears to block any device not having these facilities. They direct any problems to the business using them (which falls on deaf ears, or results in a referral back to contacting Cloudflare in an infinite loop).

ResistFingerprinting=true causes this to be testable/repeatable, but also a number of Extensions that block access to, or fake the History, WebGL, and Canvas APIs will also fail these challenges. This latter use case can be replicated by installing the Extension CanvasBlocker (for granular testing per protected API), or with certain options set in uBlock Origin.

Worryingly, the challenges fail, in a way that cannot be easily cleared, isolated, or tested and this seems by purposeful design on Cloudflare's part.

Of particular note, the Ray IDs and other resources do not change or update between page refreshes, even between private tabs (that should normally clear any stale cache). It appears that there is a long-running timeout before their webserver refreshes these resources, further confounding troubleshooting efforts at the network edge.

There are also a number of web developer console errors that also occur, but these appear to be a red herring, many of these occur even when the challenge succeeds.

Expected results:

The website widget should pass the challenge, and redirect to the protected website allowing login with the appropriate credentials, which you are prevented from submitting prior to passing the challenge.

This is blocking all web access to any cloudflare protected website on Firefox, including Cloudflare's own community site.

This is not solely limited to privacy.resistfingerprinting=true. I've had a number of Linux builds have the exact same issues without any extensions installed, or this setting set to true in about:config.

Some build flags may impact this in ways that are not immediately clear since Cloudflare does not disclose exactly what they are testing as part of the challenge (afaik).

Comment 1

[Paul Zühlcke [:pbz]]

We tried on 3 different machines and could not reproduce. Please make sure to test this on a new Firefox profile with just privacy.resistFingerprinting=true.

Comment 2

[dundir]

As of this morning, ~10:30 PST, Cloudflare now appears to be passing verification's without issue.
The Ray IDs now appear to be updating to a new unique Ray with each refresh as well.

There is no longer a 403 error being returned following submission of the XHR challenge POSTs, both on their own forum website and other sites.
Resist Fingerprinting=true passes, as do the extensions previously mentioned. Even Canvas Blocker is working (aside from the fake mode screen API which was previously known to not work correctly, and needed to be a static resolution).

I had originally tested with my original profile and also with a new test profile I had created.

I'll be putting it through a few more paces later tonight to ensure its fully corrected now, but it certainly looks like Cloudflare has fixed whatever they had broken over the past several months.

Comment 3

[Harshit Sohaney [:hsohaney]]

Were there any new breakages that you noticed in your tests?

Comment 4

[dundir]

No new breakages in the Windows package. The Linux package was a bit more finicky, but still passed within a few attempts. Both were failing in an infinite loop previously.

Comment 5

[Harshit Sohaney [:hsohaney]]

I'll close this as fixed for now, if this ends up happening more, feel free to reopen this bug and we can look into it!