Comments URL: https://news.ycombinator.com/item?id=45735597

Points: 13

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=44270624

Points: 28

# Comments: 4

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.

Comments URL: https://news.ycombinator.com/item?id=36230910

Points: 16

# Comments: 2

(disclosure: 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.

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.

Comments URL: https://news.ycombinator.com/item?id=31073953

Points: 8

# Comments: 0

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)

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)

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)

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

(disclosure: work there)

(disclosure: work there)

Comments URL: https://news.ycombinator.com/item?id=29544450

Points: 3

# Comments: 0

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)

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)