Meta:Babel/Archives/2016-12

From Meta, a Wikimedia project coordination wiki


AbuseFilter monitoring[edit]

Tracked in Phabricator:
Task T154358 resolved

Hello. I'd like to be able to monitor all abuse filter hits over IRC thus I'm asking for permission to enable $wgAbuseFilterNotificationsPrivate for this wiki so I can monitor all abusefilter hits, included those of private filters via IRC. No filter content or private details will be disclosed to the IRC (irc.wikimedia) server, but by default filter hits on private filters ain't reported. Thanks. —MarcoAurelio 16:14, 24 December 2016 (UTC)[reply]

  • Support Support, I think it is a good idea.--Syum90 (talk) 08:58, 26 December 2016 (UTC)[reply]
  • Support Support --Steinsplitter (talk) 09:02, 26 December 2016 (UTC)[reply]
  • Comment I would like to also see it, can I have an access to see it? I like to see the approach and seeing false positive and false negative and apply correct approach on other wikis. --AldNonymousBicara? 11:15, 26 December 2016 (UTC)[reply]
  • Support Support sounds good.--Infinite0694 (Talk) 15:21, 26 December 2016 (UTC)[reply]
  • Support Support, I use it heavily on wikis I take care of and it is very useful to fight spam and vandalism. In fact I have never been explained reasons why such hits should not be reported on IRC when in fact they don't contain anything private (the only "privacy" is, that the filter is marked as such). And I think it should be reported by default on all wikis as well.
    Danny B. 20:51, 26 December 2016 (UTC)[reply]
  • Support Support not seeing any trouble related to this. — xaosflux Talk 20:16, 27 December 2016 (UTC)[reply]
  • Support Support per above —JuniorX2 ChatHello! 00:48, 28 December 2016 (UTC)[reply]
  • Thank you. I have submitted phab:T154358. —MarcoAurelio 13:11, 31 December 2016 (UTC)[reply]
  • Question - Does this include private/non-public filters? Does that make a difference in the ease by which those non-public filters can be deduced and evaded? Risker (talk) 04:31, 5 January 2017 (UTC)[reply]
    • Yes it does - please see the first paragraph. Regarding the second question, please see my comment above. Also, any filter can be somehow narrowed to as little set of matching cases as possible while trying as many possibilities as necessary to be enough to ensure on such result.
      For the sake of completeness, here you have a (generalized) example how the abusefilter message looks like:
      yyyy-mm-dd hh:mm:ss [[Special:Log/abusefilter]] hit * <username> * <username> triggered [[Special:AbuseFilter/<filter_number>|filter <filter_number>]], performing the action "<performed_action_type>" on [[<page_title>]]. Actions taken: <taken_action_type> ([[Special:AbuseLog/<log_item_number>|details]])
      so obviously apart from notifying that "something happenned", there is nothing else there useful for potential abuse or misuse.
      Danny B. 07:44, 5 January 2017 (UTC)[reply]
    • Danny's reply is accurate. The IRC output just displays an abusefilter log entry, and since the description of the matched rule is public, I don't think there's any leak of private information that can make evading the filter easier, because neither the filter content nor the details are being sent to IRC. This will be useful for Meta since a number of our filters are private, and it'll help detect and stop prolific vandals and spammers repeatedly hitting the edit filter until they manage to avoid it or spam the log. And since the log of global edit filter hits are hosted on Meta, we can in adittion further this monitoring tasks on all wikis where global edit filters are enabled (by default, all small and medium-sized wiki, plus a few others that decided to opt-in). Best regards, —MarcoAurelio 08:08, 5 January 2017 (UTC)[reply]
      • Actually, it just came to my mind, that we checked just IRC, but the new(ish) RCstream should be checked as well to ensure it does not provide any additional details. Maybe Krinkle (thanks in advance!) could help to speed up the check by checking the relevant sources so we wouldn't have to wait for triggerring any private filter on some wiki which allows that to see the result...
        Danny B. 09:00, 5 January 2017 (UTC)[reply]
        • I checked and not even the filter description is provided in the feed: [[Special:Log/abusefilter]] hit * MarcoAurelio * MarcoAurelio triggered [[Special:AbuseFilter/1|filter 1]], performing the action "edit" on [[Meta:Sandbox]]. Actions taken: none ([[Special:AbuseLog/250157|details]]) is an actual example of what is shown. Thanks. —MarcoAurelio 22:57, 11 January 2017 (UTC)[reply]
  • Support Support No reason not to... trusted user. --Atcovi (Talk - Contribs) 21:35, 10 January 2017 (UTC)[reply]
  • Support Support per Above. Murbaut (talk) 21:53, 10 January 2017 (UTC)[reply]

This is now live and should be working. Thanks for participating. Best regards, —MarcoAurelio 22:57, 11 January 2017 (UTC)[reply]

Global filter hits not being reported[edit]

After the change has gone live, I've just noticed that few filter hits on global filters had hapened since, and none of them are being reported to the meta IRC feed. Shall we request that such global filter hits be logged to an specific IRC channel on the irc.wikimedia network or log them too at meta.wikimedia IRC? Thanks, —MarcoAurelio 23:02, 11 January 2017 (UTC)[reply]

  • I think a separate channel would be better here. — xaosflux Talk 04:11, 12 January 2017 (UTC)[reply]
  • It is my opinion as well. —MarcoAurelio 10:40, 12 January 2017 (UTC)[reply]
  • I prefer global hits to be reported on the channel of the project where the hit happenned, so in this case #meta.wikimedia. Format of IRC messages is quite simple, so if someone feels it is overwhelming, can simply add /ignore rule which would filter these global hits out (for instance I ignore this way all bot edits). Spreading to more channels is rather contraproductive, as it requires monitoring of more channels, therefore splitting the concentration which may result in missing of some important part of the feed.
    Danny B. 08:28, 19 January 2017 (UTC)[reply]