Den lör 30 apr. 2022 kl 09:37 skrev effe iets anders <
effeietsanders(a)gmail.com>gt;:
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_M…
//Johan Jönsson
--