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)

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.