Page MenuHomePhabricator

Special:AbuseLog should not show log entries of private filters
Open, MediumPublic

Description

Users without the abusefilter-view-private permission are not able to see the logs of private filters when browsing to them directly (example). However Special:AbuseLog (without specifying a filter ID) shows every filter that's hit, such that one could put together the logs of a private filter.

If we can't see the logs in one fashion, we shouldn't be able to see it any fashion. This includes specifying a user (example), or a page title. Consequently this would mean the filter title is also not visible in any way, which I think is good. Currently many times we have to make our filter names intentionally broad because the target vandal can see it and know it is for them.

The one drawback here is users without the requisite rights won't be able to tell that a user hit a private filter at all. So say if the affected user reached out for help, only filter managers would be able to help them. Perhaps this would need some community input, but again I think it's logical to assume that since I can't see the logs of a filter when browsing to it directly, I shouldn't be able to piece together the same log manually.

Event Timeline

How about: if you don't have abusefilter-view-private rights, the logs you see should not say the filter's name, but just say "private filter #123"?

How about: if you don't have abusefilter-view-private rights, the logs you see should not say the filter's name, but just say "private filter #123"?

Yeah that's fine. That way all users at least know which is filter involved, and what actions it took.

How about: if you don't have abusefilter-view-private rights, the logs you see should not say the filter's name, but just say "private filter #123"?

Yeah that's fine. That way all users at least know which is filter involved, and what actions it took.

Err, maybe. You could still piece together the logs of a private filter, you just wouldn't know the name of it. That's an improvement for sure, but we might seek broader input on whether the logs should be visible at all. Other logs such as checkuser aren't visible to anyone except CUs, and I like to think this analogous. While private filters aren't nearly as sensitive, the whole idea is that the users who are being targeted can't decipher there is a filter running and when it is enabled/disabled, etc., not just the "details" of the filter. I delt with at least one LTA who managed to figure out the filter # when the filter title was intentionally vague and misleading.

Other logs such as checkuser aren't visible to anyone except CUs, and I like to think this analogous. While private filters aren't nearly as sensitive, the whole idea is that the users who are being targeted can't decipher there is a filter running and when it is enabled/disabled, etc., not just the "details" of the filter.

If the filter is preventing the user from making an edit and/or blocking the user, then the user in question will know a filter is involved. The only condition in which AbuseFilter and CU could be seen as analogous is where a filter does not actually stop/block a user but just silently logs a certain activity, and you don't want the user to know that.

Also, I think we can simply add a checkbox in filter settings called "Hide the logs from the public" which would restrict seeing the logs for that filter to only those who can see the filter itself. And this can be selected per-filter.

I delt with at least one LTA who managed to figure out the filter # when the filter title was intentionally vague and misleading.

I don't see a real problem with the LTA finding out the filter #. What can they do by just knowing the filter number?

I don't see a real problem with the LTA finding out the filter #. What can they do by just knowing the filter number?

Wait till we disable it due to there being no hits, and go on a rampage. For this LTA I had to create a dummy filter to throw them off. I'd consider this very much an edge case but it has happened :)

If the filter is preventing the user from making an edit and/or blocking the user, then the user in question will know a filter is involved. The only condition in which AbuseFilter and CU could be seen as analogous is where a filter does not actually stop/block a user but just silently logs a certain activity, and you don't want the user to know that.

Yes, the log-only situation is what prompted this ticket. We were using an informative title for our filter (perhaps a mistake), and some users were discussing that it was enabled on high-traffic on-wiki venues, because they saw it at Special:AbuseLog. They were acting in good faith but the LTA knew it was time to change the M.O., and that they could check the logs to see if we were successfully tracking them.

Also, I think we can simply add a checkbox in filter settings called "Hide the logs from the public" which would restrict seeing the logs for that filter to only those who can see the filter itself. And this can be selected per-filter.

Per above, in general I think private should mean private. I can't think of many times where I'd want the logs of my private filter to be exposed in one place (AbuseLog without options) but not another (AbuseLog with the filter ID). However again some may disagree that they should ever be completely hidden, so I'll start a discussion soon.

Okay now I can understand where you come from, and relate to it better. Please post a link to the community discussion here, so I can also contribute.

PS: we have several filters with exactly the same name, so that LTAs cannot figure out which one does what :)

@Huji Started a discussion at WP:EFN on enwiki. If this proves to be at all controversial (but there is still support for it), we might want to start a discussion on Meta too.

I like the idea of per-filter additional screening being an option.

There is an obvious segment of the Wikimedia community who would find the idea of non-publicly logged actions of an administrative nature (Such as denying registrations, edits etc), to be Orwellian and there is no evidence to suggest that this change will prevent the situation described by MusikAnimal...

Take it to RFC. The enwiki EF guideline says that "For all filters, including those hidden from public view, a brief description of what the rule targets is displayed in the log, the list of active filters, and in any error messages generated by the filter." - Enwiki approved the implementation of the edit filter on the understanding that private filter actions will be publicly logged in some manner; Any deviation from the public logging element of private filters would place the edit filter outside of the approved form of operation, and outside community consensus.

Furthermore, raising this issue solely at EFN is tantamount to a canvass - Of course the reception will be positive, as EF managers who watch that board are likely to resonate with the advantages of the changes, whilst ensuring that few non-EF-oriented community members see the discussion to comment on the transparency concerns.

Related to T20476, which is for adding IDs, see tables in my last 2 comments. My doubt for this task is how would it be possible for an abuser to piece logs, since they wouldn't have that much info. What is the proposal to fix this?

Just came across this when I came to report that, even without being able to view private filters, using the api makes it fairly trivial to connect private filter entries to the filter itself. I have no intention of advertising the script, but it shows the flaw in revealing the filter description.

Daimona added a subscriber: Nardog.