Requests for Comment/Replace reCAPTCHA with another CAPTCHA 2

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Proposal 1 and 2 do not have sufficient consensus for me to draw a conclusion that the community supports moving away from ReCAPTCHA to either of these types. Proposal 3 is a service request and does not propose any policy changes - further more there is no discussion on proposal 3 to draw out sufficient ways forward in terms of policy. Numerous users have stated their intention to start a Proxy blocking bot on Meta which could potentially apply globally - however approval for this would be in the relevant venues rather than through an RfC currently. John (talk) 17:52, 1 July 2022 (UTC)

---

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) @城市酸儒文人挖坑, SolidBlock, and Msnhinet8:.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.  Strong support 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.  Strong support 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)

    Support — 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)

    Note: 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)

4.  Support城市酸儒文人挖坑 (talk) 08:43, 3 June 2022 (UTC)
5.  SupportDo 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.  Strongest oppose 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)

   @Raidarr: 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)

2.  Oppose 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)

3.  Oppose 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)
4.  Oppose Per the reasons given here, I don't think this would be a good option. Reception123 (talk) (C) 18:24, 26 May 2022 (UTC)
5.  Oppose Per whats already been said above. Universal Omega (talk) 04:54, 2 June 2022 (UTC)
6.  Strong oppose 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)
7.  Oppose I did not initially intend to participate in this Request for Comment because it seemed repetitive and a reiteration of the previous RfC that did not succeed but given that it has attained some unexpected support and a reopening I have decided to share my view. First of all it is very disappointing that this request was not framed with two questions: 1) Do you want ReCaptcha to no longer be used? 2) What should its replacement be? Because it was not framed in this way the debate about whether ReCaptcha is an issue or not is minimised and the debate mainly concerns the new captcha's that are being proposed. For my part even if I understand and do not take for granted that Chinese users are affected by ReCaptcha I do not think it should be up to Miraheze to adapt and change because of the actions of non-democratic governments. I am certain that if the Chinese government was aware of what wikis existed on Miraheze the whole project would have been banned. Alternative solutions for users from China can be arranged such as requested registration. The reality is that most people use Google in their day-to-day lives and it is very hard to completely escape it so it is not fair to impose such a burden on Miraheze when >95% of Miraheze users are already likely using Google in their daily lives. Additionally I may be mistaken but I have not seen any concrete evidence from Naleksuh about any of the privacy concerns which means that we are expected to believe everything he says without evidence. Before the argument is made, since Naleksuh is proposing this changes it is up to him to furnish evidence not us to research it. In relation to QuestyCaptcha I have nothing to add beyond the arguments that have been made above most notably by Agent Isai. Finally I do not believe that the current set up of ReCaptcha is perfect but instead of insisting on a new and less sophisticated Captcha it would in my view be a preferable solution to try to improve the current setup of ReCaptcha. --DeeM28 (talk) 20:16, 20 June 2022 (UTC)

   I believe most of the users here know how to analyze documents on policies, so please check out google's privacy policy. They collect "basic stuff" like which language you speak, to more complex things like which ads you’ll find most useful, the people who matter most to you online, or which YouTube videos you might like and tie it with "unique identifiers tied to the browser, application, or device you’re using." They also store almost all your activities and left no way to opt out it. It is not a surprise that Google uses reCaptcha to monitor user's behaviour dur to the fact that they uses all google services, tying them together to do surveillance. The problem now is, whether QuestyCaptcha is good enough for replacement. And I believe it's yes when combining "proxy blocks" and "QuestyCaptcha". --Cheers, Matttest (talk | contribs) 23:43, 20 June 2022 (UTC)

8.  Strong oppose QuestyCaptcha, while not a complete joke like MathCaptcha, given that it protects very well against generic MediaWiki spambots, would become a joke the moment someone targets Miraheze in particular, as all they need to do is solve all the questions and load them into a bot. Furthermore, as mentioned above, we would need to have language-specific questions, which, even if supported, would be an excessive burden. — Chrs (talk) 21:10, 20 June 2022 (UTC)
9.  Strong oppose Per others’ comments in this RfC, I feel comfortable in opposing this request. While I appreciate the good-faith request for a new captcha, the tool has not been vetted by SRE for use on the service. As such, I’m opposing this. Thanks - BrandonWM (talk • contribs • global • rights) 19:20, 21 June 2022 (UTC)

Comments

1.  Weak support We should use simle questions in LocalSettings.php which bots have no idea of existing. Cigaryno (talk) 11:19, 20 June 2022 (UTC)

    Note: Moved to comments section as voting is not allowed if the account was created after the RfC was initiated. Reception123 (talk) (C) 19:41, 20 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.  Strong support as proposer. Isutan (talk) 01:20, 20 May 2022 (UTC)

Abstain

•  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.  Strong oppose 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)

   @Isutan: That's fine. :) --DarkMatterMan4500 (talk) (contribs) 02:46, 20 May 2022 (UTC)

2.  Oppose As per my statement in Proposal 1. -- Cheers, Justin Aves (talk • contribs • global • rights) 23:13, 20 May 2022 (UTC)
3.  Oppose hCaptcha is nothing different from reCaptcha, it is still surveillance-funded and requires JavaScript.--Matttest (talk) 03:20, 21 May 2022 (UTC)
4. 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)
5.  Oppose per above. MacFan4000 ^{(Talk Contribs)} 18:06, 26 May 2022 (UTC)
6.  Weak oppose 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)
7.  Weak oppose & Procedural I am opposing this proposal because of my comments in Proposal 1 and because I do not support removing ReCaptcha without sufficient positive evidence that it is harmful to privacy. If the RfC was structured in the way that I suggested in my commentary for Proposal 1 I would have weakly supported this as an alternative to ReCaptcha as it does not have the issues that QuestyCaptcha does but because the way it is structured makes a forced assumption that everyone wishes ReCaptcha to be replaced I cannot support this at all for procedural reasons.--DeeM28 (talk) 20:19, 20 June 2022 (UTC)
8.  Strong oppose Per my rationale in Proposal #1. Thanks - BrandonWM (talk • contribs • global • rights) 19:21, 21 June 2022 (UTC)

Comments

1. @Isutan: 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)

   @Agent Isai: 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)

   @Isutan: 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. Isutan, 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)

   @Raidarr: 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)

2. 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)

   @Agent Isai: 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)

   @Isutan: This 'irrelevant trivia' aside from being relevant to how this discussion is carried out, is happening in a sub-topic in the commentary section. You have neither the right nor any good reason to tell him to discuss otherwise when he has already been engaged in the main content of this proposal. You can otherwise ignore this tangent and offer something more substantial in the main content, which is struggling badly to offer anything that can be seriously executed. --Raidarr (talk) 13:13, 21 June 2022 (UTC)

3. 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)

4. 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)

@Naleksuh: 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)

 Comment: 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)

@MacFan4000: 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)

I would have to echo Reception123's comment here. T-Mobile global blocks would cause many users to not be able to create accounts. Sure, they may be able to go back home and use their home Internet service to create an account, but that's if they don't also have T-Mobile as their home Internet service. As well, since we're talking about spambots here, I will just say that I have seen very little, if any, evidence of spambots using T-Mobile networks. T-Mobile can tend to be used for user accounts policy abuse, sure, but that it is nowhere near the same level of being a problem as spambots. As such, I favour restricting wide T-Mobile rangeblocks where the problems are occurring, with short durations to them (they can be reblocked easily enough, should the problems persist when the blocks expire). As to a wholesale import of English Wikipedia open proxy blocks, while this would require tweaking of the block tables (to make them soft blocks, rather than hard blocks), I'm not sure this is the right approach. First, there's no evidence the same open proxies are being abused by spambots on English Wikipedia and Miraheze. While it's fine to block unused open proxies on Miraheze, of course, my concern is more to effectively blocking currently abused open proxies. While it's time-consuming, I don't believe there's a more effective substitute than monitoring the global abuse logs, as well as select local abuse logs where spambots tend to frequent and be most active and running CheckUser checks on the spambots, globally blocking the abuse open proxies/web hosts/colocation providers. Admittedly, I haven't done as much of that recently as I have in the past, but that is something I'm certainly willing to take on as I refocus my Steward activities and limited time. Dmehus (talk) 03:35, 21 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)

  I do not mean to cause offense to any users or get into detailed political disputes but I do not think it is necessary to in a sense use euphemisms and mention "Asian countries" when the issue seems to clearly be limited to China and the government there which engages in censorship. Chinese nationals are not to blame for the policies of their government but at the same time we cannot be expected to give in or placate the Chinese regime. --DeeM28 (talk) 20:22, 20 June 2022 (UTC)

  That's a fair point, and by referring to "Asian countries," it was not my intent to "sugar coat" the censorship and information control of the Chinese regime. You're quite right, it absolutely it is that. My point of referring to Asian countries was more of a broader term because I have seen users not just from China that have had issues with reCAPTCHA. I'm not sure what the cause is; whether it's telecom infrastructure related to using Internet backbone infrastructure owned by telecommunications companies from China, whether it's software related, or whether other regimes are engaging in similar Internet censorship that is causing the issue. Dmehus (talk) 03:20, 21 June 2022 (UTC)

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section