Den lör 30 apr. 2022 kl 09:37 skrev effe iets anders <>:

> 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:

//Johan Jönsson
Wikimedia-l mailing list --, guidelines at: and
Public archives at
To unsubscribe send an email to

Reply via email to