eatbots

Reported this exact bug to Zendesk, Apple, and Slack in June 2024, both through HackerOne and by escalating directly to engs or PMs at each company.

I doubt we were the first. That is presumably the reason they failed to pay out.

The real issue is that non-directory SSO options like Sign in with Apple (SIWA) have been incorrectly implemented almost everywhere, including by Slack and other large companies we alerted in June.

Non-directory SSO should not have equal trust vs. directory SSO. If you have a Google account and use Google SSO, Google can attest that you control that account. Same with Okta and Okta SSO.

SIWA, GitHub Auth, etc are not doing this. They rely on a weaker proof, usually just control of email at a single point in time.

SSO providers are not fungible, even if the email address is the same. You need to take this into account when designing your trust model. Most services do not.

If you report the website/sitekey to hCaptcha support it'll get banned pretty quickly.

hCaptcha tested popular detectors on confirmed LLM and human output. No public AI text detector scored better than random chance.

hCaptcha has completely passive score-only modes. When to challenge and how hard is up to the site.

This is entirely configurable by the site owner. hCaptcha has entirely passive score-based detection, 99.9% passive mode, and more aggressive options as needed.

(disclosure: work there)

No: enterprise customers like that pay hCaptcha. https://www.hcaptcha.com/enterprise

This is not what empirical measurements show. It is referring to a minimum internal benchmark, rather than what actually happens. (source: work there)

If you're getting shadow banned somewhere, it is typically either the site itself or their CDN or bot management providers that is sending you into a challenge loop; hCaptcha doesn't control the behavior in those scenarios.

Like any attestation scheme, it doesn't prove anything about the humanity of the button-presser, only that software, hardware, or flesh triggered an action in iOS.

hCaptcha's announcement goes into a bit more detail on the tradeoffs: https://www.hcaptcha.com/post/announcing-support-for-private...

The main benefit over traditional hardware attestation is that RSA blinding is used to avoid linkability to a single device.

Reducing challenges to real people is everyone's goal, including the goal of everyone working on modern CAPTCHA / bot mitigation platforms..

And no one will ever succeed at bringing them to zero.

Perennial favorite explainer on the topic: https://www.hcaptcha.com/post/why-captchas-will-be-with-us-a... Why CAPTCHAs Will Be With Us Always

(disclaimer: work on this stuff)

Vast majority of traffic from Tor IPs is abuse, which makes it challenging to deliver a good experience for the handful of normal users mixed in there.

You might be interested in one approach we've been working on for this: https://www.hcaptcha.com/privacy-pass

(full disclosure: work on hCaptcha)

hCaptcha really doesn't care who you are, and has no incentive to do so. Pretty different economic model than an ad seller like Google.

People who build their own generally end up switching to a service like hCaptcha once they start getting attacked. Not a simple problem, as any solution you put in place needs to constantly evolve if you are protecting anything of value.

(disclosure: work there)

hCaptcha is in fact tested this way, and has pretty consistent accuracy across hundreds of countries:

https://www.hcaptcha.com/post/do-captchas-really-discriminat...

(disclosure: work there)

Actually, no. hCaptcha has always been very privacy-focused, so in this case there are technical safeguards available: enterprise customers can pre-blind all data on their end, meaning hCaptcha gets no PII at all.

(disclosure: work there)

As a fan of ProtonMail, will just add a few points:

Every popular online service today is being continuously attacked. Bad actors get a lot of economic value from credential stuffing, account takeovers, and fake registrations, especially on email services.

This is why CAPTCHAs exist. They are one of the better tools in the defender's arsenal to increase the cost of attacks.

Building and maintaining a good CAPTCHA service is both hard and requires a high level of continuous development, since every day people are waking up and trying to figure out how to break it.

This means almost every company that tried building their own in the past has switched to either hCaptcha or Google, since it is not practical for even large companies to maintain their own solution these days.

Why was ProtonMail originally using Google? Probably because for many years it was the only plausible option until hCaptcha came around, and they needed to protect their users.

We're working with them now to switch over to the enterprise version of hCaptcha, which:

1) includes privacy-preserving features that let them decide exactly what user data hCaptcha sees and when, and 2) guarantees what happens to any data received via a data processing agreement, and 3) isn't run by an ad network.

hCaptcha doesn't care who you are and ensures all data is ephemeral, since unlike Google we're not trying to sell ads targeting you.

(disclosure: work there)

This is not actually true: every relevant aspect is different from a privacy perspective, both technical and legal.

Looking only at the technical differences, hCaptcha lets enterprise users like Proton locally scrub any info like IPs prior to sending to hCaptcha. It can be set up so that the user makes no direct connection at all to the service, and the code runs inside of a sandboxed IFRAME.

As for false positive vs false negative rates, not sure what you consider too high. We've been able to demonstrate FP rates under 0.005% when measured against known-good/bad signals from customers, which is as good as it gets.

(disclosure: work there)

Yep. https://www.hcaptcha.com/why-captchas-will-be-with-us-always

(disclosure: work there)

This is under the control of the site with hCaptcha, so you'll tend to see more variety in difficulty levels depending on their settings.

There will always be some individual variance, but when we've tested this people always solve hCaptcha faster than reCAPTCHA on average.

(disclosure: work there)

Our system is indeed designed not to leak detections in real-time. By contrast, with reCAPTCHA you can simply sign up and get a bot score, which makes it trivial to break.

This limits options for the free version they tested, as by design it will not completely prevent all detected automation from passing.

Instead, one of the tools it relies on is frequently changing the classes and types of challenges. However, it also has “anti-drain” protections to avoid leaking these.

Thus, our response to them after looking through the paper was that in fact the anti-drain protections were working as designed, based on the other details reported.

disclosure: work there.

This was an implementation issue that bit them briefly at launch, and is now resolved. hCaptcha is quite a big supporter of privacy, and has been coordinating closely with ECI.

(source: work on hCaptcha)

Works better at stopping bots, costs less than reCAPTCHA Enterprise since it doesn't need to store your browsing history for the last decade.

(disclosure: work there)

We'd be happy to help, just drop us a line.

The enterprise version is probably what you want: includes a "99.9% passive" mode where most people will never see a challenge unless they look like an attacker, meaning you can leave it on all the time rather than having to firefight.

(work for hCaptcha)

This would be a reCAPTCHA: there were no parking meter questions running on hCaptcha yesterday, from a quick check.

hCaptcha engineer here: this is an issue with Google's approach, not all visual challenges.

Our challenges have average solve accuracy within 1% when comparing users in major African countries vs US users in our user testing. Nigeria does slightly better than the US, in fact.

Please read the second line at the very top of that page:

"Not Applicable to Third Party Websites. Please note that this Privacy Policy does not apply to any website, offering, product or service of any third party, even if it links to our Site or incorporates the Service – please refer to the applicable privacy policies before deciding to provide any information to third parties."

End user data is governed by the Data Processing Agreement, linked here: https://www.hcaptcha.com/terms

Proof of work by itself is nearly useless, unfortunately. Compute is cheaper than people. This is one reason why CAPTCHA services will likely be with us always.

As someone working in the field, I also doubt your claim "will prevent 99.9% of spam" is based on real data. Modern headless browser spambots are not deterred by this kind of approach.

(Edit: looks like the poster admitted this number was entirely made up later in the thread.)

Using any kind of privacy/adblock extension that supports domain-level whitelisting (e.g. uBlock Origin) works fine, and this is what we suggest in the accessibility FAQ. Apple didn't build fine-grained controls into their browser before making this recent change, unfortunately.

That said, we're working with the browser makers on native support for our next gen privacy-preserving approach to this via Privacy Pass.

Compared to reCAPTCHA v3, our approach does not depend on tracking your visit history. (disclosure: work there.)

We actually spend quite a lot of time on this, and regularly work with blind users to test and improve these flows.

Most vision-impaired users have no issue in our testing, and it is a much more accessible option than audio challenges, which discriminate against those with auditory processing impairments.

(disclosure: work there.)

With hCaptcha (enterprise ver) this is entirely under the control of the customer.

We're not "remembering" in the same way, but have good enough instantaneous scoring to correctly guess whether or not a challenge is required most of the time.

Some customers may disable that option to meet their requirements. Not much we can do about that :)

hCaptcha is more focused on technical solutions to privacy that minimize required trust. A privacy policy is one thing, but a mathematical guarantee is quite another.

We are working through the IETF and directly with browser makers to support provably private options like Privacy Pass, and are currently the only CAPTCHA service to support this.

Similarly, on the enterprise side we offer various technical options to let our enterprise customers guarantee exactly what data we can and cannot see.

(disclaimer: work there, comments not official, etc.)