A TextCha is a pure text CAPTCHA—and thus a case of a “logic puzzle”. Configuration: see HelpOnSpam
CAPTCHAs
A CAPTCHA is usually an image with some (more or less) hard to recognize content. A human should be able to recognize the content, a bot should not be. (CAPTCHA = Completely Automated Public Turing test to tell Computers and Humans Apart.)
CAPTCHAs have some problems:
- can be hard or impossible to recognize for vision impaired users
- some have audio for those cases (too bad if your sound card is currently not working or you dont have speakers connected or your hearing is also impaired)
- can be hard or impossible to recognize for not vision impaired people also
- some of them are already known-broken by the spammers
- needs additional code / libs for image processing or depends on external service
These were the main reasons we did not implement them yet.
TextChas
For moin 1.6 we implemented textchas because of those increasingly annoying spammers.
Features:
- for page save, ask a random question
- match the given answer against a regex
- q and a can be configured in the wiki config
- multilang support - a user gets a textcha in his language or in language_default or in English (depending on availability of questions)
- optional, default is no textchas at all
Tips:
- have 1 word / 1 number answers
- ask questions that normal users of your site are likely to be able to answer
- do not ask too hard questions
- do not ask "computable" questions, like "1+1" or "2*3"
- do not ask too common questions
- do not share your questions with other sites / copy questions from other sites (or spammers might try to adapt to this)
Discussion
Some remarks:
- Visual captchas are an accessibility problem for blind, acustical captchas for deaf, text captchas for the cognitive impaired people or people of a foreign language
I am not sure what new problem a text captcha creates for cognitive impaired people. If you have trouble understanding and answering a simple question, well, then you maybe have trouble doing any contributions to a wiki anyway.
- Foreign language people: same thing. If the wiki content is in English, then you should be able to answer a simple english question. And we even have language support in our textchas, so if you browser language is "de", you will get a german question/answer pair.
Solving Captchas makes working with a page more complicated from a usabilities point of view. SpamBayes, BlackList, Concept for Trusted Users are better in this case since they work in the background.
We have a blacklist (BadContent), but it is sometimes too slow for spammers using new throw-away domains every day.
- It is likely we have a bayes classifier in moin 1.7+ (SOC 2007 Project of Marian Neagul), but not in 1.6.
- We have a concept for trusted users (ACL groups), but that does not help if you want to run your wiki without requiring login.
- Text captchas need a big number of different but easy answerable questions in order to be safe.
- The dovecot wiki has only 1(!) question that is extremely simple to answer. They didn't have any spam in the last 3 months, as far as I could see.
- The questions are configurable, you can use any amount you like (even 0).
- How to prevent bots from collecting different questions and presenting them in a whole to a human, which solves them in less than an hour?
- You can not prevent that. But you can change your questions if you get spammed. And there is quite some chance this won't happen, because there are lots of easier targets that can be spammed fully automatically.
- How to prevent that inofficial text captcha crack lists are built and shared on the net?
- You can't prevent that either. But you can use site-specific questions, so they would have to do this for EVERY SITE they want to spam.
- Isn't cracking of a text captacha even more easy than a visual ones?
- Depends on who / what is doing the cracking. If you need site-specific knowledge, the questions could be made rather tough for outsiders, if needed, while still being easy to answer for some human that had a look at the site's content.
Keeping apart machines for humans (idea of Turing test) is maybe the wrong question. The right questions is: how to have only trustworthy user, i.e. how to identy thrustworthiness. Instead of implementing text captchas it would be better to implement things like this: FeatureRequests/MakeInvitations which help building a trusted social group.
- This is a complete different thing. You can use captchas, you can use ACLs and groups.
- Requiring a login just to fix some small typos won't work for some casual site visitor. I experience that myself any time I visited some twiki site (they require login by default).
BTW, we have spam bots creating accounts currently, thus getting into the "Known" ACL category. Some captcha maybe could stop this, too.
This all sounds very reasonable and since TextCha is only an optional feature (turned off by default), there shouldn't be any problems..
Questions:
Great Stuff!,many thx!! As far as I understand this TextCha it can be only activated or disabled. I not like that the TextCha shows up on every page edit. A TextCha for creating a new User Account would be, for my use, enough. So it is possible to define where the TextCha appears? -- MarcelHäfner 2007-11-06 11:47:55
- Well, I thought about that. Although it is no big problem, I didn't implement it yet, because:
- Spammers create(d) accounts, so they might have valid accounts from pre-textcha times. So just doing the textcha on account creation might not be enough.
- Many wikis allow anon users to edit, so just protecting account creation does not help for those.
- Just protecting page save and not account creation would be also bad because of spammer creating lots of fake accounts.
- Showing the textcha only to unknown users is also not enough because of that.
- I'll see, maybe I implement some textcha_show = ['user_create', 'page_save', 'attach_create', ...] list even if it won't make sense for everybody (but for some).
What about auto-disabling textchas for at least registered users after N questions and >M% correct?
Currently textchas_disabled_group = u'WhateverYouWantGroup' can be configured that way that everyone in this group can add others. I am not sure if everyone want's that page automaticly altered. For further discussions it would be anyway better to move your question to a feature requests page.
- Well, I thought about that. Although it is no big problem, I didn't implement it yet, because:
A word on wording: A CAPTCHA is not necessarily that pixel graphic thing, but is, by definition, a “turing test”. Also the so called TextCha uses the CAPTCHA method (= automatically tell computers and humans apart), but with an other technique as other CAPTCHA implementations (“logic puzzle” instead of a visual and/or aural verification).—It however still is a CAPTCHA. So I don't think there is a need to introduce a new term such as “TextCha” for something that already has a name. -- MartinBayer 2007-11-11 17:15:18
CAPTCHA == "Completely Automated Public Turing test to tell Computers and Humans Apart". Obviously TextCHA is not "completely automated" as you have to enter questions and answers manually into your config, while a real CAPTCHA is usually a random and automatically generated challenge. -- ThomasWaldmann 2007-11-11 20:58:22
Oh come on, I know what CAPTCHA means, I inserted the definition here. And even if that TextCha thing is not “completely automated” for the extend that new challenges can not be generated automatically, it still matches the principle of a CAPTCHA. You can even find an explanation of these pure-text question-answer things on Wikipedia's page CAPTCHA (together with explanations why they provide a false sense of security). However, I did not want to play hair-splitting with you, all I wanted is to note how clumsy I think this term “TextCha” sounds. -- MartinBayer 2007-11-11 22:18:26
No, you quoted parts of the definition of what a captcha is. Maybe just read the Wikipedia page you are quoting so we don't need to hair-split here. As I expressed above, I would like to use some easy expression not invented by me, but it should be a matching one. But "Logic Puzzle" for a simple question is IMHO not that great either. BTW, see here for CATcha.
-- ThomasWaldmann 2007-11-11 22:42:30
The current textcha is super annoying for the most important users - those who do most of the edits. The textcha should be used only for anonymous or new users. As a quick fix, I suggest to add a whitelist page of users that will not have to answer the textcha. We can use simple network of trust for that; a group page that only core team can edit. This comment was from NirSoffer.
I'm with Nir in this Point. At least this feature should be as configurable as possible (se above—use it only for account creation and so on). We want to support wiki admins in their fight against spam, but not impose them yet another anything-or-nothing decision. -- MartinBayer 2007-11-06 21:12:08
How about some "nocaptcha" ACL right. The wiki admin could assign it to some specific user(s) or group (GoodUser, GoodUsersGroup, Known, ...). It could be even assigned via a page ACL, if you don't want to ask for a textcha on some specific page. If a user has nocaptcha right, he does not have to answer captchas. -- ThomasWaldmann 2007-11-10 23:42:58
It could be solved internal that way but external (in the config file) I would prefer not to use acl_rights. Currently its quite easy to describe acls are used to control who has access on writing or reading ... of page content. While that kind of control is different. It is not based on the item or page content. In the config may be we could name it no_textcha_for=[SomeGroup,] and dont estrange the definition of ACLs. -- ReimarBauer 2007-11-11 11:01:59
I don't think using ACLs is far fetched. "write" tells "may write to the page/attachment", while "write,nocaptcha" would tell "may write to the page/attachment even without answering a captcha". We can also use "notextcha" to be more compliant with regard to consistent use of terms. Also, on does not usually need to give "nocaptcha" with on-page ACLs, it is rather something to be solved in acl_rights_before. -- ThomasWaldmann 2007-11-11 12:31:24
ACL is too low level and adding acl rights for any action is not a good idea. We need a simple and general solution to make the life of the main contributors easier. This means no textcha, no antispam or any other "protection" - because we trust these people. We use similar system on master and it works great. I would also not add another config option - just add a special hardcoded group name for trusted users. If users demand, it could be configurable in the future. The code to implement this is very simple - just check if the user is a member of that group - about 2 lines? -- NirSoffer 2007-11-12 19:40:21
Thats quite similiar to the direction I'd prefer to go and its simpler as my concept. I like it. -- ReimarBauer 2007-11-12 21:21:35
i would really appreciate if there would be a trusted user group where you can get promoted to. this would make 90% of the edits textcha free i guess. -- ThurnerRupert 2007-11-17 04:43:26
A name for such a page could be SpamEditsPreventByTextCha (or please add a better one). I think we should not use a name based on page_group_regex because one who has changed the regex may want it configurable. Currently I do think we should add it the way Nir describes it. There are more plugins which sometimes do want to be used only from a defined list of users or for pages. (That is related to the dependency concept of plugins too). Because if you work with several acl groups on a wiki (I have one currently with 30) you get easily into the situation to like to know who is in which group or which page is viewable by who. It can become not very easy to destinguish for what Group pages are used for. My feeling is currently we will have to think about how we want to have clear defined user groups used for acls. Thats why I do believe we go better with Nirs concept now. I like to have more time on the way to 1.7 to discuss a new name concept for acl groups. -- ReimarBauer 2007-11-17 08:27:38
As I didn't want to touch ACL stuff short before 1.6.0 release, I just added textchas_disabled_group = u'WhateverYouWantGroup' wiki config option. If you are a member of that group, you won't get textchas. -- ThomasWaldmann 2007-12-05 12:17:31
I just had a user lose data because they didn't know what the TextCHA was about, left it unanswered, and then were kicked out of the editor, with their changes gone. (hiding behind the browser's back button)
I'd like to suggest three changes:
- In the red Textcha box, explain what this is and what to do with it--don't just ask the question.
- In case of failure, go back to the editor instead of to the page.
- If the user doesn't pass the Textcha, verbosely explain what went wrong.
-- 72.221.120.106 2010-04-13 23:19:13
The following modification is discouraged. Spammers create accounts these days - and with a little human help they can spam forever after answering a single textcha. -- ThomasWaldmann 2009-03-17 20:35:11
In order to enable TexctCha only for unregistered users, I made a following hack in MoinMoin/security/textcha.py and it worked for my moin. FYI. -- HidekiShima 2024-11-21 10:22:09
if disabled_group and user.name and request.dicts.has_member(disabled_group, user.name):
(replace above with following)
if user.name:
- This can be implemented via custom groups backend without affecting main code. My approach was something like this (not sure whether it is correct in all situations as this hack was quick and dirty; add it to your wikiconfig.py):
1 from MoinMoin.datastruct import WikiGroups, CompositeGroups 2 from MoinMoin.datastruct.backends import BaseGroupsBackend, LazyGroup 3 from MoinMoin import user 4 5 class KnownGroup(LazyGroup): 6 def __init__(self, request, group_name, groups): 7 self.request = request 8 self.group_name = group_name 9 self.groups = groups 10 11 def __contains__(self, member): 12 return user.getUserId(self.request, member) 13 14 15 class KnownGroups(BaseGroupsBackend): 16 def __init__(self, request, group_name=u"Known"): 17 self.request = request 18 self.group_name = group_name 19 20 def __getitem__(self, group_name): 21 return KnownGroup(self.request, self.group_name, self) 22 23 def __contains__(self, group_name): 24 return group_name == self.group_name 25 26 def _group_has_member(self, group_name, member): 27 return (group_name == self.group_name) and (user.getUserId(self.request, member)) 28 29 ... 30 31 class Config(DefaultConfig): 32 ... 33 34 textchas_disabled_group = u"KnownGroup" 35 36 def groups(self, request): 37 return CompositeGroups(request, 38 KnownGroups(request, u"KnownGroup"), 39 WikiGroups(request)) 40 41 ....
btw, inability to use special group like Known and Trusted in textcha makes me sad panda. -- EugeneSyromyatnikov 2013-05-14 02:39:36