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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.