Requests for Comment/Replace reCAPTCHA with another CAPTCHA 2

Hi everyone from miraheze. I am isutan. Since Google no longer provides services in mainland China, a large number of Chinese users cannot register accounts and can only register through vpn or request others to register, so I hope that the captcha can be replaced.

Isutan (talk) 01:20, 20 May 2022 (UTC) .Isutan (talk) 23:58, 21 May 2022 (UTC)

Proposal 1: QuestyCaptcha
I think this kind of captcha works very well, especially for some games and anime wikis. I wish this could be in the other column of Managewiki and let the bureaucracy edit Isutan (talk) 01:20, 20 May 2022 (UTC)

Support

 * 1)  Isutan (talk) 23:58, 21 May 2022 (UTC)
 * 2) Neither of the opposes have anything to do with this proposal. One is claiming it is out of scope, the other is claiming that reCAPTCHA is fine and has no problems. Apart from this being false, it also doesn't address the proposal which is QuestyCaptcha. I reviewed QuestyCaptcha before here and liked it. Apart from the problem that reCAPTCHA being removed is a seperate issue to finding a replacement (hosting mandatory nonfree JavaScript is not an option), it would also likely be better at preventing spam. This is in combination with the IP blacklist. Naleksuh (talk) 17:01, 26 May 2022 (UTC)
 * 3)  Current issues with Google's reCaptcha is quite a lot. Does anyone forget the PRISM programme? Your data is not only seen by Google for tracking purposes, but also the US or the UK government. Another problem with it is JavaScript dependence, which is the main tracking method used by tons of google services like googletagmanager, google analytics. Because of this, there is a number of users who choose to disable JavaScript in the browser, and what reCaptcha do is to force them to enable it, tracking them over the web and left no options to opt out it. --Matttest (talk) 23:45, 26 May 2022 (UTC)
 * &mdash; QuestyCaptcha is more effective than the hCAPTCHA because QuestyCaptcha makes users type their answer to a question in an answer box. And the site owner can add the questions (and their answers) in LocalSettings.php, and the extension picks from them randomly. Usarneme (talk) 15:42, 2 June 2022 (UTC)
 * Moved to comments section as voting is not allowed if the account was created after the RfC was initiated Reception123 (talk) ( C ) 19:18, 2 June 2022 (UTC)
 * Restored to original position, note that users who cannot !vote can still participate in discussion, and there is no consensus to allow moving around people's comments to different sections. Naleksuh (talk) 22:03, 2 June 2022 (UTC)
 * Re-striked per policy allowing Meta sysops to make corrections in technical nature. If this is unstriked, this could cause confusion with voters. Agent Isai  Talk to me! 03:37, 3 June 2022 (UTC)
 * Stewards shouldn't have to individually check each user for whether they were created before the RfC was initiated. Having the support vote in the same section is confusing and the fact that the word 'support' is strike is not enough in my opinion. Reception123 (talk) ( C ) 11:54, 3 June 2022 (UTC)
 * 1) 城市酸儒文人挖坑 (talk) 08:43, 3 June 2022 (UTC)
 * 2) Do think about the other side, don't say "reCAPTCHA has no problem for me".Zes M Young (talk) 09:14, 5 June 2022 (UTC)

Oppose

 * 1)  This is highly out of scope, and nothing good can come out of an out-of-scope RfC. --DarkMatterMan4500 (talk) (contribs) 01:35, 20 May 2022 (UTC)
 * Except discussion, a founding principle of RfCs. That doesn't preclude its closure shortly, but I think it's worth mentioning and clarifying, especially given the direction in the comments. --Raidarr (talk) 11:19, 20 May 2022 (UTC)
 * The comments I made last night was mainly from my frustration I had with another user yesterday, so it might make sense why I wrote it like this. --DarkMatterMan4500 (talk) (contribs) 11:24, 20 May 2022 (UTC)
 * 1) The current system works well and does the job. While yes, this is a good-faith request, this is what helps us with spambots, and until SRE finds a better, working solution, and unanimously approves the new Captcha, this will stay. -- Cheers, Justin Aves (talk • contribs • global • rights) 23:13, 20 May 2022 (UTC)
 * First of all, several better solutions have already been provided, including new CAPTCHAs and a full import of Wikimedia proxy blacklists.
 * Secondly, the idea there needs to be a better replacement or even any replacement to remove reCAPTCHA is a problem. Having reCAPTCHA, at all, is a principle issue and must be removed. If a new CAPTCHA can be found, great, but otherwise that would simply mean no CAPTCHA. MediaWiki has a commitment to unobtrusive JavaScript, which this is not by any means. I also see no reason to be shuttling off background requests to Google servers on the signup page.
 * Also, do you have any problem with QuestyCaptcha or is this just "if it ain't broke don't fix it"? Do you care to actually discuss the proposal? Infact, QuestyCaptcha may actually be more effective at preventing spam than reCAPTCHA, due to the complete elimination of non-targetted bots, although the questions can be cracked. ReCAPTCHA, on the other hand, can be bypassed for less than a cent. Naleksuh (talk) 17:01, 26 May 2022 (UTC)
 * 1)  per above. I've never had any issues with recaptcha. Also the other captchas have proved to not quite so effective. I'd rather not force are stewards and global sysops to spend more time banning and locking spam accounts and IPs. MacFan4000 (Talk Contribs) 18:06, 26 May 2022 (UTC)
 * 2)  Per the reasons given here, I don't think this would be a good option. Reception123 (talk) ( C ) 18:24, 26 May 2022 (UTC)
 * 3)  Per whats already been said above. Universal Omega (talk) 04:54, 2 June 2022 (UTC)
 * 4)  I do not feel comfortable with QuestyCaptcha replacing ReCAPTCHA at all. The question can be easily cracked if a human so much as looks at the question for 5 seconds and solves it. Having someone constantly think of a new question and change it once it's cracked is extremely burdensome for our already overworked team. Additionally, it seems you cannot set a language-specific question so if we do implement this, we're going to be serving our Spanish, French, Italian, Portuguese, Chinese, Japanese and other language speakers an English question which will cause a severe headache and will cause more issues than what we're trying to solve. Even if it did support changing questions depending on the language, it would be an extreme burden having our system administrators update the question in all the languages should the question be cracked. The weaknesses portion of the QuestyCaptcha section also does not instill any sort of trust and instead instills distrust in the ability of the extension to effectively protect us against spambots. For these reasons, I must oppose strongly.  Agent Isai  Talk to me! 17:17, 5 June 2022 (UTC)

Proposal 2: hCaptcha
Unlike mathematical verification code, which is extremely easy to be cracked by spambot, hCaptcha is suitable for any wiki, and is very similar to recaptcha, which is a click-and-click image type. I think this is very suitable, shoutwiki uses this kind of captcha Isutan (talk) 01:20, 20 May 2022 (UTC)

Support

 * 1)  as proposer. Isutan (talk) 01:20, 20 May 2022 (UTC)

Abstain

 * I don't particularly have any issues with hCaptcha. If we did want to replace reCaptcha for some reason this would be my preferred option. However, I think reCaptcha is working fine at the moment other than the mainland China issue for which there is currently a Phabricator task which I will be working on resolving soon. Reception123 (talk) ( C ) 18:27, 26 May 2022 (UTC)

Oppose

 * 1)  Are you actually serious? We already had something like this back in October, and it fell flat on its face, especially since the nominator was an IP who was behind multiple abusive accounts at the time. This could only end badly. --DarkMatterMan4500 (talk) (contribs) 01:31, 20 May 2022 (UTC)
 * DarkMatterMan4500 Sorry, I don’t know that… Isutan (talk) 02:04, 20 May 2022 (UTC)
 * That's fine. :) --DarkMatterMan4500 (talk) (contribs) 02:46, 20 May 2022 (UTC)
 * 1) As per my statement in Proposal 1. -- Cheers, Justin Aves (talk • contribs • global • rights) 23:13, 20 May 2022 (UTC)
 * 2) hCaptcha is nothing different from reCaptcha, it is still surveillance-funded and requires JavaScript.--Matttest (talk) 03:20, 21 May 2022 (UTC)
 * 3) hCaptcha has many of the same problems that reCAPTCHA does. It breaks the unobtrusive JavaScript committment, it breaks the free software committment, it has a dependency on an external server, . In fact it's almost an identical clone. The ONLY advantage is the lack of involvement with Google. I don't see a reason to change to something that still has most of the problems, so it would just have to be changed again. Naleksuh (talk) 17:01, 26 May 2022 (UTC)
 * 4)  per above. MacFan4000 (Talk Contribs) 18:06, 26 May 2022 (UTC)
 * 5)  Per what's already been said above, but I still don't see it as a horrible option either. Universal Omega (talk) 04:57, 2 June 2022 (UTC)

Comments

 * 1) Procedurally speaking, this is out of scope for a Request for Comment so this request may be closed as invalid. However, SRE (the technical team) will gladly consider an alternative for ReCAPTCHA if needed. I will forward this to my colleagues at SRE to see what we can do as this is a perennial request.  Agent Isai  Talk to me! 01:28, 20 May 2022 (UTC)
 * But if you don't switch, it will block the registration of users in mainland China and make them suffer the same NOP dilemma as Wikimedia. But miraheze has not been blocked by GFW, why is it so complicated to do things that can be done by simply switching the verification code? If it is not resolved, miraheze's mail may be full, and there will always be such users in mainland China who want to contribute to wikis cannot register, which directly blocks more than 100 million netizens who want to have their own wiki or contribute to wiki. Isutan (talk) 02:14, 20 May 2022 (UTC)
 * Please remember that sometimes it's not that we don't want to, it's that we can't. We cannot simply flick a magic wand and move to hCaptcha, that is simply not possible. Our implementation of ReCAPTCHA is in-house and was developed by our own system administrators. What this proposal would do is require them to invest time to investigate hCAPTCHA and code something new so that'll take time. I'm sorry if you have issues but do note that the issue is simply bigger than just plain refusal because we don't feel like it. Agent Isai  Talk to me! 02:29, 20 May 2022 (UTC)
 * For once, Agent Isai has a valid reason and/or point on this one., as much as we want to make some supplementary changes in the system, it won't magically happen in a finger-snap. That would make the system feel rushed, and monetary damages might likely occur. Hope that clarifies things a bit. :) --DarkMatterMan4500 (talk) (contribs) 02:38, 20 May 2022 (UTC)
 * "For once"? DarkMatterMan, this has been the root of the problem since the inquiry first came up and repeated for a while. It also has little to do with 'monetary damages'. It's simply difficult at best for SRE to put on top priority while they're beta testing a full platform version upgrade and a long backlog wishlist. I'm not closing this because I believe in having the conversation and RfC is certainly a way to do it - however I'm under no illusions this RfC can or will have any real impact as it cannot mandate that SRE act in a particular way, nor will it change the realities that have been the case for some time. --Raidarr (talk) 11:20, 20 May 2022 (UTC)
 * True, but about the part where I said "for once", I talked with Agent on Discord, and I explained a bit more about it. I apologize if what I said makes no sense to you. --DarkMatterMan4500 (talk) (contribs) 11:23, 20 May 2022 (UTC)
 * 1) Procedural Correction regarding Agent Isai's procedural comment above: It is not out of scope for the community to discuss potential alternatives to the current CAPTCHA registration verification system. If consensus of the community was to switch to a CAPTCHA system does not meet the SRE, Trust and Safety, or even the Counter Vandalism Team's requirements, the respective teams retain the right not to implement the requested system. As it stands, I can see at least one CAPTCHA system that should meet with at least the CVT team's requirements and very likely the SRE and Trust and Safety team's approval. Overly simplistic CAPTCHAs, though, are unlikely to meet those requirements. It would have to be a system on par with reCAPTCHA. Dmehus (talk) 22:50, 21 May 2022 (UTC)
 * Would it be possible for you to direct me to where I said that it is out of scope to have a discussion? My point was that an RfC cannot serve as a binding vote in technical matters as it can in community matters. Either way, this has been communicated within SRE and an alternative for Chinese users is being considered being that this is a perennial request with a resolution hopefully coming soon. Agent Isai  Talk to me! 23:10, 21 May 2022 (UTC)
 * Where you said "Procedurally speaking, this is out of scope for a Request for Comment so this request may be closed as invalid" suggests you believe that this is out of scope as an RfC. An RfC is never binding upon SRE, Trust and Safety, or even Stewards, for that matter. If there are not legal, technical, or global policy conflicts, and the RfC was clear and unambiguous in its request, then it would be difficult to justify not implementing the results of an RfC, but if your latter reply is what you intended to say with the above comment, then that's fine as you're essentially suggesting the same thing. hCaptcha does seem to be one CAPTCHA alternative that SRE would support implementing, and, given the current issues with reCAPTCHA, I doubt there would be much, if any, objections from the community toward implementing, so could probably be posted as a Request for Feedback at community noticeboard that invites the community to express objections toward implementing it, as and when SRE is in a position to technically implement it. If there were more than one valid objection for different reasons, then I would personally recommend that SRE proceed to an RfC prior to implementing. Dmehus (talk) 23:27, 21 May 2022 (UTC)
 * I just want mainland Chinese users to get rid of recaptcha restrictions and register freely, please don't discuss irrelevant trivia about RfC restrictions and so onIsutan (talk) 00:02, 22 May 2022 (UTC)
 * 1) I have tested it several months ago and found that, the real reason is not recaptcha. Even if I use HeaderEditor or Gooreplacer to redirect google recaptcha to "recaptcha.net" (which is accessible in Chinese mainland), the connection fails as well. I haven't found the reason. Maybe further research is required. --SolidBlock (talk) 08:43, 22 May 2022 (UTC)
 * and I also found when researching several months ago that, the reason seems not to be with Google. "recaptcha.net" rather thant "google.com" is probably already used. One reason why it fails is, in Chinese mainland IPs, its API returns "gstatic.cn" instead of "gstatic.com". Both the gstatic domains are accessible in mainland of China, but "gstatic.cn" is not in Content Security Policy and is blocked by the client. I used to replace it with "gstatic.com" to solve the problem and succeeded. But later the method failed, even if it makes it possible to connecte the "gstatic" website. I have no idea of the reason. --SolidBlock (talk) 08:56, 22 May 2022 (UTC)
 * 1) Seeing all of the RfC, I hope both sides can stand in the other's shoes. This has been a problem for we Chinese netizens for long. Although switching a CAPTCHA may still have many problems we have now, it does  benefit users in China mainland a lot. After all, a little is better than none. So I hope someone, like SolidBlock, will help point out what the problem is exactly and how to fix it effectively. Zes M Young (talk) 12:59, 3 June 2022 (UTC)

Proposal 3: Actually block abusive IP ranges
As you may know, Miraheze uses a much more aggressive CAPTCHA, one that is easily bypassed with CAPTCHA farms and harm's users freedom, with little to no benefit, in an attempt to stop spamming, and while spamming does continue due to having wide-open editing for all with very little ranges blocked, the spam is much less present on Wikimedia. I spoke with a Wikimedia sysadmin about it and they said this was primarily due to spam ranges being blocked. In fact, they are simply using the standard math CAPTCHA there, and that combined with this is enough to keep out way more bots than reCAPTCHA can do. Naleksuh (talk) 17:01, 26 May 2022 (UTC)
 * The primary reason I've received for why this is simply not feasible is because a raw list of Wikipedia blocks cannot be accurately split off from blocks made for other reasons (general abuse and so forth). If this is resolved (and I'm not the authority on it anyway, only bringing it out to be discussed), I imagine simply importing a spam/vpn list and going with a 'dumber' captcha would be more viable. --Raidarr (talk) 17:40, 26 May 2022 (UTC)
 * It already was resolved. I gave Reception123 a full list of proxies and they ignored it. Naleksuh (talk) 17:42, 26 May 2022 (UTC)
 * That's not true, I absolutely did not ignore it. I simply indicated that as Global Sysop I didn't feel it was my place to take such matters into my own hands as that's clearly a task for Stewards to do in my view. I also replied in more detail and said that I didn't feel it was appropriate anyway to just import all of Wikipedia's IP blocks indiscriminately like that to Miraheze, since they would include non-proxy/VPN blocks. And even if they didn't include them, how could a Steward actually check whether that is the case? One can't be expected to simply block a list of IPs given by a user. Reception123 (talk) ( C ) 18:23, 26 May 2022 (UTC)
 * Haven't we always done this in the first place? --DarkMatterMan4500 (talk) (contribs) 18:25, 1 June 2022 (UTC)
 * Nope, most proxies that are blocked on Wikimedia are wide open on Miraheze, and this is why there is more spam here. Wikimedia doesn't have the problem and a sysadmin attributed that to the proxy blocks. Naleksuh (talk) 04:12, 2 June 2022 (UTC)
 * That could be a fair explanation but the solution to apply all Wikimedia blocks here doesn't seem to be a good one for the reasons I've given above. If we are to do something I'd rather prefer to try to bring back Proxybot. However, I'm not sure where the spam we're trying to go against is, because since we upgraded to ReCaptcha 3.0 the abuse filters for spam have been triggered very rarely. Reception123 (talk) ( C ) 12:13, 2 June 2022 (UTC)
 * The spam you're trying to go against would be the spam that is supposed to come back upon removal of reCAPTCHA (I'm not saying that removal of it would increase spam, but many people seem to be implying that not only does reCAPTCHA stop spam, but is necessary to stop spam). Your message, specifically the parts of the effects of spam prevention and no consideration on how different things would effect that, makes it clear you have no ethical problem with leaving reCAPTCHA in place indefinitely, despite the massive amount of accessibility technical and ethical issues with using reCAPTCHA. And no, you did not give a good reason as to why all proxy blocks should not be imported, you gave a reason as to why all blocks should not be imported ("some might not be proxies") and even after you were given a list of proxies only nothing was done with it. Naleksuh (talk) 12:52, 2 June 2022 (UTC)
 * Up until now, I still cannot see any convincing arguments against this proposal. I agree that the removal of reCaptcha will, indeed, increase spam here, but importing the list will solve it. Matttest (talk) 13:27, 2 June 2022 (UTC)
 * I haven't personally noticed any automated spam in quite awhile. I have always found reCaptcha (especially v3) to be fairly effective. v2 was not quite as effective in stopping account creations. MacFan4000 (Talk Contribs) 13:43, 2 June 2022 (UTC)
 * ReCaptcha is effective, but it do have problems stated above. 1) There are huge amounts of privacy concerns against google owned reCaptcha; 2) The MediaWiki software is designed to be able to use without JavaScript, see mw:No-JavaScript notes, and ReCaptcha violated the software design by forcing the use of JavaScript. So, reCaptcha do have problems, and thus the argument should be at whether QuestyCaptcha can be a good alternative. Following the discussions above, by combination of QuestyCaptcha and proxy block list, can replace the “efficiency” of reCaptcha. -Matttest (talk) 02:08, 3 June 2022 (UTC)
 * First regarding the importing of blocks, it seems that you haven't carefully read my response. The three main issues are: 1) doesn't the list you provided include all Wikipedia blocks (not only for VPN/proxy reasons)? 2) how could Stewards be able to independently verify that that list is actually accurate and there aren't some random IPs included in it? 3) Wikipedia sometimes does very large rangeblocks which end up affecting 'innocent' users (for example T-Mobile), why should Miraheze be forced to do the same and cause false positives? Regarding ReCaptcha, I understand you may have ethical problems with it but how do you explain the fact that the vast majority of users don't seem to have such issues? I presume if they did you would have more support here. The reality is that Google has ~4 billion users and in this day and age I think it's fair to say that it's very difficult to avoid Google in some areas. As I'm sure you know we've avoided using Google Analytics and instead use Matomo, however for ReCaptcha any of the alternatives that are given are unconvincing IMO and that's why I would disagree with changing it and think it is the best option currently. Reception123 (talk) ( C ) 14:10, 2 June 2022 (UTC)
 * 1) For the 934857394857394857394857394857394th time, no, it is only proxy blocks.
 * 2) If anyone has any doubts, they could check a sample of them, or re-generate the list (that list is >3 months old at this point, so it'd probably want to be re-generated anyway).
 * 3) I'm not sure I agree that T-Mobile is a false positive, given that mobile data can easily be abused. If there are false positives, they can be handled then like Wikimedia does or by tweaking blocks. Unless there is such a large amount of false positives that the negatives outweigh the positives, and I don't think that is the case. Naleksuh (talk) 22:03, 2 June 2022 (UTC)

(reset indent) For number 2, you would of course have to actually indicate how the list was generated. And given the fact that Wikipedia even has a special notice for T-Mobile users I think it's quite clear that there will be false positives there. Of course there will be abuse from some T-Mobile users but I wouldn't say it would be fair to block almost the entire network because of it. In any case, as I've said before this decision should be taken by Stewards so it would be best if they weighed in on this matter. Reception123 (talk) ( C ) 05:38, 3 June 2022 (UTC)
 * Procedural Comment: I've reopened this RfC following this request at stewards' noticeboard. Though this RfC was open for a long time and portions of it are vague or unclear, as I articulated, it's clear that reCAPTCHA is causing many issues for users, particularly in Asian countries, so it's an issue that needs to be resolved, and I believe there is consensus here that it's a problem. What's not clear, as I stated, is how to resolve this. Dmehus (talk) 01:10, 20 June 2022 (UTC)