Jump to content

Community Wishlist Survey 2023/Anti-harassment/Mitigate the damage caused by proxy blocks

From Meta, a Wikimedia project coordination wiki

Mitigate the damage caused by proxy blocks

  • Problem: Most English Wikipedia administrators live in developed countries; as a consequence, the blocking practices that have evolved are ones that work well for the internet infrastructure of developed countries, but much less so for developing countries. Specifically: 1) by the time the internet became mainstream in many developing countries, most IPv4 addresses have been reserved by richer countries, so in these countries it's common that many internet users have to share the same IP address (cgNAT), so blocks cause large-scale collaborative damage. 2) Wikipedia users in oppressive countries often need to use IP hiding services (Tor, open proxies, VPN etc) to remain safe, but these services share the same IP addresses between their users and can be weaponized by vandals, which means they tend to be blocked preemptively.
    The same can be said about mobile users as well to some extent: patterns of IP reuse are increasingly more common (see e.g. iCloud and T-Mobile), but because mobile use among developed-country power users and admins is low, the blocking practices that emerged are disruptive for mobile users.
    More information on the topic can be found on Talk:No open proxies/Unfair blocking and Diff's series of posts on the topic: [1], [2], [3]
  • Proposed solution: I think we are still in an exploratory phase with this problem, plus many potential solutions are too large for the wishlist, so it's best to leave to Community Tech to identify things they can do.
  • Who would benefit: Users who are forced to use proxies for their safety, users in less privileged countries who only have access to ISPs with proxy-like behavior, possibly mobile users.
  • More comments:
  • Phabricator tickets:
  • Proposer: Tgr (talk) 07:22, 1 February 2023 (UTC)[reply]

Discussion

  • I don't want to completely dodge the "what can we do" question, so here are some ideas (although there are probably better options, and quite likely we haven't found all of them yet):
    • Improve the usability and accessibility of notifications about / explanations of proxy blocks, and make it easier for users to request exemptions. (E.g. T243863, T265812)
    • Some sort of peer-to-peer exemption systems where users "in good standing" can exempt other users from proxy blocks (related: T189362).
    • Some kind of "proof of work" system where a user can spend some time to bypass a proxy block.
    • An exemption request system that lets you tie your request to your established internet identity (e.g. social media accounts) so it is easier to identify well-meaning users.
    • Make it easier to exempt editathon participants from range blocks, e.g. via T27000.
    --Tgr (talk) 07:22, 1 February 2023 (UTC)[reply]
  • A lot more could/should be done to prevent vandalism before blocking anon users by their IP address. Most vandals are not very sophisticated, so session/cookie based blocks should work for them, if made possible. Throttle: 3 edits in 10 minutes, 10 edits in 1 hour? Obligatory captcha for IPs after 3 edits. Short automatic block for obvious vandalisms (repeated c&p, ALL CAPS, emojis). Obligatory answer to "How did you improve this article". Know your enemy, WMF! The little measures that I mentioned are (of course) all circumventable, but do lead to measurable reduction of vandalism. Too restrictive? I think it's way more restrictive to block entire networks of some big internet providers – which is what sysops and stewards are manually doing now, plus 2o ooo en wiki bot blocks per day. ponor (talk) 10:59, 1 February 2023 (UTC)[reply]
  • @Tgr: I wonder if the IP Masking project might solve some of these problems, particularly of collateral when blocking IPs. This proposal is likely to be too big for Community Tech, but is a good candidate for the larger suggestions category. Unless you want to limit the scope of this proposal to something more discrete and manageable. DWalden (WMF) (talk) 14:16, 1 February 2023 (UTC)[reply]
    @DWalden (WMF) I figured CommTech could pick themselves something that they feel is appropriately sized - I think at this point what we have for improving the proxy block situation is a bucket of independent improvements (some large, some small) rather than a single block of work, so there is a lot of wiggle room in defining the scope. Deciding what's the most useful / feasible to work on would take some amount of research itself, that's why I figured it's better not to try to specify it as part of the wish (the guide suggests that's OK). I can try to turn the wish into something more concrete if that's preferred. Tgr (talk) 20:08, 1 February 2023 (UTC)[reply]
  • On enwiki I usually just refer the many unblock requests of this sort to WP:IPECPROXY where they can request IPBE. Do other wikis have this page or its equivalent? Daniel Case (talk) 06:08, 2 February 2023 (UTC)[reply]
    They can request it but do they actually get it? AIUI the process sometimes takes weeks due to the size of the backlog, it involves you writing an email to an unknown person and having to justify yourself (which, if e.g. you are using a proxy to circumvent a Wikipedia ban in an oppressive regime, is not the most comfortable thing to do - what are you going to say? how much you can trust the random anonymous volunteers at the other end of the email address?), and I don't think it's common for other wikis to have even that much. It's better than nothing (and more clearly exposing it to users is one of the things CommTech might be able to do) but not great. Tgr (talk) 03:01, 5 February 2023 (UTC)[reply]
    Yeah, I think some users just don't want to deal with it. One flatly told me he didn't want his email address to be able to be so easily connected to his account. We need something that works better for these users. Daniel Case (talk) 03:21, 16 February 2023 (UTC)[reply]
  • I think this actually is the result of a larger and probably not easy to solve problem: MediaWiki still relying mainly on IP addresses & Co. for vandalism/abuse prevention and sockpuppet detection, so NOP became necessary. If MediaWiki could rely on something different (what: I don't know) to handle vandalism/abuse/sockpuppet detection/prevention I feel proxy blocking would perhaps no longer be needed, or not that much maybe. Apologies for any inexactitude, as I'm not really "techy". —MarcoAurelio (talk) 11:05, 6 February 2023 (UTC)[reply]
  • Maybe unrelated, but now, as default, autopatrollers or approved bot are automatically blocked, even if they are logged-in, when their origin is from an IP range block. To me, this is a bug in good faith, since there is no consensus, and there is not any strong benefit, in blocking these trusted logged-in users (and maybe other trusted roles). phabricator:T309328 --Valerio Bozzolan (talk) 20:38, 6 February 2023 (UTC)[reply]
  • See also phab:T309328. In my opinion what is better is allow IPs or ranges to be (locally or globally) "semi-blocked", which is to block with (auto)confirmed users exempted. This will be a level between soft (anon-only) and hard (all non-IPBE) block, and will be applied to most open proxies.--GZWDer (talk) 23:09, 8 February 2023 (UTC)[reply]
  • Please see also Explore evasion methods of state-level censorship across Wikimedia movement. --Diskdance (talk) 15:08, 13 February 2023 (UTC)[reply]
  • I don't know the technical details, but maybe for those who use 2FA automatically allow the use of VPNs and proxies without changing the IP blocking of these services. --Klip game (talk) 08:53, 16 February 2023 (UTC)[reply]

Voting