Page MenuHomePhabricator

Wikidata edit filter does not fire when test tool says it should
Open, Needs TriagePublic

Description

https://www.wikidata.org/w/index.php?title=Wikidata:Contact_the_development_team&oldid=1161804660#AbuseFilter_not_triggering_on_edits_that_would_trigger_it
https://www.wikidata.org/wiki/Topic:Vkqokk527p3u4cnp

I created Wikidata edit filter 131 to block certain LTA activity from wide IP blocks, intended as a softer alternative to imposing blocks across many /16 blocks. Since then, while is has been successful in preventing some abuse, there have been multiple cases where it did not fire in cases where it would have been expected to do so. Further, the test tool intended to preview the effect if the tool says that it _does_ fire for those edits. Even if there is some bug in the filter definition, we would expect the filter and the test tool to behave consistently.

Steps to reproduce:

  1. Open https://www.wikidata.org/wiki/Special:AbuseFilter/131
  2. Click on the tool "Test this filter against recent edits"
  3. Under "Changes made to page" enter "Q1447095".
  4. Observe green check marks against certain changes on 2020-04-20 by 113.218.0.173 and 113.218.0.0.
  5. Under "Changes made to page", now enter "Q275139".
  6. Observe green check marks against certain changes on 2020-04-18 by ‎61.187.158.133.

If the edit filter had been operating consistently with the test tool (and the behaviour I expect), then these changes would have been prevented.

Event Timeline

Haven't checked deeply, but a possible hint is that AF doesn't see automatic edit summaries (I think there was a task for that) which, however, it sees when retrospectively examinating edits.

Haven't checked deeply, but a possible hint is that AF doesn't see automatic edit summaries (I think there was a task for that) which, however, it sees when retrospectively examinating edits.

But still, the edit summary it sees (the *real* summary) is something like /* undo:0||REVID|USERNAME */. The filter's summary-related part is designed to catch "undo:0" (not "Undo revision REVID by USERNAME", which is the automatically generated summary).

For information: I have now disabled this edit filter in favour of a set of softblocks on certain /16 IP ranges.

For testing, I re-used blank https://www.wikidata.org/wiki/Special:AbuseFilter/31 with

'undo:0' in summary

During the test, there were at least 9 undo actions (tagged as mw-undo, example) but none of them triggered the filter. So @Daimona may be right...

Haven't checked deeply, but a possible hint is that AF doesn't see automatic edit summaries (I think there was a task for that) which, however, it sees when retrospectively examinating edits.

But still, the edit summary it sees (the *real* summary) is something like /* undo:0||REVID|USERNAME */.

It depends on how you define "real". I have to say, I'm not at all certain about the summary that the filter is effectively seeing, so... I don't even know where the 'undo:0 ...' part is coming from in Wikibase, so I can't tell whether it can be read by the AF.

For testing, I re-used blank https://www.wikidata.org/wiki/Special:AbuseFilter/31 with

'undo:0' in summary

During the test, there were at least 9 undo actions (tagged as mw-undo, example) but none of them triggered the filter. So @Daimona may be right...

Not surprising... I'd be glad to confirm this and investigate it locally, but I don't have Wikibase installed on my wiki, and it's also not so easy to install IIRC (also I'm not practical with it).