Last modified: 2014-06-22 19:18:13 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 T3542, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1542 - Log spam blacklist hits
Log spam blacklist hits
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Spam Blacklist (Other open bugs)
unspecified
All All
: Normal enhancement with 9 votes (vote)
: ---
Assigned To: Kunal Mehta (Legoktm)
:
Depends on: 3732
Blocks: SWMT
  Show dependency treegraph
 
Reported: 2005-02-15 21:23 UTC by Jeff Bonham
Modified: 2014-06-22 19:18 UTC (History)
13 users (show)

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


Attachments

Description Jeff Bonham 2005-02-15 21:23:48 UTC
It would be extremely useful to have a log of every time the spam blacklist blocks 
an edit, with the URL that was blocked. 
 
This would pin down problems on all the different wikis with filters that are too 
broad. 
 
This would also tell us whether our filters are actively blocking spam, and how 
often different spams are attempted, and where. 
 
This would also help us know when to expire filters from the spam blacklist (say, 
after six months or a year of inactivity).
Comment 1 Jeff Bonham 2005-02-20 09:01:49 UTC
A recent oops with the spam blacklist revealed that spambots are hammering [[PHP]] on en at 
least (the blacklist was temporarily not available and the article was spammed within six 
minutes).  IP checks also indicate that these attacks are being done using zombie machines 
(various ISP addresses, including an AOL IP, varying often).  If this log were added it might 
consume a fair bit of disk. 
Comment 2 Rob Church 2007-07-10 11:31:21 UTC
Matches *are* logged, in the standard debug log. I suppose we could introduce some sort of aggregation table to facilitate reports on most-spammed domains and other things like that.
Comment 3 Mike.lifeguard 2008-09-12 21:12:30 UTC
Can it be made available on the toolserver? We would probably want to run queries on so much data anyways.
Comment 4 Helder 2009-10-20 16:23:10 UTC
And what about the [[MediaWiki:Titleblacklist]]? Could we have a log for it?

Is there any bug about it?

Helder
Comment 5 Mike.lifeguard 2009-10-20 19:17:38 UTC
(In reply to comment #4)
> And what about the [[MediaWiki:Titleblacklist]]? Could we have a log for it?
> 
> Is there any bug about it?

See bug 21206
Comment 6 Rainer Rillke @commons.wikimedia 2012-03-03 11:57:34 UTC
Huhu, if the data are available somewhere, it would be kind if someone links to it from here and closes this bug.
Comment 7 seth 2012-09-15 18:50:31 UTC
It would be really a great help to have such a log (similar to the log of the abuse filter/edit filter).
Especially for coping with unblocking requests a log would be a great tool.
Comment 8 MZMcBride 2012-10-22 01:01:31 UTC
Marking this as easy.
Comment 9 Platonides 2013-03-07 21:36:40 UTC
I think the approach should be to log matches using abusefilter extension if that one is loaded.
Comment 10 seth 2013-03-09 22:56:01 UTC
(In reply to comment #9)

The abusefilter is not a good replacement for the spam blacklist. Both tools are important and they complement one another. I guess, if we moved all SBL entries to AF. This would slow down the whole thing. So there should be a individual log for the SBL for _all_ entries. This would be a great help in reducing the length of the very long lists at meta and w:en. And it would help in coping with blacklist removal requests.
Comment 11 Gerrit Notification Bot 2013-06-18 11:23:59 UTC
Related URL: https://gerrit.wikimedia.org/r/69303 (Gerrit Change I7b1ee2b3bb02b693d695bf66d157e2c33526c919)
Comment 12 Kunal Mehta (Legoktm) 2013-06-18 11:28:34 UTC
I've uploaded a patchset that implements logging to the standard Special:Log. I think using AF logging is a bit overkill, since all you really care about here is the link that is being added.
Comment 13 seth 2013-06-29 14:02:32 UTC
That sounds great! :-)
When will this be active in w:de?
Comment 14 Alex Monk 2013-06-29 16:47:04 UTC
(In reply to comment #13)
> That sounds great! :-)
> When will this be active in w:de?

We don't know which version it will be in until the change gets merged. Once that's done you can check https://www.mediawiki.org/wiki/MediaWiki_1.22/Roadmap
Comment 15 Gerrit Notification Bot 2013-09-08 00:58:43 UTC
Change 69303 merged by jenkins-bot:
Log blacklist hits to Special:Log

https://gerrit.wikimedia.org/r/69303
Comment 16 Kunal Mehta (Legoktm) 2013-09-08 01:10:01 UTC
Marking this as fixed since the patch has been merged.

https://gerrit.wikimedia.org/r/#/c/83353/ is for enabling this on WMF sites.
Comment 17 seth 2013-09-12 20:56:38 UTC
Searching all prevented additions for a given domain is what this request was about. But as far as I can see (e.g. at [https://en.wikipedia.org/wiki/Special:Log/spamblacklist]), it's still not possible to search for a given url or at least a domain, right?
Comment 18 seth 2013-09-12 21:01:42 UTC
oops, sorry, didn't see, that it's not yet available...
Comment 19 Kunal Mehta (Legoktm) 2013-09-13 00:16:04 UTC
Searching for a specific domain will not be possible due to how the logging data is stored, however it would be trivial (I already started working on one) to write a toolserver/labs tool that allowed such searches.
Comment 20 Helder 2013-09-13 12:12:03 UTC
(In reply to comment #17)
> Searching all prevented additions for a given domain is what this request was
> about. But as far as I can see (e.g. at
> [https://en.wikipedia.org/wiki/Special:Log/spamblacklist]), it's still not
> possible to search for a given url or at least a domain, right?

I believe the script [[commons:MediaWiki:Gadget-rightsfilter.js]] makes it possible to filter the SPAM logs to find those which refer to a specific URL.

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


Navigation
Links