Page MenuHomePhabricator

Replace IPs with "an anonymous user" in title blacklist hits log
Open, Needs TriagePublic

Description

Doing so would violate the WMF privacy policy (see T68450).

Event Timeline

Cenarium created this task.Jan 23 2017, 3:36 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJan 23 2017, 3:36 AM

Change 333559 had a related patch set uploaded (by Cenarium):
Don't display anons in title blacklist log, add to CU data, reenable it

https://gerrit.wikimedia.org/r/333559

@Cenarium : About that Gerrit patch, does it hide all IPs or just these who try to make an account? Because my understanding is that only the latter scenario can cause a privacy leak. A mere edit in contrast would be a-OK.

This proposed change if it matches the title is problematic. The way it reads it says no IP hits on title blacklist will show. That is of little value.

Title blacklist affects

  • creations of new accounts
  • creation of new pages
  • restricting certain pages to autoconfirmed editors
  • move blocks
  • reupload
  • prevent editing

The only concern should be where there is an account creation. All others should be visible for admins/checkuser/stewards. Rather than restrict the view /items, why not change the output in that for admins that the output blanks the IP address, or replaces it with xxx.xxx.xxx.xxx and displays it for checkuser/stewards.

I would also argue that stewards should have access to title blacklist data equal to checkusers without a requirement to give themselves specific rights allocation, though I can be argued out of that matter if it is difficult for technical reasons.

Cenarium renamed this task from Don't display anonymous users in title blacklist hits log to Replace IPs with "an anonymous user" in title blacklist hits log.Jan 23 2017, 2:28 PM

@JEumerus, @Billinghurst: only account creation attempts can be logged (since it's a POST request, others are GETs, so this could be abused).

@Billinghurst: I've clarified the meaning, it only replaces the IP in the log with "an anonymous user", it doesn't remove the entry entirely. See T68450 for the need to log the access.

Why would editing a/moving to a blacklisted title be a GET request? Does the titleblacklistlog trigger upon merely clicking the edit button?

Yes, the titleblacklist is hit by merely having &action=edit in the URL. See T23206 for a thorough discussion of this.

Perhaps one could log actual save attempts (which are POST requests, I believe) that trip the blacklist like normal and not log mere requests (which are GET requests, I believe) such as accessing a blacklisted edit page URL.

Users will not be able to make the save attempts since they have been blocked from accessing the edit URL (except in the case where a blacklist entry is added while the user was already editing the article, but it's too rare to be useful). Users are blocked from the edit URL so they don't waste their time making edits that will end up being blocked, as for protected pages.

Perhaps one could log actual save attempts (which are POST requests, I believe) that trip the blacklist like normal and not log mere requests (which are GET requests, I believe) such as accessing a blacklisted edit page URL.

That would be really helpful, as for defence purposes it is only the actual "attempt to save action" as the problem is often intense/shock vandals, and spambots.

As a clarification, as there is the <autoconfirmed> option, are you saying that it would trigger a warning to the user when they attempt to edit, rather when they attempt to save. [one asks naively as one has never triggered the title blacklist]