"*if a wiki chooses to block all unregistered edits (...) w**ould we still need to auto-block open proxies, if there was no more anonymous editing at all?*"
Please don't use the term "anonymous" to refer to IP edits, which are anything but anonymous. The only edits with a minimum level of anonymity are precisely those made by registered users. One of the reasons we blocked IP editing on pt.wiki was exactly because editors using IP addresses were being traced, identified, and harassed. Best, Paulo <dh...@wikimedia.org> escreveu no dia terça, 3/05/2022 à(s) 02:31: > 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 > https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/TNMMK5HEQQ3H4MSLEPXV72LI567OIJPB/ > To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
_______________________________________________ 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/O2KMGSQV4R5MD5YSBRCJU2CQJC53ADFO/ To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
