Page MenuHomePhabricator

Investigate the practice of making thousands of global blocks per day on Meta-Wiki
Open, Needs TriagePublic

Description

The stewards on Meta-Wiki are issuing thousands of global blocks on some days. For example, so far today over 41,000 global blocks have been issued. Many of these blocks are for a short period of time such as 24 hours.

The purpose of this task is to answer a few questions.

Is issuing thousands of global blocks per day now an accepted standard practice?

Should stewards on Meta-Wiki be making thousands of automated global blocks per day?

Is the Wikimedia operations team okay with this practice?

Should these blocks be handled by smarter software?

Event Timeline

Hmm, have you asked stewards, as they might know best? :) Which aspects do you have in mind that might make SRE not be okay with this practice?

Hmm, have you asked stewards, as they might know best? :)

I mentioned it to them, yes. The stewards appear to be in a battle mentality against long-term abusers.

Which aspects do you have in mind that might make SRE not be okay with this practice?

It's kind of horrible to be making thousands of short blocks per day like this. The "flood" user group mitigates some of the impact, but relying on volunteers to make dozens of blocks per minute for hours every day seems like a pretty flawed design.

taavi closed this task as Resolved.EditedMar 14 2022, 10:04 PM
taavi added a subscriber: taavi.

The GlobalBlocking extension can deal with a large amount of short-term blocks, and I haven't heard anyone complain about the logging table causing issues.

Is issuing thousands of global blocks per day now an accepted standard practice?

Apparently yes, and that something that should be discussed on meta and not here.

Should stewards on Meta-Wiki be making thousands of automated global blocks per day?

Yes, if the stewards believe that is the best way to deal with some kind of abuse.

Is the Wikimedia operations team okay with this practice?

See above, although I am not a member of the SRE team.

Should these blocks be handled by smarter software?

Depends on the details of that specific alternative.

Closing since I don't see anything actionable here.

In T303774#7775994, @Majavah wrote:

Closing since I don't see anything actionable here.

There's truly no need for such haste here.

In T303774#7775994, @Majavah wrote:

Is issuing thousands of global blocks per day now an accepted standard practice?

Apparently yes, and that something that should be discussed on meta and not here.

Where on Meta-Wiki would you suggest? Are there previous discussions on Meta-Wiki about stewards using their main accounts to run automated processes that make thousands of blocks per day? If so, could you please provide links?

Is the Wikimedia operations team okay with this practice?

See above, although I am not a member of the SRE team.

I'd like to see some acknowledgement of this practice from the SRE team, at least.

Closing since I don't see anything actionable here.

Do you think the current architecture—relying on volunteers to make thousands of blocks per day under their primary accounts—is sustainable and reasonable?

This is necessary mitigation for T265845.

Is issuing thousands of global blocks per day now an accepted standard practice?

Has been for a while.

Should stewards on Meta-Wiki be making thousands of automated global blocks per day?

Better than the alternative.

Is the Wikimedia operations team okay with this practice?

Haven't heard any complaints, they're certainly aware.

Should these blocks be handled by smarter software?

Ideally yes, but the WMF has largely not allocated resources for that. There has been some work in T290917, but it is unlikely to change the need for global blocks. T273220 will also help somewhat, but not in many cases.

Where on Meta-Wiki would you suggest?

https://meta.wikimedia.org/wiki/Stewards%27_noticeboard

Do you think the current architecture—relying on volunteers to make thousands of blocks per day under their primary accounts—is sustainable and reasonable?

We would be relying on volunteers to clean up if the blocks weren't made as well (at least what could be cleaned up).

In the future, I'd appreciate a ping if you're talking about me (since that is my grant proposal and my announcement). Bullseye is not used for this, though Bullseye and the tools used to block these proxies do share some data sources. Further details in T265845 (more importantly, no further details in a public ticket).

Hmm, have you asked stewards, as they might know best? :)

I mentioned it to them, yes. The stewards appear to be in a battle mentality against long-term abusers.

"Battle mentality" is quite uncalled for. These blocks were put into place (on enwiki originally, later also globally) due to sustained abuse from several extremely problematic LTAs that we simply could not deal with any other way.

It's kind of horrible to be making thousands of short blocks per day like this. The "flood" user group mitigates some of the impact, but relying on volunteers to make dozens of blocks per minute for hours every day seems like a pretty flawed design.

These are short-term blocks because the proxies in question are generally on dynamic IPs (and so people can't just hand out wide three-year blocks like we do for hosting providers and most VPN services).

I'm a volunteer and my IRC bot was working its way through a very large queue due to these blocks. Some user many years ago decided to stalk every action on Meta-Wiki in their private IRC channel. That's why I happened to notice and I'll fix the bot when the queue clears and then probably move on with my life.

I certainly appreciate the efforts that other volunteers, including stewards and admins, undertake to keep the projects safe from abuse. I understand that the relentless vandalism and other problematic edits are tiresome and draining to deal with.

This is necessary mitigation for T265845.

I don't have access to that task.

Should these blocks be handled by smarter software?

Ideally yes, but the WMF has largely not allocated resources for that. There has been some work in T290917, but it is unlikely to change the need for global blocks. T273220 will also help somewhat, but not in many cases.

Thank you for this info.

In the future, I'd appreciate a ping if you're talking about me (since that is my grant proposal and my announcement). Bullseye is not used for this, though Bullseye and the tools used to block these proxies do share some data sources. Further details in T265845 (more importantly, no further details in a public ticket).

You seem to have quickly subscribed to this task. :-) It's pretty difficult to figure out who's directing that these blocks be made and using what criteria. Perhaps intentionally, I'm not sure. Are you directing that these global blocks be made? Should affected users be reaching out to you since it's your grant proposal? The 50,000+ global blocks made on Meta-Wiki on March 14 are not directly attached to your account, of course. And the page linked in the block message (https://meta.wikimedia.org/wiki/No_open_proxies/P2P) makes no mention of you, Shodan, or Spur.

"Battle mentality" is quite uncalled for. These blocks were put into place (on enwiki originally, later also globally) due to sustained abuse from several extremely problematic LTAs that we simply could not deal with any other way.

So far this month on Meta-Wiki it looks like there have been 320,069 global blocks issued. That's quite a lot of blocks and they're not being made using a standard bot account and it's not clear what code or lists or systems are being used to make these blocks. Is it free and open source code? Could you please provide a link to it? It's also not clear whether making thousands of global blocks per day was discussed on Meta-Wiki anywhere. Was it?

I really want to ask: Why we does not have a bot to globally block known proxies? It may be meaningful to bring ST47ProxyBot and so on to global blocking known proxies.

Frankly, it is ridiculous to have a bot blocking proxies only locally - vandals would get a list of valid proxies and use it to vandalize other projects.

I really want to ask: Why we does not have a bot to globally block known proxies? It may be meaningful to bring ST47ProxyBot and so on to global blocking known proxies.

That's a good question. @Tks4Fish may know why we aren't using a dedicated bot account such as ST47ProxyBot on Meta-Wiki.

Frankly, it is ridiculous to have a bot blocking proxies only locally - vandals would get a list of valid proxies and use it to vandalize other projects.

Of course you could also take a slightly wider view and say that a list of global blocks on Wikimedia wikis provides a list of valid proxies to vandalize non-Wikimedia wikis. I'm not sure this is a reasonable concern.

Of course you could also take a slightly wider view and say that a list of global blocks on Wikimedia wikis provides a list of valid proxies to vandalize non-Wikimedia wikis. I'm not sure this is a reasonable concern.

This is not a concern with the type of proxy we're blocking and the way we're blocking it -- that's the best I can say publicly. And more broadly speaking, publicised lists of proxy exit IPs are likely to be substantially more useful to defenders than to attackers anyway.

That's a good question. @Tks4Fish may know why we aren't using a dedicated bot account such as ST47ProxyBot on Meta-Wiki.

Because there isn't a group that grants both globalblock and bot, so I use my account with flood, that gives myself bot

That's a good question. @Tks4Fish may know why we aren't using a dedicated bot account such as ST47ProxyBot on Meta-Wiki.

Because there isn't a group that grants both globalblock and bot, so I use my account with flood, that gives myself bot

This may mean we can create a new global user group for fully-automatic globally proxy blocking bots.

Historically, for whatever reason, that hasn't been done, and there are several examples of stewards using their own accounts for semi-auto or supervised auto global blocks and locks. I do think it's mostly been an expediency thing, and there's no statement in policy, guidelines, whatever, for or against the practice.

Global groups are managed directly by the stewards through Special:GlobalGroupPermissions. However, global blocking and locking are generally assigned to meta local groups, not global groups, to ensure that logs are centralized to meta.

Stang added a subscriber: Stang.

The stewards appear to be in a battle mentality against long-term abusers.

It's really a shame that phab doesn't allow the GIFs required to express how disappointing this sentence is.

Should these blocks be handled by smarter software?

Absolutely yes.
I use to block VPNs and I'd really don't like it.
Something like a SPUR subscription to gather IPs to be automatically blocked by Mediawiki would be great, humans' time should be devoted to more interesting things, or, at least, more sensitive ones, e.g. fixing the inevitable problems caused by automatic systems.

Something like a SPUR subscription to gather IPs to be automatically blocked by Mediawiki would be great, humans' time should be devoted to more interesting things, or, at least, more sensitive ones, e.g. fixing the inevitable problems caused by automatic systems.

This is already happening in a limited way, with a lot of (hopefully) improvement work in flight. See also T290917, though many of those tasks have been intentionally left a bit vague. There's also a protected task which discusses this issue in a lot more depth here: T265845 - though I think we still need to keep that protected for a bit longer. While Spur's (and other vendors') products do provide for a lot of incredibly valuable data, they can also exhibit Western bias and can be overly-aggressive in their aggregation. I believe you've also been active on the recent, lengthy wikimedia-l thread discussing some of these unintended consequences. I think all concerned parties are hoping to strike a fine balance here in enabling project contributors while keeping malicious actors away, but that can be an extremely difficult problem to solve in certain cases.