I'd like to surface that this has continued being a big UX problem, and increasingly big ever since iCloud Private Relay has become more common to be enabled by default for Apple users.

The kinds of attacks Daniel describes here are important and AbuseFilter is one of the best tools the community has available. The community has come to deploy AbuseFilter quite responsibly and thoughtfully, and it makes sense to me to allow the community to decide whether a particular filter should present a captcha at what level of edits, rather than having a blanket rule that autoconfirmed users can't be captcha'd by AbuseFilter.

Reviving this ticket to note that recently we noticed an instance of proxy block evasion using a 6to4 IP address. I don't know if this is worth substantial engineering effort given that 6to4 is deprecated and very rarely used in the wild; instead, if there is a serious flare of abuse, I would recommend simply disabling editing from 6to4 addresses across the board.

Thanks for everyone's work on this.

Thank you to Dreamy and everyone for your work on this.

My sincere thanks to everyone for the swift action here!

I am responsible for a fair number of these blocks on enwiki. I frequently get emails these days from furious users about being blocked for no reason. This is troubling to me because for every user who emails about this, there are probably many users who didn't email about it and instead, fed up, just decided not to edit.

Thank you for starting this. As an enwiki CU, I appreciate the effort WMF is devoting to Trust and Safety Tools. Would it be possible for project CUs to weigh in more on their needs for such a tool? In particular, I will note that project CUs don't normally limit themselves to looking for exact matches (IP and User-Agent exactly matching), and so if this ever comes to supplant the raw availability of user-agents or client hints, the MVP of the unique device identifier locality-sensitive hash would then have to include include:

In T380221#10333285, @Urbanecm wrote:

Personally, I'd be open to removing the restriction for good, and allowing people to query IP Info for any IP (Temporary account), regardless of whether it actually edited. This might seem unnecessary, but IPs often make an action that is rejected prior to saving (by an AbuseFilter, spam filter or the like). When looking at those events, IP Info data can be useful, but cannot be generated natively. This is even more visible in the Temporary accounts world – there is always some reason for a Temporary account creation, and that reason always is "the user attempted to make a write action". Sometimes, that attempt is not successful, but that can be a valid reason to want to see IP Info data. Given this and the other is very similar to each other, I'm not filling a separate task for "allow data to be queried for any actor", but I do see a lot of usecases where that would be helpful.

Hi everyone. As a brief update, several Research staffers joined ArbCom for a call last week and we discussed the white paper. Several arbitrators left comments, and we will be looking forward to any revisions prior to eventual clearance and approval on our end. On the whole, arbitrators were very thankful for the work and impressed with its quality. Thank you!

It's definitely an improvement. I'll take it, if that's what we've got. Looping over all the blocks would also be satisfactory. Or, just remove the "There are multiple blocks against your account and/or IP address" part — that's already implied because we're calling blockedtext-composite, not blockedtext. If you remove the "There are multiple blocks against your account and/or IP address" from the block reason, that allows local customization for how to inform the user that there are multiple blocks.

Hello everyone. I write to emphasize this is a highly urgent issue and needs prioritization. This issue affects everyone who is using a VPN and editing the English Wikipedia -- including many who may not even know that they are using a VPN (see, e.g., iCloud Private Relay). I am guessing this is at least 10% of the non-established editors who attempt to edit, though I don't have a real basis for this. As I'm sure y'all can empathize with, receiving this message must be infuriating and entirely inconsistent with the Foundation's prioritization of Growth in its planning.

In T314672#8147378, @Tgr wrote:

@L235 is there any other place where you would expect better documentation?

Maybe "log", then? The schema is less well-defined there, and it's used by other services (such as the abuse filter log) that don't create entries on Special:Log.

We run into the 5000 entry limit *all the time* and having a way to navigate those results would make us much more effective as a team. This would be a good task to prioritize if there is capacity for that.

This seems like a relatively easier task that would help immensely, given the ubiquity of script usage when using CU.

This would be quite helpful.

This is already possible and being done on enwiki by testing the $7 parameter for whether it's an IP address. See https://en.wikipedia.org/wiki/MediaWiki:Blockedtext.

I would support this request; as an enwiki CU who has used this tool informally by emailing Ladsgroup, I can attest that this tool would be wonderfully helpful.

@Tgr that would be an insufficient response. It may be stating the obvious to you, but to the *many* editors who have come to functionaries in very tough situations (harassment or even legal trouble) after using a publicly identifiable username who registered prior to this message, it certainly was not. This was what prompted us to post this message in the first place.

I'm going to make this a security-protected issue for now for the reasons given in T265845#7309052 as a precaution. If this was the wrong call please feel free to reverse, but I'd rather be safe than sorry.

This would be useful on the English Wikipeida.

While interim stopgap measures (e.g. Znuny) should be implemented, this is a good opportunity to revisit the software we're using for email response purposes. OTRS is notoriously difficult to use: for example, I have heard from many English Wikipedia CheckUsers who refuse to use OTRS due to the difficult interface. Previously, the chief advantage of OTRS was its open-source ethos; unfortunately, that seems to no longer be a benefit. We should seriously consider using vaguely modern and well-designed CRM software, and switch away from OTRS and its descendant projects as soon as technically and logistically reasonable.

This is a big issue and I hope that it receives priority for fixing.

See also the recent discussion on enwiki which prompted this, and a user script that mitigates this issue: https://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard&oldid=953329946#Fun_admin_script.

Done per IRC request.

Yes. Per this document, expected and normal behavior in the past is that redirects converted to articles show in the queue. Also see this discussion for more local info. Thanks!

This is an urgent issue for the enwiki community. This allows users to easily circumvent the new page patrol process, on pages that have usually been unwatched but are precisely the ones that are not notable enough for articles (that's why they're redirects in the first place). I hope that we'll see a fix for this as soon as possible. Thanks!

@Dzahn, I was intending to make Board business (voting and reports and such) easier replacing our current patchwork system, so I think a second list would be needed, but to avoid the confusion, perhaps "wikimedia-us-ia-board" would be better?

Thanks @Dzahn! Per the description, could you create wikimedia-us-ia-internal@lists.wikimedia.org as well?

@RobH, thanks! Yeah, please remove me from the moderator list as well. Cheers!

Chmarkine, there's always StartCom/StartSSL which has free certs, and they're already trusted by default in all major browsers.

Thanks Dzahn, appreciate it.

Also reproduced in Firefox Developer Edition and Firefox Nightly (on the same machine):

I can reproduce this at https://sv.wikipedia.org/wiki/Pwdes?veaction=edit. Screenshot attached.

Thanks. I suspected that was the issue but wasn't sure.

it's not working (if you try to search "wm2016:" on any wiki) nor is it showing up in Special:Interwiki

This needs to be added to the interwiki table as "wm2016", keeping in line with the previous Wikimania wikis.

Can confirm that I'm also getting this on several pages on en.wp. It's intermittent and happens in about one in two requests.