Last modified: 2014-11-18 18:07:33 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 T34959, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32959 - Private filters should not be visible in recent changes
Private filters should not be visible in recent changes
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
AbuseFilter (Other open bugs)
unspecified
All All
: Normal enhancement with 6 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-11 08:39 UTC by Tisza Gergő
Modified: 2014-11-18 18:07 UTC (History)
5 users (show)

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


Attachments

Description Tisza Gergő 2011-12-11 08:39:09 UTC
When a vandal is active, and someone creates/changes a private abusefilter to stop him, there will be a log event in recent changes, available for the vandal to see. This can draw unwanted attention to the feature. Such log events should be hidden from users without the abusefilter-viewprivate right.
Comment 1 Pine 2012-06-05 04:30:51 UTC
How
Comment 2 Pine 2012-06-05 04:31:36 UTC
How would we prevent the vandal from seeing logs that are set to public? This is the nature of public abusefilters.
Comment 3 Kunal Mehta (Legoktm) 2012-12-14 13:38:03 UTC
I'm not sure this is a bug. If you look at [[Special:Log/abusefilter]], you can't see any information besides timestamp, user, and filter number for a private filter. None of that information should be private really.

(In reply to comment #2)
> How would we prevent the vandal from seeing logs that are set to public? This
> is the nature of public abusefilters.

I think the bug only covers private filters.
Comment 4 Tisza Gergő 2012-12-14 19:48:46 UTC
The point is that a vandal who, until then, maybe did not even know that there are  such things as edit filters, will easily realize that he is being tracked by such a filter by looking at the Recent Changes page. Vandals usually do not look at system logs, but they do look at RC.
Comment 5 Kunal Mehta (Legoktm) 2012-12-14 20:32:16 UTC
(In reply to comment #4)
> The point is that a vandal who, until then, maybe did not even know that
> there
> are  such things as edit filters, will easily realize that he is being
> tracked
> by such a filter by looking at the Recent Changes page.

How would the vandal know that that specific filter was for xyr if they can only see the filter #? And wouldn't a vandal know they are being tracked as soon as they see that their edits are being blocked by the filter?

> Vandals usually do
> not
> look at system logs, but they do look at RC.

I'm not seeing how hiding this information in once place but not in another is advantageous, and will prevent exploitation of the filters.
Comment 6 Tisza Gergő 2012-12-14 21:23:19 UTC
(In reply to comment #5)
> How would the vandal know that that specific filter was for xyr if they can
> only see the filter #? 

From the timing, especially on smaller wikis. If you are vandalizing, your edits are refused, you change your pattern, you get through, but after a few edits you are refused again, and the same time an RC entry appears about abuse filter changes, that is kind of obvious.

> And wouldn't a vandal know they are being tracked as
> soon as they see that their edits are being blocked by the filter?

Sure, but the filter messages in themselves do not give you much information about what is going on (not enough to abuse it, anyway). Pointing them to the AbuseFilter page, which further points them to the documentation, with details of how exactly the tool works, is unhelpful.

> I'm not seeing how hiding this information in once place but not in another
> is advantageous, and will prevent exploitation of the filters.

Ideally it should be hidden everywhere (given that the log does not say anything useful, and all the links do not work if you have no privileges, there is no point to showing them anyway - it is bad UX design to put links before the user and only notify him after he clicks that he is not allowed to use them), but hiding it on the page which abusers are reading is more important than hiding it on pages they are not reading.
Comment 7 Kunal Mehta (Legoktm) 2012-12-15 21:46:26 UTC
Ok, I think it makes enough sense to work on this.

I looked into it, and MediaWiki itself doesn't support hiding log entries to a certain usergroup, so a patch to MediaWiki core would needed to support this.

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


Navigation
Links