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.
Lodewijk
On Fri, Apr 29, 2022 at 5:03 PM <dhorn(a)wikimedia.org> wrote:
(cross-posted from
https://meta.wikimedia.org/wiki/Talk:No_open_proxies/Unfair_blocking#Help_f…
)
Hi folks, I'm DannyH from the Wikimedia Foundation. I manage the product
teams that build Contributor Tools -- Community Tech, Campaigns, CheckUser
improvements and sockpuppet detection, moderator tools on mobile web, and
the new incident reporting system.
I've been reading all of these conversations, and I'm concerned about the
people on both sides of the issue -- the admins working to keep the
projects safe from bad-faith people, and the good-faith people who are
being blocked because of someone else's rangeblock, or because they're
using default network proxy features that they're not aware of.
This problem is getting attention within the WMF. Foundation folks are
really concerned about what we're hearing on Wikimedia-L and in this
discussion, especially because there seem to be systemic issues that are
specifically making things harder for new users in Africa. I've got the
opportunity right now to assign people to make software changes to help
solve this problem, which is great. But now I'm trying to figure out what
those software changes could be, and I don't have a clear answer yet for
what that should be.
So if you don't mind, I'd like to run through what I think the main
points are, and a list of possible directions that a solution could take,
and then I would love it if you could help me figure this out.
Here's what I understand about the problem:
* Open proxies are a vector for harassment and vandalism. Bad-faith long
term abusers use them to disguise their IP and evade detection. The
projects automatically block open proxies that they know about, to
discourage the bad-faith vandals.
* There's been a big increase in proxy blocks since July 2021 on English
Wikipedia (and Oct 2021 on Spanish WP), because ST47ProxyBot has been
getting trustworthy outside data to help identify open proxies.
* The use of open proxies on the internet is rising, partly because
people are becoming more concerned about their privacy. Apple has
introduced iCloud Private Relay, which is disguising people's IP — this is
currently in beta, but will probably become the default. Google is working
on a similar project. Our system of using IPs to identify block vandals is
gradually breaking down, and there will probably be a point when IPs just
won't be useful anymore.
* There are a lot of good-faith users, including first-time contributors,
who are getting caught in these blocks. For some people, that's an annoying
inconvenience; for many others, especially brand new people, it drives them
away completely.
* There appears to be a systemic issue with how some African ISPs deal
with IP addresses, which is creating a lot of collateral damage in places
where campaign organizers are trying to introduce new users to wiki
contribution. I saw one person mention that the problem was especially bad
in Ghana and Benin.
* The messages that people get when they're blocked are confusing,
especially for new people. They only get the message after they've made an
edit and are trying to publish, which is very frustrating.
* The solution for individuals is to request an IP Block Exemption, which
can be either local or global, depending on whether the block is local or
global. The local/global distinction is very confusing for people who are
trying to make the request, and the whole process is difficult.
* Each request has to be processed by hand, and the system gets backed
up. It's possible to get unblocked quickly if you know the right person to
email, but a lot of people just fill out the request, and then wait for who
knows how long.
* It's possible for admins/stewards to get overwhelmed by the number of
unblock requests.
That's a cluster of many different problems, so now I'm trying to figure
out which problems we could actually make progress on.
Possibilities include:
* Mitigate the harm coming from open proxies, so we don't need to
automatically block them
* Understand the difference between a "dangerous" open proxy (which
bad-faith people are actually using) and a more "innocent" proxy (which is
just blocked because we know it's a proxy), and then treat them
differently. (If it's possible to make that distinction.)
* Make the messages to good-faith people more helpful and less frustrating
* Make the unblock request process easier/faster/more friendly for the
people making requests
* Make the unblock request process easier for the people responding, so
they can process them faster (or involve more people who can help)
* Make it easier for good-faith people to get some kind of automatic
exemption
* Make it easier for campaign and editathon organizers to whitelist their
participants
* Adapt the system better to the reality of African ISPs — figure out
what the problem is, and treat those ISPs differently
That's a lot, and it's not clear to me what the path forward should be.
Can folks help me out? What did I get wrong here, or what did I miss?
Thanks in advance for your help.
DannyH (WMF)
aka Danny Horn, Director of Product Management, Contributor Tools
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
at: