adammartinetti

Hi there! Original commenter .

> So who is to say that the people complaining in the original post were using Turnstile or not?

I'm sorry if that wasn't clear, but they were all using Turnstile (either in a Cloudflare Challenge or implemented in Turnstile individually). By the time of the original post, there was no difference between the two.

> I didn't really see anywhere in the post where it discussed why they were getting so many false positives, and blocking real humans

If you take a look at the section on what we learned in the beta, we mention the two biggest sources of false positives we received during the beta period are 1) incorrect system time and 2) privacy settings that restricted the execution of third party scripts entirely. In both case, there wasn't an easy "just fix it" option, but we surface the issue obviously in the managed challenge and via a Turnstile error callback, which should allow users to see clearly what the problem is.

We've also finished rolling out (update on the blog article, which states this was in progress) our challenge feedback reports, so we can better track when groups of users are impacted in ways where they can't render the challenge in the first place. This was an area where we had difficulties understanding the scope of a problem previously, because our telemetry relies on the widget to load in the first place.

We'll continue to use the new data we're gathering to continue making reliability improvements when we find issues. Ensuring we can accurately identify human users is fundamental to the success of Turnstile as a product, so this will always be a high priority for us.

Thanks for the examples! Would you be able to share browser and extension information with me? If you don't want to share publicly I've dropped my email in this thread.

I'd love to get more information from you on this. We don't see any suspicious signals from these attempts, and it looks like they were completed 100% successfully from our perspective. You can drop me an email at amartinetti at cloudflare dot com.

Would you be able to drop me an email at amartinetti at cloudflare dot com with more information on your setup? Some of the signals we're getting from your browser don't seem to match what we'd expect to see. We'd love to better understand what's causing the mismatch so we can improve our logic.

I think this is fair! I can promise a public blog update in the next 90 days that includes a progress update on the work we're doing now to reduce real humans being blocked and announcing the feedback form users can click on to easily let us know when there's a problem.

Would you be able to clarify your comment about ublock origin? Cloudflare's challenge page (any captcha provider as well) is a third party script. If I enable these settings I don't see the challenge load as all. Are you enabling ublock origin before entering the challenge or sometime later?

Thanks so much to you and everyone else who's supplied these. I'm collecting them now, and the team is looking into this.

Do you see the challenge and then you're able to pass? Or does the challenge loop forever?

Would you be able to send me a rayID of a failed challenge so I can take a loop? It sounds like you can use https://gitlab.com/users/sign_in to generate one.

You can either reply in the comments with the ID (no PII), or email me at amartinetti at cloudflare.com and I'd love to dig into it.

We're building Turnstile because we want to make challenges a better system than CAPTCHA. It sounds like for you it's worse, and we want to fix that.

Hi there, I'm the PM for Cloudflare's challenge platform. I'd love to look into what the cause of the problem is, so you don't see these difficulties.

> Cloudflare detected the high frequency of requests and denials (but not their faulty loop that caused this pattern of requests, of course), and tagged my browser as suspicious.

I can tell you at least that we don't penalize users for this looping behavior, so this wouldn't cause us to see your browser as suspicious. I hope we can dig into this more and uncover the cause of the problem.

Personally, I'm a big Firefox user, and this isn't behavior I see. If there were a widespread Firefox wide issue, automated alerts would trigger and we'd consider this a critical incident.

You can drop me an email at amartinetti at cloudflare if you're interested in troubleshooting.

Would you be willing to share a rayID you see during one of these looping challenges? I'm the PM for Cloudflare's challenge platform, and we'd love to look into this. RayIDs contain no PII so you can share publicly, or feel free to drop me an email at amartinetti at cloudflare.

We'll also release a reporting mechanism soon, so in the future you can let us know when you see these issues and we can react to them quickly.

Hi there! I work at Cloudflare. Our global performance for linux users on challenge pages looks good at the moment, but I'd love to take a closer look.

Could you send me an email with details you have available, (rayID, IP address + website, or HAR file) at amartinetti at cloudflare.com?

> It’s okay if you only see it for two seconds. But the page stays on screen for over a minute.

That doesn't sound right. You shouldn't see a loading page for over a minute. If you're open to providing more details privately I'd love to help troubleshoot. You can drop me an email at amartinetti @ cloudflare.

This fix is now live to all Cloudflare locations.

We are beginning to roll out a fix now to a small portion of traffic. I will update when the fix is 100% applied for all Cloudflare traffic.

No apologies necessary! It did not, and I appreciate you bringing it up.

I'm a product manager at Cloudflare. Thanks very much for posting this here.

This looks like a bug with our "Managed Challenge" security action that's causing the loop. This feature attempts to determine browser versus non-browser traffic and block non-browsers. The fact that the challenge is currently not working for Waterfox Classic and Pale Moon is not by intent, and we do not want to be in the business of saying one browser is more legitimate than another.

I see that the name of our Browser Integrity Check feature (which is not causing the block here) is drawing some attention. This is a feature that blocks malformed HTTP request headers, and user-agents commonly used by abusive bots (like user-agents with Java and Python in them). This is a pretty simple set of rules that also does not attempt to differentiate between browsers. Here's our KB article on the feature: https://support.cloudflare.com/hc/en-us/articles/200170086-U...

I'm sorry that this has caused a serious issue for quite a large number of users, and that we were not more reachable in our community forum. I'll provide a follow-up here when we have an update on the bug. Thank you again for taking the time to write this up!