Add more variables to AbuseFilter file uploading evaluation
OpenPublic

Description

as title.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=14417

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz19565.
liangent created this task.Via LegacyJul 7 2009, 2:37 PM
werdna added a comment.Via ConduitJul 16 2009, 5:04 PM

(Batch change)

These are low-priority miniprojects that I can mop up at some point when I'm doing general code work as opposed to working on a specific projects.

werdna added a comment.Via ConduitAug 14 2009, 12:37 PM

[Batch change]

Removing Dave McCabe from CC, who I somehow managed to add to the CC list of 12 bugs assigned to me.

Rillke added a comment.Via ConduitNov 9 2011, 1:23 PM

Some checks are possible:

  • Title, user, action and SHA1 of file

Reference:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/AbuseFilter/AbuseFilter.hooks.php?view=markup#l280

Especially for Commons it would be desirable if we could check the *content* (wikitext) of the new file for "source= google,..." and other invalid sources to automatically tag them.

Thank you.

hoo added a comment.Via ConduitFeb 28 2013, 1:40 AM

(In reply to comment #3)

Especially for Commons it would be desirable if we could check the *content*
(wikitext) of the new file for "source= google,..." and other invalid sources
to automatically tag them.

Thank you.

I tried to lay the foundation for this in https://gerrit.wikimedia.org/r/51326 (not yet merged) where I changed the extension to use a hook which provides more data than just the file names... but this still requires some changes to MediaWiki itself and then a follow up to the linked patch.

I'll keep you updated.

liangent added a comment.Via ConduitOct 8 2013, 8:33 AM

Just found that AbuseFilter already checks file uploads, but there aren't many variables available.

Currently those variables include:

Edit count of user (user_editcount)
Name of user account (user_name)
Groups (including implicit) user is in (user_groups)
Whether or not a user is editing through the mobile interface (user_mobile)
file_articleid = page id of the image page, or "0" for new uploads
file_namespace = "6"
file_text = unprefixed page name of the image page
file_prefixedtext = full page name of the image page
Action (action) = "upload"
SHA1 hash of file contents (file_sha1)
Whether or not the change was made through a tor exit node (tor_exit_node)
Unix timestamp of change (timestamp)

Missing:

upload comment
wikitext of the image page (for new uploads)

Mahitgar added a comment.Via ConduitFeb 27 2014, 12:54 PM

Any updates about progress on this bug Please . We prefere this getting fixed. Rgds

Aklapper added a comment.Via ConduitFeb 27 2014, 1:05 PM

This report has low priority, but if you have a high interest in getting a specific problem fixed, you could provide a patch to speed up the process.
See https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker for more information.

hoo added a comment.Via ConduitFeb 27 2014, 1:14 PM

This is still blocked by changes to how MediaWiki handles uploads (and especially the page creations linked to them)... we need more context from that side (right now AbuseFilter has no way to know about the wikitext used as description).

FDMS added a comment.Via ConduitSep 8 2014, 8:28 PM

This bug enables bad-faith editors to upload media files with an invalid {{permissionOTRS}} tag without anyone noticing. Therefore, in my opinion, this is not a low priority enhancement.

Aklapper added a comment.Via ConduitSep 8 2014, 10:56 PM

[As long as nobody works on this ticket it de-facto will be low priority, no matter what the Priority field will be set to.]

werdna removed a subscriber: werdna.Via WebDec 10 2014, 5:24 PM
Legoktm added a subscriber: Legoktm.Via WebJan 8 2015, 5:29 AM

https://gerrit.wikimedia.org/r/183430 added a file_size variable.

Steinsplitter added subscribers: Rjd0060, pajz, Krd.Via WebJan 8 2015, 6:08 PM
Steinsplitter set Security to None.
DFoy added a subscriber: DFoy.Via WebJan 8 2015, 6:57 PM
Fae added a subscriber: Fae.Via WebWed, Feb 11, 3:59 PM
Fae added a comment.Via WebWed, Feb 11, 4:03 PM

This is a great loophole for copyright abuse and uploading professional photographs to Commons without permission. Once an OTRS ticket gets "recycled", an image would be highly unlikely to get noticed as a copyright problem or that the ticket was not added by anyone with OTRS access.

If this cannot be fixed, we really should consider if an efficient bot can be designed to do the same job.

Se4598 added a subscriber: Se4598.Via WebWed, Feb 11, 9:36 PM
In T21565#1031373, @Fae wrote:

This is a great loophole for copyright abuse and uploading professional photographs to Commons without permission. Once an OTRS ticket gets "recycled", an image would be highly unlikely to get noticed as a copyright problem or that the ticket was not added by anyone with OTRS access.

If this cannot be fixed, we really should consider if an efficient bot can be designed to do the same job.

What exactly is your point? What variables are missing for OTRS-checking?
If AF doesn't pick up a upload it should, then it's a bug, but outside of this tasks scope.

ok @Fae, I think I understand and you mean T89252.

Fae added a comment.Via WebWed, Feb 11, 11:23 PM

ok @Fae, I think I understand and you mean T89252.

Yep, probably. It's not a "bad" OTRS ticket though, this is just finding a way to flag when a non-OTRS user adds what might be a perfectly good ticket. In fact sometimes we want batch uploaders to do things this way, so it's not something to stop, just something to track.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.