-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] MSC2745 : Add hCaptcha as captcha provider #2745
base: old_master
Are you sure you want to change the base?
Conversation
…ptcha-as-captcha-provider.md
…ptcha-as-captcha-provider.md
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see any actual proposed spec changes in here. Is this just a placeholder right now?
* dropping reCaptcha | ||
|
||
## Potential issues | ||
As a potential issue there would be the variables in homeserver.yaml, namely `recaptcha_public_key` `recaptcha_private_key` `recaptcha_siteverify_api` which would need to be renamed, which breaks config backwards compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't discuss implementation details in MSCs.
@reivilibre Thank you, changed the MSC ID |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH, so far this looks like a rallying call, rather than a technical proposal. Please see more specific comments below.
# MSC2745 : Add hCaptcha as captcha provider | ||
|
||
This MSC proposes to generalize the use of a captcha api in the matrix spec and that | ||
hCaptch is to be added to provide a more privacy focused alternative to reCaptcha. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hCaptch is to be added to provide a more privacy focused alternative to reCaptcha. | |
hCaptcha is to be added to provide a more privacy focused alternative to reCaptcha. |
as a captcha provider and also should be used as the default moving forward. | ||
|
||
This move would have multiple benefits: | ||
* Not relying on Google |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not clear why relying on Google is bad. Unless a homeserver owner is the author of their own captcha system, they will have to rely on some other captcha system provider, and Google is far from being the worst to rely on, if only in terms of robustness. If it's the point about privacy then it's already mentioned below.
* Not relying on Google | ||
* Protecting users privacy, see [here](https://www.hcaptcha.com/privacy) | ||
* The captchas are easier to solve and aren't confusing like reCaptcha sometimes can be (only from my own and anecdotal experiences) | ||
* Used by Cloudflare, see [here](https://blog.cloudflare.com/moving-from-recaptcha-to-hcaptcha/). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a benefit, it's rather a testimony. You can put it to the Context section.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. In fact, it can be a big drawback.
* implement needed changes for multiple captcha providers | ||
* implementing hCaptcha api calls | ||
* switching to hCaptcha as default captcha provider | ||
* dropping reCaptcha |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather split the topics of adding hCaptcha, using it as a default, and dropping reCaptcha - these are 3 different things with different implications. I personally think that only the first one has merit, for reasons below.
First, what you laid out here is a plan to switch captcha providers. Adding another captcha provider brings choice and more neutrality. Shifting from one captcha provider to another is not.
Then, the concept of a "default captcha" doesn't fit the Client-Server spec. The spec's "defaults" pertain to cases when certain piece of input to the API is omitted; not to the prepackaged software configuration. If there were an API that would trigger captcha, you could devise that a default value for a given parameter is "hCaptcha", rather than "ReCAPTCHA". There's no such API though. The way a user is authenticated is homeserver-specific, every owner sets it up to their circumstances. You can try to propose a default authentication mechanism involving hCaptcha to Synapse, probably.
|
||
The Matrix spec should not directly reference reCaptcha as the only captcha provider. | ||
The spec should be generalized to use multiple captcha API's. hCaptcha should be added first | ||
as a captcha provider and also should be used as the default moving forward. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good start but you have to proceed with more technical details on how exactly you want to introduce the change. Bear in mind that Matrix spec is a set of protocols, not the software that implements this set. Technical bits that you discuss in "Potential issues" are about Synapse (one of homeservers), not about the Matrix specification; instead, you should describe which pieces of the Client-Server specification and how you propose to change.
@turt2live there is an implementation at matrix-org/synapse#8797 |
It is worth to make it explicit whether a) hCaptcha is open source and b) can be self-hosted. |
Please feel free to correct any spelling errors. Discussion and improvements very much welcome.
Current discussion issue for context: matrix-org/matrix-spec#295