Forum:Switch to using QuestyCaptcha network-wide

From Meta Wiki
Jump to navigation Jump to search
Forums: Index > Switch to using QuestyCaptcha network-wide
Archive
This page or section is an archive.
Please do not edit the contents of this page.
This thread was archived on 28 August 2019 by Cqm.

With more and more spam accounts - perhaps even crowdworkers - signing up on our network, I'd like to open up a dialogue about using QuestyCaptcha on the wiki. It would allow us to present a custom question (out of a selection) to a user when signing up that they'd need to answer, instead of a simple captcha. We could also use different questions per wiki. As an example, we could have one of the following questions appear on signups to the RuneScape Wiki:

  • Who develops RuneScape?
  • Where is the Grand Exchange located?
  • Which skill lets you brew potions?

This will make it slightly harder for spam accounts, especially the people who are humans and carrying out the spam, to sign up to the wiki, because they'd require at least some basic level of RuneScape knowledge. On other wikis, we could have a generic set of basic level general knowledge questions (preferably ones not used elsewhere).

We could have a pool of questions available at a time, but I'd recommend using 1-2 different questions and changing them if it seems that they have become ineffective at blocking spam bots. As a note, we currently use Google ReCaptcha, but it does not seem to be helping to stop much spam.

Pros

  • Harder to crack for spam users than a simple captcha
  • More reliable than Google ReCaptcha - there has been some users who have had spam even while using Google ReCaptcha
  • No reliance on a third party API (Google ReCaptcha, obviously, calls home to Google's servers)
  • The current implementation of Google ReCaptcha may not work correctly, if at all, with VisualEditor

Cons

  • Might be slightly inconvenient to some legitimate sign-ups
  • Questions would have to be unique in order to not be cracked easily ("What's 5+5?" isn't going to work)
  • Questions need to be changed if they become ineffective

I have mentioned this before in which Cook said "Not crazy about the idea, I don't think the spam is really an epidemic issue and I feel like it would reduce our sign up rate by a non trivial amount". I would probably disagree with that, especially if the questions were simple enough that a user actually wanting to sign up to our wikis can do so, but anyone who may be creating an account to spam would struggle. This is why I've created this discussion to gauge the thoughts of others.

If you look at our sign-ups on https://runescape.wiki/w/Special:Log/newusers, you can quite clearly see we are getting a ton of spam accounts every day, and we need to take more effective approaches to deal with it. Yugipedia use QuestyCaptcha with some Yu-Gi-Oh! themed questions, and according to them (I spoke to one of their team on Discord), the only spam sign-ups they're aware of happened before implementing it.

I think we should put some serious consideration into using this, or at least testing it on one or more of our wikis for a duration. Spam accounts are a pain in the ass, and while people will always find a way to create spam accounts and edit, this seems like a straight-forward solution to potentially reducing the amount of spam we're getting by a ton, which we could implement in the space of a few minutes.

Discussion

Support - Template:Signatures/JaydenKieran 13:44, 13 June 2019 (UTC)

Support - Something tells me those people can get over the minor inconvenience. EDIT: Support questions that are easily found on the specific wikis, but probably no simpler than "What game is this wiki for?" Badassiel (talk) 13:48, 13 June 2019 (UTC)

Support QuestyCaptcha, oppose asking RS questions only - I'd rather not limit account creation to RuneScape players only, we should allow any human to create an account. There's more to having an account than editing RuneScape content. Haidro (talk) 13:57, 13 June 2019 (UTC)

Support - Makes sense. // Salix // Talk-to Salix // 14:55, 13 June 2019 (UTC)

Oppose - Is there not an issue with getting and keeping editors as is? I don't think making sign-up more difficult (even mildly so) is the right move. The issue isn't with spambots creating accounts, I don't think they violate any rules by just signing up, the issue is that they post content which isn't relevant or allowed. Thankfully they all follow the exact same pattern and post said content to the same place, their Userpage. I would prefer limitations on editing your own Userpage over limitations on signing up, it's lower in the heirarchy of things and less uninclusive. RS/Wiki/General Questions as a preventative measure for spam I can get behind but not to joining the website when spam is localised to one specific location that can be limited in both the same or other ways instead. MitcheII (talk) 15:49, 13 June 2019 (UTC)

When you say "I would prefer limitations on editing your own Userpage over limitations on signing up", we already do this. We have an abuse filter which tries to block new users who spam. It works for some of them, but not all. It's clear that just trying to tackle the edits themselves isn't working and we need to think more about how easy it is for a spammer to sign-up to the wiki. If it was as easy as "lol put some limitations on people editing their user pages" then we'd have done it already. Template:Signatures/JaydenKieran 16:01, 13 June 2019 (UTC)
I don't at all mean to make light of the difficulty/effort put into preventing spam, I appologise for coming off that way. I'm not sure how feasible the idea is but why not have these Questions as a limitation to editing userpages where all the spam is localised? It's the same effect of making it more difficult for spam bots but a potentially non-significant portion of genuine editors don't get caught in the crossfire? MitcheII (talk) 16:10, 13 June 2019 (UTC)
Not a pro on spam prevention but my interpretation and issue with that: it almost sounds like having someone answering a question to confirm edits to a userpage? Some editors (myself included) use the userspace to solidify edits before porting them over to mainspace. What would be in place to make that less annoying, assuming I understood what you're suggesting correctly? Badassiel (talk) 16:15, 13 June 2019 (UTC)
I mean I haven't really thought much about how to go about it, more that the limitation is better suited to the specific location where Spam is an issue. I'd imagine that you'd only get asked questions if it's your first edit on the Wiki as a whole and you're trying to edit your Userspace, so as to be as unobtrusive as possible for everyone and specifically targetting Spam. Screw having to do a captcha/question for every userspace edit lmao MitcheII (talk) 16:22, 13 June 2019 (UTC)
The extension we use (ConfirmEdit) allows enabling a captcha when editing any page, unless the user has the "bypass" right. This probably isn't ideal, as it would trigger on every edit for every user without that right. Requiring completion of the captcha on sign-up makes more sense, and is what we do currently with Google ReCaptcha too Template:Signatures/JaydenKieran 16:25, 13 June 2019 (UTC)
From what I can tell, that extension is perfectly suited to this? $wgCaptchaTriggersOnNamespace can be used to specify exactly which namespaces Captcha should appear on, in this case Userpages. With a psuedogroup between New User and Autoconfirmed user with the requirement instead being a single edit, $wgGroupPermissions['New-ish User']['skipcaptcha'] = True; would then only affect New Users wishing to Edit their Userpage as their first and only Edit. MitcheII (talk) 16:47, 13 June 2019 (UTC)
Still seems easy to get around. An extra step, sure, but once that's been done you're free to spam. Badassiel (talk) 16:59, 13 June 2019 (UTC)
I'm not sure I understand, it's the exact same as having a captcha on sign-up in terms of how difficult/easy it is for spambots to get around though? The plugin Jayden mentioned specifically talks about using QuestyCaptcha. What I mentioned would just change where the questions get asked? MitcheII (talk) 17:03, 13 June 2019 (UTC)

Oppose - Fix ur ab00se filter lol (in all seriousness, per MitcheII) InvalidCards (talk) 16:00, 13 June 2019 (UTC)

Support, at least as a trial - Do a trial run for a week or two, look at the data, and decide from there. -Towelcat (talk) 16:01, 13 June 2019 (UTC)

Support - I think this is a good solution. Possibly we could pool questions privately from admins for each wiki. Keep in mind that pt-br would need their questions translated. -dDbvitC.pngScuzzy Metahib8CAd.png 16:06, 13 June 2019 (UTC)

Comment - I have concerns about the questions/answers being proposed here. Will the answers be case insensitive, allow common misspellings, etc? Many of us have seen what SearchDigest output before it was killed off, and that's just for searching. I dislike increasing the barrier for legitimate new user signups, so if this does get implemented it needs to be monitored closely to ensure we aren't seeing lots of false positives. Is it possible to do a phased rollout to A/B test the impact? cqm talk 16:19, 13 June 2019 (UTC)

I answered a question similar to this on Discord, but answers are case insensitive and multiple answers can be provided for a single question. An A/B test was a suggestion from the Yugipedia guys too, but we probably don't have a simple way to do that other than to run it on one wiki for a period of time (e.g RSW only) rather than enable it on all. Template:Signatures/JaydenKieran 16:21, 13 June 2019 (UTC)
Multiple answers is a benefit, but these questions need to have unambiguous, easy-to-spell answers and ideally span multiple languages seeing as a German, French, Dutch, etc. player could be trying to sign up (not forgetting we have pt-br wiki to think about). Do you think this is able to provide that? cqm talk 17:18, 13 June 2019 (UTC)
Yeah, I don't disagree with using questions that have unambiguous answers. I'm not even suggesting that we have individual captcha questions for each wiki (that's just something we could do). We could have a list of a few easy "general knowledge" questions that are preferably unique to our wiki network/site(s). Localised questions per wiki (such as questions written in Portuguese on the pt-br wiki) would be simple enough as it is just a conditional change to our MW config. Template:Signatures/JaydenKieran 17:24, 13 June 2019 (UTC)

Oppose, fix it at the point of attack - I don't think this is a good solution at all to the spam problem, and will reduce signup rates.

I actually don't think we have a serious problem right now -- since we made the AbuseFilter more robust at the end of March, we've manually blocked 70 spammers between the two wikis. It's not unreasonable to say that we've spent more time discussing this proposal than we have actually dealing with spam. In that same time period, we've had about 4000 account registrations. I don't think inconveniencing 50-70 people for every 1 spammer we need to take 30 seconds to block is worthwhile, and that's assuming 1) spammers can't solve a game-specific captcha, 2) most/all legitimate players can. I think both of those are dubious assumptions.

I looked into the data behind the spam and found about 1100 examples. About 82% of the spam was in userspace, 100% of it contained an external link, and about 99.8% of it involved creating a new page rather than editing an existing one.

What we really need to do is crack down on the actual methods these spammers are using to create pages. The most obvious thing is to prevent non-whitelisted external links on new pages from accounts that meet certain requirements (I'd suggest >0 edits), and perhaps we could be even more strict in userspace. I looked through the last 3 months of recentchanges on both wikis and found exactly zero false positives. Based on the available information, this would catch about 99.5% of all the spam with no negative consequences (other than an ugly newusers log, which I assume would decrease when none of the edits came through). Why have we not done this? Why are we matching on such a specific format in the global filter?

In general I agree with Mitchell that we should move away from having captchas and checks at the point of origin (account creation), and move towards having checks at the point of attack (page editing). Once we strengthen our filters, I think we should strongly consider eliminating the captcha entirely, as it clearly doesn't work against the spammers, and is just an annoyance for legitimate users (and will get even worse if/when we start relying on account logins for wiki/game integration). ʞooɔ 09:17, 14 June 2019 (UTC)

Comment - oppose for now. If it may be possible to fix this by further refining abuse filters then I'd rather try that before introducing more obstacles for account creation. I do find this problem a real nuisance personally, due to the spam in recent changes and editors' time being wasted in dealing with the spam accounts, so if the abuse filter changes are not successful in preventing the spam and the accounts being created for that purpose then I think we should come back to this discussion in future. IsobelJ (talk) 15:52, 15 June 2019 (UTC)

Oppose — I believe abuse filters would do a much better job at eliminating spam without hindering legitimate users. --laagone talk 16:03, 15 June 2019 (UTC)

Oppose - at least, whilst there are alternatives (as per Mitchell and Cook) - Rawny (talk) 15:36, 16 June 2019 (UTC)

Oppose - Improving our abuse filters is the way to go rather than inconveniencing users, per Cook. Additionally, anything that involves text input from the user, like QuestyCaptcha, with something not trivially defeated by spammers, is just going to frustrate users trying to match exactly what the question expects, especially when trying to attract editors who might not have (British) English as their first language, or be new to the game or wiki. - TehKittyCatTalk Wikian-Book 15:55, 16 June 2019 (UTC)

Oppose - per cook STAR the coolest bean (talk 2 me xoxo) 21:18, 17 June 2019 (UTC)

Closed - There is no support for QuestyCaptcha at this time. cqm talk 23:43, 28 August 2019 (UTC)