I think T17294: Allow globally blocking of accounts should be fixed instead.

In T340275#8960404, @Bugreporter wrote:

I think T17294: Allow globally blocking of accounts should be fixed instead.

^^. Furthermore, I think this should not be a Low priority. As of now, GlobalBlocking would be of very limited use once we switch to IP Masking everywhere, as it is capable of only blocking IP addresses (it isn't capable of blocking registered users, including temporary accounts). While we can globally lock registered accounts (both named and temporary), this is not effective, as temp account holder will be logged out and the system will gladly provide them with another temporary account.

To maintain current capabilities, we would need to be able to set global blocks that only apply to temporary accounts (curently soft blocks), and global blocks which also apply to logged-in users (hard blocks).

This also raises the question of how account creation blocks will work, which I don't know if there's a ticket for that yet. Optimally, setting account creation off would prevent anonymous editing but would allow people to make actual accounts. And setting account creation on would prevent anonymous editing and creating accounts.

Related: I have often been travelling, editing on mobile, and connected to the internet through a blocked IP range. In those cases, there was no way to edit or propose an edit or make an account.

It would be good to in those cases to have an semi-soft block option that allows proposing an edit that sits in its own queue for review, so that editors who care to can sift through the queue and assess what proportion of such edits are good/usable vs bad/spam. This would also allow slow-but-sometimes-possible editing over Tor.

In T340275#9102290, @Sj wrote:

Related: I have often been travelling, editing on mobile, and connected to the internet through a blocked IP range. In those cases, there was no way to edit or propose an edit or make an account.

It would be good to in those cases to have an semi-soft block option that allows proposing an edit that sits in its own queue for review, so that editors who care to can sift through the queue and assess what proportion of such edits are good/usable vs bad/spam. This would also allow slow-but-sometimes-possible editing over Tor.

See also Suggestor, a proposed (not yet deployed) tool that allows Tor users to suggest edits for review. There are multiple variants:

1. Approved edits are credited to the logged in account (only applies when the user is logged in)
2. Approved edits are credited to the proxy/Tor IP
3. Approved edits are attributed to users that review it (as T149961 proposed) with clearly indication that they are edits via that review system
4. Approved edits are attributed to users that review it without indication (so that they are not distinguishable with other edits of the reviewer)

I am personally opposing such a review system, for the following reasons:

• Variant 3 and 4 makes edits not tracable so there are no easy way to prevent users from abusing the review system. Variant 2 does but proxies can be easily changed
• This make users able to circumvent local or global santions (such as WMF bans); Many edits looks good though they are actually disruptive, and this is why ban exists

Alternatively we can introduce a new type of (local and global) IP block between soft and hard one - one will only block non-confirmed users. This is proposed in T323948: Blocking all non-confirmed users on an IP or IP range (aka range block against sleeper accounts).

Note changing the current No Open Proxy policy to this new type of block will require a global RFC.

Please don't blanket-oppose such a review system, just help make it good :) I'm not sure how variant 3 supports abuse, any more than those reviewing editors could already make such edits themselves.

I would certainly be able to work with a semi-soft block. As it's possible to assign confirmed flags to new accounts, a variation could also allow running editing workshops through such blocked ranges. [schools often being subject to such blocks]

In T340275#9129585, @Sj wrote:

I would certainly be able to work with a semi-soft block. As it's possible to assign confirmed flags to new accounts, a variation could also allow running editing workshops through such blocked ranges. [schools often being subject to such blocks]

It's best to just request IPBE if you're traveling and on blocked ranges. Making some special block option that is effectively more-complicated FlaggedRevs is...something that would require a ton of work, would have questionable impact, difficult to patrol, etc.

Also, this should probably be discussed on another ticket :p

Also, this should probably be discussed on another ticket :p

Please discuss such idea at T323948: Blocking all non-confirmed users on an IP or IP range (aka range block against sleeper accounts).

In T340275#8960404, @Bugreporter wrote:

I think T17294: Allow globally blocking of accounts should be fixed instead.

Quick update - we are discussing this actively and there is a good chance we will end up working on T17294: Allow globally blocking of accounts instead of this task. I will have another update within a couple of weeks. Thanks all for the helpful comments.

In T340275#9143053, @Niharika wrote:

In T340275#8960404, @Bugreporter wrote:

I think T17294: Allow globally blocking of accounts should be fixed instead.

Quick update - we are discussing this actively and there is a good chance we will end up working on T17294: Allow globally blocking of accounts instead of this task. I will have another update within a couple of weeks. Thanks all for the helpful comments.

I'm realizing now that this ticket was made to allow global blocks to be placed against temporary accounts...which might as well be all accounts.

What seems to me to be a larger problem is that, at present, there would not be a way to distinguish global soft blocks and hard blocks. Everything would need to be a hard block because only accounts exist. This is unless autocreation of temporary accounts would be prevented by global blocks, in which case soft blocks would actually prevent anonymous editing by preventing creation of temp accounts. However, this would not affect already-created temporary accounts, which is a problem.