[WIP] MSC2745 : Add hCaptcha as captcha provider #2745
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,47 @@ | ||
| # MSC2733 : 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. | ||
|
|
||
| ## Context | ||
|
|
||
| Since Google is well known for misuse of their customers data and general disregard | ||
| for basic privacy rights it is desireable to distance the Matrix spec from such a company. | ||
| The ubiquitously used reCaptcha is one such mechanism to accumulate more private data for Google. | ||
|
|
||
| ## Proposal | ||
|
|
||
| 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. 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. |
||
|
|
||
| This move would have multiple benefits: | ||
| * Not relying on Google | ||
|
There was a problem hiding this comment. 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. |
||
| * 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. 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. Agreed. In fact, it can be a big drawback. |
||
| * Supports [Privacy Pass](https://privacypass.github.io/) | ||
|
|
||
| **All proposed changes listed chronologically:** | ||
| * 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. 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. |
||
|
|
||
| ## 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. We don't discuss implementation details in MSCs. |
||
| Also adoption and integration with clients like element.io and so on could become an issue and possibly cumbersome to maintain multiple captcha providers. | ||
|
|
||
| ## Alternatives | ||
|
|
||
| Some alternatives have been discussed in multiple Issues [1](https://github.com/vector-im/element-web/issues/3606) [2](https://github.com/matrix-org/matrix-doc/issues/1281). | ||
| There are generally two views regarding alternatives for reCaptcha. Design oriented and Security/Privacy oriented. | ||
| For Design, there are two notable mentions: | ||
| * [VisualCaptcha](https://visualcaptcha.net/) | ||
| * [MTCaptcha](https://www.mtcaptcha.com/) | ||
| Regarding security and privacy the by far best option is [hCaptcha](https://www.hcaptcha.com/) | ||
| Since hCaptcha is pretty simmilar to reCaptcha design wise, it would be the ideal replacement since the majority of users are already familiar with reCaptcha. | ||
|
|
||
| ## Security considerations | ||
|
|
||
| Arguably hCaptch isn't as bot proof as reCaptcha is, but to what degree is uncertain. | ||
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.