[Wikimedia-l] Re: Open proxies and IP blocking
(cross-posted from https://meta.wikimedia.org/wiki/Talk:No_open_proxies/Unfair_blocking#Help_from_WMF) 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
[Wikimedia-l] Re: Open proxies and IP blocking
I've been getting really helpful replies both here and in the Meta discussion, thank you very much. I'm going to summarize what I'm seeing so far, and ask some new questions. One thing that's come up is that there are many kinds of good-faith people who experience collateral damage from the current practice — people in Africa and South/Southeast Asia who are automatically in proxies thanks to their ISP (the folks who started the conversation), and also people who live in countries where contributors risk harassment or legal action, including queer editors who live in countries where queer sexualities are criminalized. Right now, I'm thinking about the different kinds of "pain" involved on all sides. Just for the sake of this conversation, I'm using the word "pain" to mean something that's frustrating, time-consuming, dangerous, obstructive, or otherwise negative. Admins & stewards who spend all of their free time trying to block IP-hopping abusers experience "pain", users who get doxxed or harassed by IP-hopping abusers experience "pain", organizers with editathon participants getting blocked experience "pain", editors who are blocked from contributing experience "pain". So: is this a zero-sum game, where one group's pain relief = another group's pain point? Right now, I think the expansion of proxy blocks since last year has been reducing the pain for vandal/abuse fighters, which has increased the pain for good-faith users (especially in Africa/South Asia). For stewards, it may have just shifted the work: less work blocking the vandals, but more work granting block exemptions. If it's a zero-sum game, then we're trying to find an acceptable balance among these groups, which is difficult and makes everyone unhappy. I'm hoping there are things that we can change in the software that make this more of a non-zero-sum game, so that relieving pain for one group doesn't increase it for someone else. The ideas so far break down into two categories: #1) making proxy blocks less frequent or more nuanced so that we don't need an unblocking request process, and #2) making the unblocking request process easier or more efficient. The IPBE process is kind of the pivot point in the problem. From a software design perspective, the fact that IPBE even exists is a failure state — we're not doing our job properly making a website that anyone can edit, if good-faith people are blocked and other good-faith people are spending time unblocking them. So the ideal solutions would be focused on #1, because if we solve those, #2 doesn't exist anymore. Here are some of the ideas suggested so far: Category #1: Making proxy blocks less frequent, or more nuanced * Instead of auto-blocking, wait for someone to vandalize before blocking that open proxy * Tag edits made through open proxies, so that admins can give them more scrutiny * Throttle edits made through open proxies, to discourage vandals (and good-faith people) * For Apple's Private Relay, rangeblock the regions where vandalism is coming from rather than blocking the whole service * Treat ISPs in Africa, South Asia and Southeast Asia that use carrier-grade NAT differently, instead of making them auto-blocked open proxies Category #2: Making the IPBE process easier, or more efficient * Make the local/global distinction easier to understand and navigate by signaling to users that they've got a local or global block, and guiding them in the right direction * Let trusted users like campaign organizers submit lists of accounts to be automatically exempt (but obviously blockable if those accounts are used badly) Are there other suggestions for either category? What have I missed? One thing I'm curious about: for the "treat ISPs in Africa/South Asia differently" idea — would people in other regions be able to abuse those services? Would a bad actor in Europe be able to make edits through an unblocked ISP in Ghana? Also: What happens if the open-proxy block only applies to anon edits, and allows edits from people with accounts? I know that the basic answer is "then the bad-faith people create accounts, so there's no point" — but does that at least reduce the amount of "pain"/damage to a more acceptable level? I'd also like to know what happens if a wiki chooses to block all unregistered edits, like Portuguese WP and Farsi WP are doing right now? Would we still need to auto-block open proxies, if there was no more anonymous editing at all? I'm not suggesting that as a solution right now; I just want to understand what the impact would be. Thanks for your thoughts and ideas. DannyH, aka Danny Horn (WMF) ___ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at
[Wikimedia-l] Re: Open proxies and IP blocking
Paulo, you're right — I'm sorry, I shouldn't use "anonymous" to describe unregistered editing. I misspoke on that. Danny ___ Wikimedia-l mailing list -- wikimedia-l@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/message/IVU5U5FIUB45MVLKXHHETSPK56X4POQX/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
