Last modified: 2013-08-13 17:48:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T43522, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 41522 - Provide a log of actions which trigger the CAPTCHA
Provide a log of actions which trigger the CAPTCHA
Status: PATCH_TO_REVIEW
Product: MediaWiki extensions
Classification: Unclassified
ConfirmEdit (CAPTCHA extension) (Other open bugs)
unspecified
All All
: Normal enhancement with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: analytics
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-30 00:24 UTC by Helder
Modified: 2013-08-13 17:48 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Helder 2012-10-30 00:24:16 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).
Comment 1 Andre Klapper 2012-10-30 11:36:01 UTC
["It would be useful" => severity=enhancement]
Comment 2 Platonides 2012-11-03 18:19:49 UTC
I don't think they need to be in "emergency mode". → Bug 41745
Comment 3 Helder 2012-11-03 18:25:05 UTC
(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)
Comment 4 Helder 2012-12-25 20:46:43 UTC
Draft at gerrit change I5ad1f8d5.
Comment 5 Nemo 2013-01-24 13:53:13 UTC
Does it hide them by default from log view, like patrol and review?
Comment 6 Helder 2013-01-24 16:36:11 UTC
(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.
Comment 7 John Mark Vandenberg 2013-01-24 20:20:40 UTC
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.
Comment 8 Umherirrender 2013-01-26 14:46:41 UTC
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.
Comment 9 MZMcBride 2013-06-28 03:15:23 UTC
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.
Comment 10 Helder 2013-06-28 10:58:35 UTC
(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...
Comment 11 SJ 2013-07-07 17:59:23 UTC
I like the idea of resolving Bug 18110 as a solution here.
Comment 12 Nemo 2013-08-13 17:48:53 UTC
It's not clear to me how, but bug 34914 seems to be something that would help.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links