Last modified: 2013-08-13 17:48:53 UTC
It would be useful to have a way to get stats on how often users attempt to edit an article and give up after receiving a CAPTCHA. For this, the extension would have to provide a log of such edits (e.g. as in abuse filter, which allow us to see each filtered edit to check if it was a false positive, and maybe contact the user, or reinsert the valid content). This is even more important on wikis which are under the so called "emergency mode" (ptwiki and ptwikinews, at the moment), where the CAPTCHA is required on every edit by new and anon users (even if they do not add links). A workaround would be to implement the request from bug 18110 (allow AbuseFilter to force the user to solve a captcha).
["It would be useful" => severity=enhancement]
I don't think they need to be in "emergency mode". → Bug 41745
(In reply to comment #2) > I don't think they need to be in "emergency mode". → Bug 41745 I don't either, but there is no consensus about this on our community yet: https://pt.wikipedia.org/wiki/WP:Esplanada/propostas/Alterar_a_configura%C3%A7%C3%A3o_do_CAPTCHA_(26out2012)
Draft at gerrit change I5ad1f8d5.
Does it hide them by default from log view, like patrol and review?
(In reply to comment #5) > Does it hide them by default from log view, like patrol and review? I'm not sure (and I won't be able to install a copy of MW for a few weeks to test this again). Anyway, I agree it makes sense to hide them by default.
It looks like that patch leaks email recipients into the public log. Before publicly and permanently logging non-public events (badlogin, email, etc) the user should be warned that attempting and failing to solve the capatcha will result in a public log entry.
addurl, edit and create looks okay, because saving can already create a public entry in the history But the description of the log entry must have some extra information (at least for addurl). badlogin and sendemail are no public visible actions at the moment, so this should not go into a log. createaccount cannot use the account name, because when the user does not try again, another user will have that log entry. But the ip can leaks private data, so this is also a bad idea.
Helder, if you can respond to comment 7 and comment 8, that would help move this bug forward. Broadly, I'm not sure we want a public log of CAPTCHA hits. Bug 18110 may be a better avenue to pursue.
(In reply to comment #8) > addurl, edit and create looks okay, because saving can already create a > public > entry in the history But the description of the log entry must have some > extra > information (at least for addurl). > badlogin and sendemail are no public visible actions at the moment, so this > should not go into a log. > createaccount cannot use the account name, because when the user does not try > again, another user will have that log entry. But the ip can leaks private > data, so this is also a bad idea. I assume we should add only the addurl, edit and create logs then. For the other actions, maybe the warning suggested on comment 7 is enough, or the log could be restricted to users with a given permission. (In reply to comment #9) > Broadly, I'm not sure we want a public log of CAPTCHA hits. Bug 18110 may be > a better avenue to pursue. As long as we get *some* way to get data like "X of the Y users which attempted to edit Wikipedia give up after CAPTCHA". Bug 18110 would have the advantage of allowing us to see the text the user was trying to add before the CAPTCHA appeared...
I like the idea of resolving Bug 18110 as a solution here.
It's not clear to me how, but bug 34914 seems to be something that would help.