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.

@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.

In T155967#2963536, @JEumerus wrote:

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]

@Billinghurst and others: I've created T246090 to discuss whether GET/read requests should be left unlogged, as it seems slightly unrelated to the issue here.

Update? Is there any reason not to merge the patch from 2017 (after rebasing it)?

Anyone please feel free to rebase it first.

I looked at the code, and I'm not sure whether this actually removes the IP from public view, or just makes it harder to find (so it's not displayed on Special:Log, but maybe will pop up in other places like the API, replica DBs, filtering by username, etc.). The mechanism of hiding it seems to be to change the system message used for title blacklist log entries. Is this sufficient?