Page MenuHomePhabricator

Provide a log of actions which trigger the CAPTCHA
Open, NormalPublic

Description

As a sysop, I would like to whitelist at MediaWiki:Captcha-addurl-whitelist any god URLs which might be added as sources by new users, so that they can reference articles without having to solve a CAPTCHA. For this, I would need to know which sites users attempt to add. It would also 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).

A workaround would be to implement the request from T20110: Allow AbuseFilter to force the user to solve a captcha.

See Also:
T36914: LoginAuthenticateAudit should be extended to also report access attempts blocked by anti-spam extensions

Details

Reference
bz41522

Event Timeline

bzimport raised the priority of this task from to Normal.
bzimport set Reference to bz41522.
bzimport added a subscriber: Unknown Object (MLST).
He7d3r created this task.Oct 30 2012, 12:24 AM

["It would be useful" => severity=enhancement]

I don't think they need to be in "emergency mode". → Bug 41745

He7d3r added a comment.Nov 3 2012, 6:25 PM

(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.

He7d3r added a comment.EditedJun 28 2013, 10:58 AM

(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". T20110 would have the advantage of allowing us to see the text the user was trying to add before the CAPTCHA appeared...

Sj added a comment.Jul 7 2013, 5:59 PM

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.

Ricordisamoa set Security to None.
He7d3r updated the task description. (Show Details)Mar 18 2015, 2:31 PM
He7d3r added a project: Analytics.
Restricted Application added subscribers: Florian, Aklapper. · View Herald TranscriptDec 7 2015, 6:41 PM
He7d3r updated the task description. (Show Details)Apr 22 2018, 6:31 PM
He7d3r removed a subscriber: wikibugs-l-list.