Den lör 30 apr. 2022 kl 09:37 skrev effe iets anders <effeietsanders@gmail.com>:
Hi Danny,

this is great thinking. There's one more angle that I'd like to offer, but it would come with plenty of risks and downsides, so I'm not sure if it is actually viable (I guess it falls in the 'mitigate harm' category). But just to put it out there:

One of the main reasons that we block open proxies, is because of sockpuppets and block evaders. What if we would somehow expose to admins which edits are made by open proxy? That way they can consider the entire picture (including a history of good faith edits) before blocking their edits. Down the road, that flag could become more nuanced (open proxy vs shared connection) but obviously it would have to remain pretty broad categories. There are plenty of downsides (WMF would need to keep a database of open proxies for one, but it would also share a small piece of private information about the user - we could warn them about that as they are saving their edit). 

If we are afraid primarily for rapid open proxy edits, we could use a tactic that is used by some social media tech companies in other settings: slow them down when using an identified open proxy. If we build in a 30s throttle or even wait time before the edit can be saved, or a 5 minute delay before the edit can become visible, that would take the fun out of it possibly. Obvious downside is that this is still annoying as hell for good faith users, but at least they can now request exceptions on-wiki. 

This family of methods risks a two class community, but I'm not sure if that is worse than the current situation. I'm not sure what would be the 'right' path either.

Relevant in this context:
https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation/IP_Info_feature

//Johan Jönsson
--