Talk:No open proxies/Unfair blocking

Context

In February 2004, the decision was made to block open proxies on Meta and all other Wikimedia projects.

According to the no open proxies policy : Publicly available proxies (including paid proxies) may be blocked for any period at any time. While this may affect legitimate users, they are not the intended targets and may freely use proxies until those are blocked [...]

Non-static IP addresses or hosts that are otherwise not permanent proxies should typically be blocked for a shorter period of time, as it is likely the IP address will eventually be transferred or dynamically reassigned, or the open proxy closed. Once closed, the IP address should be unblocked.

According to the policy page, « the Editors can be permitted to edit by way of an open proxy with the IP block exempt flag. This is granted on local projects by administrators and globally by stewards. »

The policy page suggests that, should a person be unfairly blocked, it is recommended

• to privately email stewardswikimedia.org.
• or alternatively, to post a request, if able to edit it, if the editor doesn't mind sharing their IP (for global blocks) or their reasons to desire privacy (for Tor usage).
• the current message displayed to the blocked editor also suggest contacting Tks4Fish. This editor is involved in vandalism fighting and is probably the user blocking open proxies IPs the most See log.

What the problem is

1. Over time, the number of users reporting being blocked for using open proxies has been increasing. This particularly affects African editors and is becoming a REAL issue to this community.
2. Blocks affect all types of editors, from the complete newcomers to more experienced veterans. There is no automated system to have old timers automatically protected from such blocks.
3. Blocks regularly impact edit-a-thons, photo hunts, upload sessions etc. disrupting the activities organized by the project leaders and exhausting everyone's goodwill.
4. For most users and in particular new participants, the guidelines offered to request unblocking are confusing at best. Most people actually have no idea what an open proxy is... Also, many editors do not understand what they should be doing. For example, consider the instructions to make a request here... most editors simply freak out reading the instructions.
5. As a consequence, most blocked editors simply call for help from other editors, on social media channels, mailing lists or by email. Those other editors can not help unblock, thus further causing unhappiness and frustration to all involved parties.
6. Some blocked editors follow the recommended route, writing to stewards to get unblocked. Many of those editors report receiving no answer whatsoever from the stewards (when several people are blocked PER DAY, it certainly put undue pressure on the stewards)
7. Unblocking, however, can and will eventually occur, often after much effort.

The situation has been getting worse in 2021 and 2022 and is in particular impacting a segment of our community which is struggling to participate for various reasons. We believe the situation has become serious and that the process by which the blocking of open proxies is implemented, or the process to get blocked editors unblocked, should be reviewed and improved.

History of some complains/reports recorded after IP blocking

• 12 mars 2022: w:fr:Special:PermaLink/191836109#Deblocage d'adresse ip et exemption de compte de blocage

  involved: w:fr:User talk:Adù229 (autopatroller)

• 12 mars 2022: w:fr:Special:PermaLink/191836122#Ip address global wikimedia block et exemption de blocage

  involved: w:fr:User talk:Adoscam (autopatroller)

I have been affected by open proxy blocking

List your name and explain how you were impacted (you were blocked / you organized an event where people were blocked / you were contacted by blocked editors asking for help etc.)

1. Aboubacarkhoraa - république de Guinée,depuis quelques mois des bénévoles qui ne sont pas de la même ville ont commencé à me signaler qu'il sont bloqué à cause d'un proxy ouvert. Mais il disent ne pas utilisé de proxy. Des cas de nouveaux éditeurs qui ont leurs IP bloqué avant même la création de leurs compte Wikipédia. Ce qui représente une vrai menace car une personne qui a déjà peur des nouvelles technologies ou pense que seul les génies peuvent continuer à Wikipédia. S'il est bloqué des ses premières pa, il risque de fuire et faire fuire d'autres contributeurs si chère à convaincre déjà. Aboubacarkhoraa (talk) 05:37, 14 April 2022 (UTC)
2. Amuzujoe is my user name and I am from Ghana, the IP block has become a very big issue for me lately, I contribute using my phone and my laptop. Ever since this IP block came it has affect me in such a way that I have to be asking for IP block exemption which I think isn’t good for us contributor’s in the wiki space. It the same reason and same action for the block. You can have a look at image on my contribution page with the name “IP Blocked_01”. I am contributing images to “Wiki Loves Africa” and the block on my IP has slowed my upload using the phone which is mobile. This has affected me immensely and i will be very happy is I am exempted forever. I have some photos to upload and will be glad to be exempted. Amuzujoe (talk) 05:50, 14 April 2022 (UTC)
3. Onyinyeonuoha is my user name. My IP's have been blocked repeated from uploading to Commons with my phone and my laptop. Ever since this IP block came it has affect me in such a way that I have to be asking for IP block exemption which I think isn’t good for us contributor/Facilitor in Wikipedia. I am contributing pictures to “Wiki Loves Africa” , I still have over 500 pictures to contribute, this issue si frustrating me, the block on my IP has slowed my upload using the phone which is mobile. This has affected me immensely and i will be very happy is I am exempted forever. Onyinye Achukwu (talk) 08:29, 14 April 2022 (UTC)
4. Ip blocking as made me give up on editing. Kojodavid (talk) 07:59, 14 April 2022 (UTC)
5. I have not been blocked, but every week I see a message of an editor I know reporting himself blocked. I get contacted all the time by people complaining, either that they were just blocked, or that their request for unblocking to the stewards or others is going nowhere. Last week-end, no less than 3 people contacted me privately to ask me for help unblocking them. I started this page because I believe the situation is not acceptable. Anthere (talk) 09:05, 14 April 2022 (UTC)
6. I have been blocked and this affected my access to my project bage i was not able to update the meta and it is up to know i dont see any respond from the email i sent and it was not clear at all what i should be do more to be unbloked and the if iam not part of the commmunity grop on telgram it could have been impossible to unblocked myself and it also confused me with the cost of the internt in my country Ola.mahadi (talk) 12:08, 14 April 2022 (UTC)
7. I have organized a lot of training for very new people who even at the point of account registration suffer an IP block. The disappointment is always huge and loud because from the onset the person feels he is not welcomed and would join Wikipedia in total fear of getting block. There were times, I will travel of 300 miles from home to a new location to train people about how they can contribute on wikipedia and would be blocked... Which was totally unfair and very rude because the claim will just be open proxies. Another time, myself and some friends bought a router from our hard earned savings to aid edit wikipedia and the first day we got connected, we were blocked again. It took chains of explanation from each one of us to get global IP block exemption. Though the stewards or admins are doing their job but frankly they judge people wrongly. Dnshitobu (talk) 09:32, 14 April 2022 (UTC)
8. Les sans pagEs are continuously sollicited to tackle problems linked to the organization of edithatons in Africa (there is an active group of les sans pagEs in Bénin and one emmergieng in Cameroun) and cannot help efficientlly contributors to settle these problems. These contributors feel they are being treaten unfairly and that their efforts to train new contributors is hindered by constant management of requesting to be unblocked because of that policy. This is time consuming for people trying to provide help to them as well, and frustrating as no long term solution is being proposed. So I am posting here on behalf of the francophone UG les sans pagEs to request help to solve the problem within a reasonnable time frameNattes à chat (talk) 09:52, 14 April 2022 (UTC)
9. Le problème de blocage est récurrent au Bénin comme dans certains pays d’Afrique. Cette une situation qui sabote nos efforts pour rassembler la communauté autour du mouvement que cela soit au cours de Edit-a-t-on et de campagne. Nous souhaiterions qu’une solution définitive soit trouvée à cette situation qui est une grande cause de démotivation des personnes qui rejoignent la communauté au Bénin.--Adoscam (talk) 10:19, 14 April 2022 (UTC) ̪(Translation in English ː The problem of blocking is recurrent in Benin as in some African countries. This situation sabotages our efforts to gather the community around the movement, whether during Edit-a-on or during the campaign. We would like to find a definitive solution to this situation which is a great cause of demotivation of people who join the community in Benin.)
10. Adù229 is my username and I am from Bénin. I joined wikipedia in March 2022. From the very first day one my IP address was blocked. Since then, I have been blocked quite a number of times. I am very motivated to contribute to wikimedia projects, especially wikipedia and wikidata. These untimely blocks are a real brake. I contribute to wikipedia because I am exempt from IP blocking. This is not the case for other projects. Thank you for your help! --Adù229 (talk) 12:36, 14 April 2022 (UTC)
11. Robertjamal12 is my username, and I’m from Ghana. I am a Wikimedia projects editor, a recruiter and trainer for new editors and a formal program lead for Wikimedia Ghana User Group’s Community Development Program, which looks to improve the retention rate of new and experienced editors. IP blocks in Ghana now are absurd. Recruiting new editors is stressful because new editors are consistently blocked from creating accounts or editing, and trusted users are always victims of an open proxy, which they know nothing about. Organizers in Ghana go through much stress to pull off events. Most newbies lose interest in editing after leaving events because they can’t even log in to edit. This is unacceptable Robertjamal12 ~🔔 13:15, 14 April 2022 (UTC)
12. Alhassan Peter (talk) 19:43, 14 April 2022 (UTC)is my name and I am a wikipedia editor, and currently I have been block for open proxy which I know nothing about. I was only adding wikidata items when I was blocked.
13. I've been affected by this IP block and it's not a funny experience. Few hours to the start of our WikiGap I was trying to add a realist to the Igbo Wikiquote and I got an IP block. I was frustrated because as a community leader, it was an important event for my community and also as a WiR, I had another event the same day. I had to seek help from the global Wiki Community before I got an IP exempt. The second incident was while training participants in the African Leadership Academy, few minutes into the training, their IP was blocked by Tk4Fish. A lot of people in my community keep complaining and I'm beginning to feel like it's targeted at the African Community.
14. This should be looked into please. --Tochiprecious (talk) 17:11, 15 April 2022 (UTC)
15. Mwintirew (talk) 15:14, 19 April 2022 (UTC) -I had to train new volunteers to edit on Wikipedia. However when I logged into my account to demonstrate creating an artcle, I received a notification about an IP block. I tried to use my sandbox and that was affected too. Another incident was when I was trying to upload some images to commons. This challenge has really affected our edit-a-thon events.
16. C'est lors d'un éditathon début avril 2022 à Abidjan (Côte d'Ivoire) que j'ai constaté que j'avais été bloqué pour environ une semaine. Je n'ai pu donc contribuer. Ce même jour, 3 autres contributeurs participants à l'éditathon subissaient le même sort au point de ne pouvoir également participer. Quelques semaines auparavant, plusieurs éditeurs du User Group de Côte d'Ivoire nous avaient alerté sur des cas similaires. Au moment où j'écris, une autre contributrice vient de signaler son blocage pour le même motif d'open proxy...La situation devient intenable et ressemble à un acharnement sous le prétexte d'une règle technique. Ce qui est contraire à la vision de la stratégie 2030 qui postule plus d'inclusion et d'ouverture aux communautés émergeantes. Papischou (talk) 08:11, 20 April 2022 (UTC)
17. Après un téléversement sur Commons dans le mois de Mars, j'actualise la page et je constate que je suis bloqué pour une semaine pour le motif d'open proxy. j'étais donc surpris de voir mon compte bloqué et je n'ai donc pu continuer mon téléversement. Le même problème s'est présenté dans le mois d'Avril .Je trouve cela un peu accentuer car cette manière de faire ralentie le taux de contribution sur l'encyclopédie Didierwiki (talk) 12:04, 20 April 2022 (UTC)
18. WMF QA engineers have been affected by blocks several times in the past year: [1] [2] [3] (sorry, these links are not public, I can share details on request). It's only a small inconvenience, as WMF employees can avoid blocks by using the office VPN, but I wanted to share another example. Matma Rex (talk) 21:47, 20 April 2022 (UTC)

    To be fair, without looking into the specific case this complain makes no sense. There are several reasons for blocks, for example, T-Mobile is blocked because of massive abuse but its side effects must be mitigated more than side effects of NordVPN block, given that NordVPN subscribers can seamlessly circumvent the block. Vituzzu (talk) 06:00, 21 April 2022 (UTC)

19. My IP Address was blocked and I am not sure of the policy violated. I probably used an office laptop with VPN enabled, however I turned it off and still had same issue. I will appreciate if I am exempted. My name is Smart Olawale. Drsmartofficial (talk) 08:36, 21 April 2022 (UTC)

    VPN blocks stop affecting you as soon as you turn VPN off. Otherwise write to stewardswikimedia · org Vituzzu (talk) 08:38, 21 April 2022 (UTC)

    Note this is not always the case, see No open proxies/P2P. If a user runs a P2P proxy, their real IP becomes an open proxy itself. This IP may be blocked automatically, and the block will last for a few days after the proxy is disabled. However, without knowing the exact IP, I can't say if this is the case here, but stewards can help. MarioGom (talk) 16:40, 21 April 2022 (UTC)

20. I was on someone else's phone on the local mobile network in the US, and wanted to make an edit without logging in. The mobile network was blocked and I was unable to work around it via proxies or other solutions. I was also not able to help them make a new account to edit for the same reason. –SJ talk  17:48, 21 April 2022 (UTC)

    Sj: What was the reason for the block? Was it a T-Mobile block? An open proxy block? MarioGom (talk) 18:13, 21 April 2022 (UTC)

    It happened twice in the past month. Once was a T-Mobile block, once appeared to be an open proxy block (I don't know why that would be, afaik the browser/phone was not actively using a proxy). In both cases there was no way to leave a comment noting the desired edit that I could later review and approve once again logged in. The fact of the block, and the massive, multiple, somewhat unhelpful banners, seemed excessive in a few dimensions. –SJ talk  18:37, 21 April 2022 (UTC)

21. I can edit when my HTTP requests reach Wikimedia servers through IPv4, I can't when they go through IPv6, something I can't influence as I don't run the network. This differs from one request to the next, so other than my home wiki (on which I have an ipblockexempt status) I can't contribute reliably. Ironically this also happened this afternoon when I tried to leave this same message. I can probably request a global ipblockexempt status, but I refuse to do so on the grounds that the block is unreasonable, and my contributions are apparently unwanted. –Frank Geerlings (talk) 22:09, 21 April 2022 (UTC)

    Do you use a tunnel breaker? Vituzzu (talk) 06:35, 22 April 2022 (UTC)

    Yes, the network I am on uses a tunnel broker. –Frank Geerlings (talk) 22:37, 25 April 2022 (UTC)

    Frank Geerlings: These blocks are unlikely to be related to your contributions, but related to activity from certain IPs. Could you cite the exact reason you get in the block message? MarioGom (talk) 07:05, 22 April 2022 (UTC)

    The message is "2001:470:0:0:0:0:0:0/32, you have been blocked by ‪RadiX‬ until 04:10, 4 September 2022, because: Open proxy/Webhost: See the help page if you are affected: Should you be affected by this block, please contact us.."

    To be clear, I don't really mind I am blocked because I know the reason and I know how I could theoretically fix it by bothering a steward. I am also trying not to complain, I am just stating that people like myself won't contribute if these artificial hurdles are in place. That said, I wouldn't mind being unblocked either. :) –Frank Geerlings (talk) 22:43, 25 April 2022 (UTC)

22. Je suis Aristidek5maya, contributeur actif et Responsable projet Wikimedia au sein du Groupe d'utilisateurs Wikimedia Côte d'Ivoire. j'ai été également victime de ce genre de blocage plusieurs fois en essayant de contribuer sur des projets Wikimédia. Celà a commencé en Août 2021 lors d'un atelier Wikipédia que je pilotais à l'intérieur du pays. Ce jour-là , je n'ai pas pu, à cause des blocages, créer les comptes de plusieurs participants à l'atelier. Et même pour les quelques participants dont j'ai pu créer les comptes, ces derniers n'ont pas pu avancer dans leur apprentissage en faisant des modifications d'articles, parcequ'ils avaient été bloqués à peine leurs comptes créés. J'ai ensuite constaté les jours suivants que lorsque j'essayais moi-même de travailler sur les projets Wikimédia, le problème de blocage perdurait, m'empêchant ainsi de faire des contributions.
    Enfin, j'ai rencontré le même problème de blocage dans les mois de Janvier et février 2022 lors d'ateliers Wikipédia que j'ai animé dans une ville de l'intérieur du pays. Non seulement je ne pouvais plus travailler sur les projets Wikimédia durant les deux (2) ou trois(3) semaines (délai de blocage fixé par le proxy) qui ont suivi les ateliers, mais aussi des participants ayant participés aux ateliers écopaient de la même "sanction".
    Je pense que ce problème doit être résolu le plus rapidement possible, car non seulement, celà n'encourage pas l'inclusion des nouveaux contributeurs dans le Mouvement, mais aussi celà empêche les contributeurs actifs et les organisateurs d'événements ou edit-a-thons d'être plus productifs en termes de résultats. --Aristidek5maya (talk) 22:51, 21 April 2022 (UTC)
23. I have been blocked for open proxy even though I am on a personal network. I am interested in contributing to Wikidata and Wikimedia projects and hope to be unblocked to enable future contributions. Heatrave (talk) 20:26, 22 April 2022 (UTC)

    Heatrave: Please, see the instructions at No open proxies. MarioGom (talk) 10:33, 23 April 2022 (UTC)

24. Hello Zend2020 is my username s my username, I have been blocked several times even to the point that I felt I indeed had open proxies. I even had an account block when I was editing in a editathon organized by a community member, this has been on for almost a year with request for unblock first declined and another simply unanswered and ignored. It has affected my contribution because it happened in the middle of a project which I was the project lead: It was targeted at onboarding underrepresented folks into the community that is People with Disabilities.
    Oh mine, the project was a nightmare coupled with accessibility issues of the Wikipedia skin. As a result the People With Disability could not edit especially the blind ones as if that was not bad enough, some of them where blocked as well. As a result, the project has not found closure and the issues of accessibility still unresolved. It has affected my contributions to even a greater extent as the admin also deleted my sandbox as a result trainings organised by techwiki like learning how to use pywiki I am practically useless there as it involves practice in the Sandbox.
    I have been unable to fulfil my promise to the community I tried to onboard and I sense the deep frustration and disappointment in them when we interact on Whatsapp.Those who are vocal have aired their views and I feel frustrated at it all.--Zend2020 (talk) 11:29, 26 April 2022 (UTC)
25. I couldn't contribute to any of the wiki projacts since last three weeks due to the fact that my IP address has been blocked since last two weeks. I can't best tell the exact reason why I was blocked. This is so worrying since it denied me an oppotunity to edit on the wiki projects. Achiri Bitamsimli (talk) 22:48, 27 April 2022 (UTC)
26. During several editathons and editing workshops we have received complaints from people about this very issue in Mexico. It is a frustrating situation for newcomers and difficult to resolve for the community. So far in my chapter we have not documented these blockages in detail, but we will do so in the future. --ProtoplasmaKid (talk) 16:22, 28 April 2022 (UTC)
27. Je suis Petrus yh, contributeur actif et membre du Groupe d'utilisateurs Wikimedia Côte d'Ivoire. j'ai été également victime de ce genre de blocage plusieurs fois en essayant de contribuer sur des projets Wikimédia. Celà a commencé en Mars 2022 lors d'un atelier Art+ Feminisme auquel je participais. Ce jour-là , je n'ai pas pu, à cause des blocages, faire mes contributions lors de cet atelier. J'ai ensuite constaté les jours suivants que lorsque j'essayais de travailler sur les projets Wikimédia seul en retrait, le problème de blocage perdurait, m'empêchant ainsi de faire des contributions.
    Enfin, j'ai rencontré le même problème de blocage dans les mois de Avril 2022 lors d'ateliers Wiki kouman que auquel je prenais part. Non seulement je ne pouvais plus travailler sur les projets Wikimédia durant le tout un mois (délai de blocage fixé par le proxy) qui ont suivi les ateliers, mais aussi d'autres ayant participés aux ateliers écopaient de la même "sanction".
    Je pense que ce problème doit être résolu le plus rapidement possible, car non seulement, celà n'encourage pas l'inclusion des nouveaux contributeurs dans le Mouvement, mais aussi celà empêche les contributeurs actifs et les organisateurs d'événements ou edit-a-thons d'être plus productifs en termes de résultats
    Petrus yh (talk) 07:57, 4 May 2022 (UTC)
28. My friends got interested to become Wikipedia editors after my explanation on the relevance of Wikipedia. To my greatest surprise, both of their IPs got blocked immediately they clicked on create a Wikipedia account without violation of any rule on two different scenarios. This is a real problem and discouragement to most of them willing to contribute to Wikipedia.One was blocked forever according to the blocking message while the other was blocked for six months and for what? They still haven't been unblocked till date. Please try to rectify the issues because it's really embarrassing...thank you. Obuezie (talk) 04:24, 29 June 2022 (UTC)

    @Obuezie: Please tell them to contact stewards using UTRS or by sending an email to stewardswikimedia.org, specifying all details they saw in the block. NguoiDungKhongDinhDanh 12:10, 29 June 2022 (UTC)

29. Hi, French Wikimedian here discovering the joys of contributing to Wikimedia projects from Nigeria. I'm experienced enough to ask for unblocking and/or an exemption, no big deal, but how doable is this for a newcomer? What impression are we giving to people whose first interaction with the Wikimedia interface is "your IP is blocked"? This is a serious issue. Editors from the developing world are already facing a lot of obstacles, this is one that should be addressed as soon as possible. Thanks. --DonCamillo (talk) 11:49, 13 September 2022 (UTC)
30. Hello! An admin and bureaucrat from Basque Wikipedia here. Two weeks ago I received a couple of messages from two students telling me that they had been blocked, but they didn't do anything. So I researched the IP they gave me, which wasn't a VPN but the regular IP from the University and made an IP Block Exemption for Basque Wikipedia. Anyway, today I was working at the University, and I discovered that I couldn't edit anything outside euwiki. Not Meta, Commons or Wikidata. I couldn't even link new articles to other languages, because that depends on Wikidata. I couldn't write to the Steward that blocked the IP because writing should be done also on Meta, nor write in my user page. This blocked didn't affect only anonymous users, also users with long-standing activity. And students couldn't even log in with the Dashboard, because the logging-in process also depends on Meta/English Wikipedia. There have been vandalism from this IP, but blocking everyone using it in all pages and saying that this was an Open Proxy seems too much in my opinion. -Theklan (talk) 13:55, 11 April 2024 (UTC)

Comment from Vermont

Hi all. Thank you for voicing your concerns about these proxy blocks. I'd like to address a few of the concerns listed here, as well as give my thoughts on some of it.

• Regarding Tks4Fish, yes, he is one of the Stewards most involved in blocking proxies. Blocks that mention his username are the blocks he made, it isn't a default for all global blocks to point to him.
• As I understand it, this has particularly affected editors in Africa because of issues regarding how some African ISPs assign IPs. See en:Carrier-grade NAT.
• The way to get around these blocks is a global IP block exemption, which can be requested on Meta or to the Stewards' email queue. And for which there is a significant backlog. New problems, same tools.
• Correct, there is no system to exclude experienced users from global IP blocks. And I do not expect that to happen, nor would I support it. It would mean that there would be a set bar after which someone can abuse proxies, and such a policy would have prevented the discovery of so many large cases of abuse. Individual requests are better, though even better would be if there was a more manageable line between preventing abuse and reducing collateral that never affected as many users to begin with.
• Unfortunately, edit-a-thons are often affected. Email response times are not easily fixable, and it might be helpful to have some sort of special queue or something to handle the requests that have a deadline. For now, though, if you know someone who is organizing an edit-a-thon and urgently needs gIPBE, I would be okay accepting it via email directly to me. I will note that making it so that edit-a-thon participants can easily register accounts on their own is somewhat more difficult. Giving the coordinator gIPBE would allow them to register up to 6 accounts on that IP address. The English Wikipedia has the "event coordinator" permission that gets around the 6-account cap, but we do not have that userright on Meta-Wiki. It is something that I think might be helpful; people planning events on projects other than the English Wikipedia would be able to request gIPBE from Stewards and event coordinator on Meta, could register the accounts on Meta, and the event participants could then edit with it on their own. See mw:Help:Mass account creation and Mass account creation for technical details and current practice.
• As for the "guidelines offered", where are those currently used? That's an explanatory subpage from a WikiProject that doesn't seem to have been updated in 15 years. If it's in any current block messages, please let me know and I will remove it. The guidelines are here, on the page that this discussion is a subpage of.

There is no question that this system is far from working ideally. Part of it stems from outdated IP assigning methods in various ISPs (certainly not just in Africa), part of it from difficulty in preventing new avenues of abuse, part of it from a lack of systems and tools that we as volunteers have, and a variety of other reasons. Not to mention that, apart from the users whose residential IPs are blocked (whether because of CGNAT or p2p proxies), there are more users than ever using free and paid VPN services, or comparable services like Apple's iCloud Private Relay. Allowing editing and account creation from those IPs will make containing abuse infinitely more difficult (dangerously so), but blocking those IPs does cause collateral. And, as noted, the infrastructure we have to manage and reduce that collateral is lacking.

The optimal fix for this, in my view, would be to create a streamlined process for gIPBE requests separate from the current VRT option, as VRT is not particularly suited to handle these sort of reports. It would also be beneficial to reduce to anonymous only or remove the blocks on the affected African ISPs, and consider unblocking ranges that had similar issues on a case-by-case basis after review. This would affect fewer users overall and allow faster response times to affected users. I hope this helps. Vermont 🐿️ (talk) 22:46, 20 April 2022 (UTC)

Agreed with the solution. When I noticed that range blocks caused more harm than good (countless mails to stewards), I started to reduce the length of any such block (if necessary at all; I check every single range intensively if a block would case more harm than good). The situation with OPs is a bit different because they obfuscate the original IP address which is pretty often needed by checkusers and stewards to stop harm against the projects. For that reason, I agree that we cannot give up on OP blocking. The only way to get out of these problems are (much!) easier reporting ways, more people who can give out exceptions (locally and globally) and check outdated OPs and IPBEs. Maybe it would also make sense to give long-term users an option to self-assign an IPBE (e.g.) once per week for x hours for such cases like edit-a-thons. Most of their IP addresses used would still be reported (in order to prevent abuse) but most problems for that one moment would be solved (and users could look for long-term solutions). Best, —DerHexer (Talk) 10:09, 21 April 2022 (UTC)

I don't see any need to rate limit how many of these long-term users can hand out, as long as the flag for doing this can be revoked and exemption is linked to that user's account. –SJ talk  18:34, 21 April 2022 (UTC)

Blocking

My name is Margaret Kabanda my Wikipedia username is pine12k. 197.239.4.213 06:29, 21 April 2022 (UTC)

Neither this IP address nor the account pine12k are globally blocked. Vituzzu (talk) 08:37, 21 April 2022 (UTC)

Hello Vituzzu, but still when i go to my Wikipedia page it still shows me that my account is still blocked i can not edit. Pine12k (talk) 12:32, 28 April 2022 (UTC)

There is a message in the block log at https://en.wikipedia.org/wiki/Special:Log/block?page=User:Pine12k The reason does not appear to have anything to do with open proxies or IP addresses. Whatamidoing (WMF) (talk) 16:51, 2 May 2022 (UTC)

IP Address Blocked

My IP Address was blocked and I'm quite sure I didn't violate any policy. Drsmartofficial (talk) 08:31, 21 April 2022 (UTC)

Drsmartofficial: You can follow these instructions from No open proxies:

Privately email stewardswikimedia.org (direct contact form). You can use any language, we'll do our best. Include:

1. the IP mentioned in the error message you got,
2. the username you use or would like to use and
3. the reasons why you think the global block was in error

MarioGom (talk) 17:08, 21 April 2022 (UTC)

Some related discussion and stats

Hi. I believe phabricator:T303774 and phabricator:P22459 are related. --MZMcBride (talk) 16:19, 21 April 2022 (UTC)

Indeed, as explained in phab and wikimedia-l. See https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Archive335#Recent_proxy_blocks MarioGom (talk) 16:30, 21 April 2022 (UTC)

French translation

Part of the blocks reported here are explained at No open proxies/P2P. There seems to be a lot of confusion about how to appeal them. That page includes specific instructions. Given that a significant amount of complaints are related to French Wikipedia, it would be nice if someone could translate that page to French. cc Anthere. MarioGom (talk) 17:00, 21 April 2022 (UTC)

done Anthere (talk) 21:24, 22 April 2022 (UTC)

Awesome, thank you! MarioGom (talk) 10:31, 23 April 2022 (UTC)

Auto-blocking is never the answer [any more]

I think 'automatic blocking' as a concept is now the wrong solution in almost all of [these] cases. Once it made sense as a stopgap. But now it does not.

1. We have machine models that can effectively help classify contributions based on their content rather than their metadata -- so it is always preferable to see what an editor is trying to post before deciding how to handle it.
2. We edit in a society, and can easily allow people to approve one another or ping one another to join our implicit web of trust, rather than a hard, slow, email-and-wait process.

   For instance, we could let any autoconf user create a temporary IPBE account for someone else, long enough for them to make initial edits (say at an editathon) and ask for longer-term exemption if needed. Or we could let anyone edit through a rangeblock if they connect their account to an existing identity online. Or let anyone propose an edit that is caught in a non-public queue, and then based on classification of that edit, ask them to add profile details afterwards in a way that feels welcome to humans and unwelcome to bots... or to try editing a less controversial / less-vandalized page... or to do a short wiki-captcha-style cleanup task.

As a bonus, doing this would provide a smooth + uniform experience for editors + editing tools (even if the way their edit is applied changes w/ context), rather than giving different messages / interfaces based on how suspicious their ambient network environment is. –SJ talk  18:30, 21 April 2022 (UTC)

I partially agree. IP blocking in general is only one of the tools we have, it's not a silver bullet, its effectiveness will probably decrease over time, and it has a high number of inconveniences. However, its part of our current toolbox, and it's effective to mitigate some kinds of serious abuse. You mention machine models that can effectively help classify contributions based on their content rather than their metadata, as an alternative, but it's currently not. No such system exists today ready for production and capable of replacing all other tools, including IP blocking. Anyway, I'm all for discussing and implementing tools that can complement, and even replace IP blocking (eventually). The way I imagine these tools in the future, IP blocking would mostly be replaced by IP flagging, where IPs that are frequent source of abuses are flagged to help other systems down the pipeline to establish thresholds for stopping edits. MarioGom (talk) 18:48, 21 April 2022 (UTC)

Agreed, IP flagging would be an ideal replacement. [Also "account flagging" for accounts that leverage their reputation to help exempt newbies from blocks] Is there a phab thread about such an idea yet? –SJ talk  16:42, 26 April 2022 (UTC)

I've been waiting for a very simple and small software bit which would help handle a fair amount of cases for years, we've been waiting for global block of accounts for years. Honestly I don't expect to see cutting edge technology being implemented for a massive revolution of the whole "user management" system. Vituzzu (talk) 21:44, 21 April 2022 (UTC)

Vituzzu: I feel you. That's why I push back against throwing the baby out with the bathwater for our actually existing tools. But still, we should try to discuss and implement improvements, both small increments, as well as more ambitious tools. MarioGom (talk) 21:59, 21 April 2022 (UTC)

Surely, but if a solution is needed on the short term talking about futuristic solutions is somehow inappropriate. Vituzzu (talk) 07:32, 22 April 2022 (UTC)

@Vituzzu: I've wanted a tool like that for a while. I did make a tool called BlockAround as a stopgap solution to poke single-ip holes in webhost blocks, for EN. I could probably work on adapting it for use elsewhere if it would help you. I use this 3rd party tool to help with larger / more complicated scenarios. SQL^{Query me!} 22:54, 23 April 2022 (UTC)

@SQL thank you for the link, the maths is not a problem, but having the links is helpful, although it is still an administrative overhead, which, for example, doesn't allow to log the reasons for unlocking a certain IP. However I tested the tool and it, apparently, can't parse ranges in the Block Around field. Vituzzu (talk) 17:25, 24 April 2022 (UTC)

Autoconfirmed should not be the basis for IPBE, nor extendedconfirmed, nor some similar length of time or edits. Editing from actual proxies should not be encouraged unless needed (China, as one example), and is often related to attempts to evade CU. However, editing from ISPs that act like proxies (like the many users here) is something where we can look at decreasing the amount of blocks made and improving response times to IPBE requests. Vermont 🐿️ (talk) 00:28, 22 April 2022 (UTC)

@Vermont: For clarity, I'm suggesting that anyone who has put a dozen hours of time into their account should be welcome to grant IPBE to others, not that they shoudl get it automatically themselves, and that the others which are so granted would be linked to the grantor's account, so that they are both affected by any future block or CU. It doesn't give evaders or spammers extra leverage, and lets community members build a web of trust. –SJ talk  16:42, 26 April 2022 (UTC)

What are your thoughts on a global eventcoordinator permission that includes the ability to give IPBE temporarily and create accounts on blocked ranges? Currently, neither of these are possible in MediaWiki, but this is a significant need and I'm going to ask. Vermont 🐿️ (talk) 17:05, 26 April 2022 (UTC)

That makes perfect sense to me. I'm not sure it needs to be limited to events; but 'accountcreator' would be a useful flag that could be assigned to event coordinators on a regular basis. –SJ talk  02:31, 1 May 2022 (UTC)

I've been also asking for years to improve the blocking messages. Vituzzu (talk) 07:32, 22 April 2022 (UTC)

@Vituzzu: Where does the blocking message text live? How does it get updated?

As for "futuristic solutions", the machine-reading models I mean is not complicated and we have both a WMF team and community devs who might be able to adapt something. And for better or worse, sometimes a more substantive/specialized change can be easier for [people with energy / interest / available time] to focus on than a small one. –SJ talk  16:42, 26 April 2022 (UTC)

@Sj: We already do something close to that with the abuse filters, which accept a fairly sophisticated config thanks to regexp. I spent many hours monitoring and improving those filters when we still had to deal with IPs at wiki.pt, with the help of some resident regexp gurus we have there, and in a number of cases a high level of refinement was attained - though not enough for not making a much better option to get rid of all that IP editing for good. In any case, the main problem here seems to be that the people behind IP addresses identified as OPs don't seem to be able to register an account, or even to edit using a registered account. If that would be allowed a significant part of the problem would be gone. - Darwin ^Ahoy! 12:53, 30 April 2022 (UTC)

On-wiki feature

There are some elements of answers that are purely in the hands of stewards, they have to discuss and find common grounds, in particular to implementing blocks, so that they limit damage on good people, whilst preserving the projects from vandals.

However, the general observation is that the current system to report an unfair block to stewards and get unblocked by them is largely broken.

1. process is not simple to understand by the user
2. complicated to implement on the steward side (requires back and forth discussion, checking legitimacy of request, copy pasting information etc.)
3. the steward pool of volunteers is limited, whilst the stewards willing to do that job is even smaller (I heard the VRT queue is overflowing)
4. the process reveals IP private info

All this creates a bottleneck.

There is one path we could explore, a feature to simplify the process of "adding legitimate users" to the Global IPblock exemptions list, in a process inspired from the Global renamers one.

1. interface directly on wiki (bypass of VRT, bypass of copy pasting between tools)
2. a process which could provide info to the functionary to very quickly assess whether the person is a legitimate editor or not (every person fighting vandalism know how to do that... display last contribs... block log... number of edits... etc. or simply direct links to those info to simplify the functionary job)
3. a process allowing various "unblocking" options, day, weeks, indef listing, pretty much as the blocking feature permit, so as to grant indef listing to the super trustworthy individuals, and a time limited listing to those more questionnable
4. add a checkbox system where requesters can give pre-loaded reasons for their asking (edit-a-thons etc.), which will help make the system multilingual and language neutral for the functionary (in most cases, no need to discuss with the user)
5. add any feature necessary to limit the risk of vandals abusing the feature (forced loging before submitting the request, capcha stuff)
6. tool access by steward and CU

In short, simply make the "add to the Global IP block exemption list" process fluid.

Issues

• complicated situations would still require going VRT
• does not solve a possible shortage of steward

Potential benefits

• will allow transparency on the process (who gets added to the unblocking list, who does it)

Anthere (talk) 15:45, 26 April 2022 (UTC)

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 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) (talk) 23:47, 29 April 2022 (UTC)

DannyH (WMF), seems generally accurate. You mentioned Ghana and Benin; add Bangladesh, Indonesia, and Malaysia to the list, all extensively use CGNAT and are covered in questionable proxies. I don't think your possibility #2 ("innocent" vs "dangerous" proxies) is practical, though. ST47ProxyBot's uptick in blocks since last year? All of those "API-confirmed p2p proxy" blocks are targeted at one service that has been abused a lot. There's no practical way to differentiate between "good" and "bad" proxies there, it's just a question of which IP an abuser gets routed to, and a "bad" IP is good right up until someone starts abusing it. Apple Private Relay has been helpful enough to publicly indicate how their IPs are organized based on location, so it would at least be possible to rangeblock a region without blocking the whole service, but I don't think any other VPN/proxy services give us a practical way to block individual users or small subsets of users. And speaking as one of just a few people who work the English Wikipedia checkuser queue (for IPBE requests)...yeah. We're doing our best here. Queue's down to less than a week response time lately. GeneralNotability (talk) 02:02, 30 April 2022 (UTC)

I've taken to getting trusted users in the region (people running editathons etc) to just list accounts on my talk page. I do want to add that us enwiki checkusers can't solve the problem - these people generally need global exemptions to edit wikidata, commons, and often their local wiki. I'd like to see the adoption of a noticeboard for stewards to do the same, and they can probably just grant GIPBE to users with enwiki IPBE, since we're usually fairly reliable. -- zzuuzz ^(talk) 08:02, 30 April 2022 (UTC)

Don't many local wikis also having their own blocking system though? enwiki will duplicate open proxy blocks on meta, so global-IPBE will not work on enwiki. I know there are also other wikis with this system of local open proxy blocks, so you'd need local IPBE on each. ProcrastinatingReader (talk) 12:05, 30 April 2022 (UTC)

I believe that both meta and eswiki essentially copy their proxy IP blocks from enwiki. Yes, enwiki would also need to add IPBE in the current scenario, but global IPBE seems to be a more essential basic. For instance, I believe users won't even be able to edit their enwiki talk page to request unblock without GIPBE. Many will want to edit wikidata and commons, and are not otherwise prevented. -- zzuuzz ^(talk) 13:21, 30 April 2022 (UTC)

This latter confusion seems like something a better software system would help with. Have a public request-page that anyone, from any IP, can [make a nym and] post to to request a block exemption [for an account w/ that nym if they don't already have an account]. Or let existing users post there w/ the requested nym. Work w/ local wikis that have their own system so that they replicate this form of block exemption. –SJ talk  02:28, 1 May 2022 (UTC)

I'd like to add that the global/local distinction can be confusing even to local admins dealing with IP block exemptions, which creates even more work and delays as they have to figure out what's going on when it doesn't work the way they expect it to. Julle (talk) 09:21, 1 May 2022 (UTC)

I've been getting really helpful replies both here and on Wikimedia-L, 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 IP 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 IP 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 (WMF) (talk) 01:29, 3 May 2022 (UTC)

I have a couple of observations on these suggestions.

"wait for someone to vandalize". Not an effective approach, in fact I would say in most cases that the network has already done the vandalism and that's why it's blocked.. These IP addresses are most troublesome because vandals (etc) can switch between IPs more or less instantly. Individual blocks are basically useless. The size of the available pool is the problem, and through mass blocking we are adding viscosity. It's the same reason Tor got banned a long time ago.

"would people in other regions be able to abuse those services". Absolutely. They have done for years, and this almost all of the problem. The US is obviously a major origin of abuse on enwiki, but not the only one, even through proxies in Africa. There are some local issues, but the foreigners are the real problem.

"block all unregistered edits", yes the abusers will continue making accounts. It would slow down some of the more rapid vandals a little, but probably not have a much greater effect. I sometimes think that in some senses it is almost better to allow unregistered editing and prevent accounts, because then at least you have some idea of what's going on. I seem to recall that I already block more registered sockpuppet accounts than IP addresses.

I do believe at this time Ghana is a special problem, since most traffic in the country is carried on two networks which are effectively completely blocked. Some softening of this block would probably be proportionate. I'm not sure which would be next to look at, but Ghana really is badly affected. -- zzuuzz ^(talk) 07:19, 3 May 2022 (UTC)

I'll just add to this. I suspect other West African countries should be the next to look at (Benin, Togo, Côte d'Ivoire, and a few others). Regarding the problem of vandals switching IP address: it is most common for proxy users to switch between, say Ghana->Colombia->Egypt->Vietnam, rather than switch between 4 different IPs in Ghana. Lifting one or two countries' blocks, those with highly concentrated IP ranges, will allow some abuse to filter through, but the benefits should be disproportionately larger. Many other countries have enough IP ranges to deal with this type of block; although it can be inconvenient for the end user, it's often not terminal. -- zzuuzz ^(talk) 13:01, 3 May 2022 (UTC)

One nuance to Category #2 is that often someone will find that they need to get both local AND global IP Block Exempt before they can edit, which usually means that after going to all the trouble of getting the local one, they then have to deal with a global steward whose fluency in their language may be poor. I would propose allowing local stewards to assign global IP Block Exempt, or removing the distinction in software altogether and have local exemptions be recognized globally, which would not only reduce the workload on the global stewards, but remove the friction caused by the local and/or global distinction. -- Ahecht (TALK
PAGE) 14:49, 4 May 2022 (UTC)

Hi everybody. I'm a Director of Engineering in Product Engineering at the Wikimedia Foundation. I'm writing this from my perspective as a practitioner in engineering and security, not necessarily from that of someone trying to set a specific direction. Danny invited folks to participate in the conversation, and although it's honestly a pretty busy time with annual / semi-annual planning at the Foundation, I think this is a really important topic, and it's one of increasing importance. I do want to note that what I'm saying here has likely been raised by others already, so it's likely there's nothing new, but here's a sketch of a proposal, getting into some specifics about mechanics. I'm aware of the tradeoffs for privacy, security, and usability. It's tough! Anyway, ...

If I understand correctly, we want to optimize for several things:

1. Making sure good faith proxy users can contribute.

2. Not making good faith proxy users go through onerous and unfamiliar processes.

3. Reducing the size of queues for IPBE maintainers.

4. Ensuring positive bold-revert-discuss cycles.

5. Keeping malicious actors out.

Does that cover it mostly?

I would prefer the ability for users to register and login from any IP, then exempt logged in users from proxy block lists (after all, their username is known and that can be blocked).

If the user is coming from a proxy block list, can we require an email address or end-to-end encrypted messaging number for registration, and require the user to confirm it prior to being allowed to edit?

The "Welcome to Wikipedia: Please confirm your email address" email and "Account details on Wikipedia" (for password resets, where the user actually has to input a username anyway) emails should not list the username of the user if we're concerned about the user's Wikipedia username being divulged in email for such users (as to whether us storing the user's email address introduces any risk of inquiry that has to be avoided when all things are considered, that's a question for people knowledgeable in this regulatory space; double-salted-and-multi-hashed email addresses and other privacy-forward encryption schemes are ways systems attempt to work around this when merely verifying that there's an email address match). However, we do want users to be interacted with for their edits via notifications, so perhaps something has to be shown to the user at registration or upon email verification to notify them of communication preferences and the implications.

Have we considered sending a nicely formatted welcome packet in email for these sorts of scenarios to help users in their editing journey? Sort of like a README included with the email verification email. I wonder if that could help newcomers in having the most good faith, productive editing experiences. Most users want to do the right thing!

As it is, if a user has an active cookie from registration and clicks the email link in the "Welcome to Wikipedia: Please confirm your email address" they're already redirected to Special:Homepage, where we're putting them on a safe path less likely to result in counterproductive edits, which should mitigate the risks leading to patroller fatigue. So, instead of the current practice of "letting" the user immediately beginning editing on the page, the proxy users should be redirected to a special page that tells them to confirm their email address first. However, this keeps the user from the user's original intent to edit a particular article. But the user can get back to the article if they're truly interested.

An additional enhancement if this is still creating too many counterproductive or possibly genuinely damaging edits is to force the user through a number of Special:Homepage based edits to get to autoconfirmed for further edits. This is more work to implement, but it may not even be necessary. It seems like it would be best to first test if the email requirement for proxy users to register gets the job done.

Confirmation of email address can be scripted by sophisticated attackers, but that and its ilk is always going to be a problem. However, if we would do something like use Managed Challenge (Cloudflare) specifically and only for the case of the user who wants to register from a proxy blocked IP as an intervening step, that could be another deterrent. Alternatively, use of a QR code to setup a 2FA application is strong evidence of it being a human (also scriptable by a sophisticated attacker, but they need to have a clue about turning the the image bytes into a TOTP) and having access to a device equipped for scanning QR codes - there are numerous usability challenges with QR codes plus it can practically require people who don't have regular access to their own phone to be disenfranchised; email offers more benefits and fewer of the drawbacks. So maybe a thing to consider is giving the user a choice.

If we need to add some other type of friction for users who are attempting to *login* from a proxy IP (e.g., to deter brute forcing attacks), something like Managed Challenge (or whatever Security is already building?) is an approach. Another is sending a 2FA code to their email address. Again, 2FA by way of a 2FA application is another way. I believe the scope of this discussion here is less concerned about login, but I mention this for robustness of implementation.

These sorts of approaches wouldn't stop people from using disposable email addresses, and that's probably okay. There are legitimate reasons for people to use those on privacy grounds or if they're concerned about the annoyance of advertising (even if direct-to-consumer stuff is pretty narrowly scoped in practice in Wikimedia land). And additionally, as long as these users can engage in meaningful and positive bold-revert-discuss cycles, we sort of don't care about what the actual email address is.

Another idea that's been bandied about is putting the user into the registration flow in the app (many of the users are on mobile devices and when they aren't they may have a mobile device), where we can enforce further constraints on the provenance and legitimacy of the user and also ensure they're following a curated editing experience. Even if we don't do that, a similar approach in the apps for the registration as discussed above ought to be possible, although I believe it does require some URL route matching to be established in the apps. Proof of notifications is one way the device itself can be used to verify a second factor in establishment of identity - it's not always super portable across devices, though. A team member had at one point suggested using the app as a place to send 2FA tokens to the user, by the way. It's an interesting approach and provides a nice means for keeping users connected to the bold-revert-discuss flow in a mobile oriented way.

A potential issue with an email requirement for proxy IP users might include UCE filters flagging our mail exchangers. It's also possible that introduction of an email requirement for proxy users could have some sort of chilling effect (but it's hard to imagine how it could be more chilling than the current state). Malicious users creating lots and lots and lots of disposable email addresses could potentially be an issue in a few areas. For all of these, anti-automation techniques can probably help stave that off some - I'm afraid that probably requires a redirect to another service if it's to be done in a security and privacy forward way (we do have a serious concern for accessibility and internationalization and localization as well, although it's probably worthwhile to consider incremental enhancement if there are drawbacks with current "off the shelf" options). Finally, valid email address / end-to-end encrypted messaging number account determination vulnerabilities as always require some consideration. ABaso (WMF) (talk) 16:24, 11 May 2022 (UTC)

Hi ABaso (WMF): I think the idea of requiring email confirmation for certain IPs (e.g. open proxies in residential networks) is worth exploring, or at least the idea that we may use IP as a signal for more complex processes, rather than just being blocked/unblocked. With respect to 2FA or other types of challenges you mentioned, I think they have nothing to do with our threat model. Strong evidence of it being a human is (mostly) useless here. Our proxy blocks are (mostly) not about bots. Most types of abuse we're after are carried out by humans, manually, and sometimes with a lot of dedication. Gaming autoconfirmed status is what many of them already do. MarioGom (talk) 22:33, 16 May 2022 (UTC)

@DannyH (WMF) / @ABaso (WMF) - In my experience, one big improvement that should be implementable would be to have the option to turn cookie blocks (or even maybe autoblock) off for a block. We typically hardblock these IP's, which blocks logged-in users, and sets a block cookie, as well as the other autoblock stuff. This means, when a user attempts to edit via VPN, they then realize they are blocked for using a VPN, and turn it off. Now they get a block message still, because of the cookie block. This lasts another 24 hours. Worse yet, the block message now tells them that <vpn IP> is blocked. This makes it confusing for admins to troubleshoot why they are seeing a block on an IP that isn't theirs. SQL^{Query me!} 05:52, 24 May 2022 (UTC)

Just for the record: phab:T306751. MarioGom (talk) 06:40, 24 May 2022 (UTC)

In his first comment, DannyH wrote:

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.

I am compiling below a list of known existing or ongoing efforts by major industry players to protect the privacy of IP addresses:

• Apple iCloud Private Relay: Available for paying customers of iCloud+ on Apple devices. Restricted to certain countries at the moment.
• Google One VPN: Available for paying customers of Google One on Android and iOS.
• Microsoft Edge Secure Network: Built-in VPN for Microsoft Edge browsers. Available for free. Currently in early testing phase.
• Opera VPN: Opera browser comes with built in free VPN.
• Mozilla VPN: Paid service. Can be installed on several devices.

This is not an exhaustive list. There are also standalone VPN services that have been seeing steady growth in user base as well as browser extensions that provide VPN services for most mainstream browsers.

Part of the reason for this increase in VPN usage is the high levels of government censorship and surveillance in several countries (source). It seems highly likely that over the next few years we will see more users preferring to use VPNs or other similar services that protect their privacy. If this continues, it brings into question our current practice of blocking VPNs and proxies. -- NKohli (WMF) (talk) 22:51, 3 May 2022 (UTC)

Meanwhile VPN detection services are doing a roaring trade, and that's because until the Internet gets redesigned it will still run on IP addresses. Unless these services offer effective ways to deal with criminal abuse (and dealing with abuse is usually against their stated purpose), people are going to realise they're just going to be banned all over the place. Because this is why we can't have nice things. Online banking from the Tor network? Not going to happen. There's an interesting discussion to be had there for sure, but I would suggest it won't fix that Benin editathon or the other problems stated at the top of this page in a hurry. -- zzuuzz ^(talk) 13:09, 4 May 2022 (UTC)

Well, while a lot of sites do block Tor, few block any kind of VPN service. Those who do have VPN blocks don't have it as aggressive as we do. I think Wikipedia actually has the most complete VPN block list of any site I've seen. It's certainly the only site I use where I've encountered issues (from memory). Technically speaking it's pretty impressive, though I'm not sure if it's necessary. ProcrastinatingReader (talk) 15:21, 16 May 2022 (UTC)

Most big services do restrict VPNs and open proxies. But they have more sophisticated anti-abuse tools like shadow-banning, requiring additional verification, etc. Many, like Facebook, also have restrictions based purely on geolocation (e.g. required verification step differ if you sign up from an IP in Thailand or in the United Kingdom). In other cases, you might not notice restrictive measures because they're assisted by extremely aggressive behavioral profiling. We could learn from some of these measures, and we should probably never implement others (sometimes for ethic reasons). MarioGom (talk) 22:48, 16 May 2022 (UTC)

@ProcrastinatingReader - Anecdotal for sure, but both my primary bank, and the bank I use for my mortgage block me if I connect using a major commercial VPN. Neither is a small, or even medium sized bank. SQL^{Query me!} 05:56, 24 May 2022 (UTC)

NKohli (WMF): Note that privacy is not a good use case for P2P proxies. P2P proxies are inherently dangerous for their users because users themselves become exit nodes, and the network is used primarily for abusive and criminal activity. Firing up a P2P proxy in your machine will eventually lead to someone's else illegal activity going online through your IP. Definitely not something anyone would want to avoid problems with the government. MarioGom (talk) 22:39, 16 May 2022 (UTC)

Block messaging. I don't know what the latest developments in block messages are. Last time I encountered a multiple block, presumably a local+global block although it might have been multiple range blocks, all it would say is "there are multiple blocks against this IP address", with no further messaging. At en:Wikipedia:Mobile communication bugs, custom block messages are described in places as 'flaky', 'unknown', or 'No'. A census of these issues from the WMF would probably be useful. -- zzuuzz ^(talk) 13:34, 4 May 2022 (UTC)

As a longtime user who has uploaded thousands upon thousands of files to Wikimedia Commons, I strongly advocate for an end to the proxy ban. It is inconsistent (sometimes I can edit, sometimes I can't), unfair to those who want to protect their privacy, and above all unjust. It must end. PDMagazineCoverUploading (talk) 16:57, 4 May 2022 (UTC)

I find it slightly irritating also as an established editor. On mobile I use iCloud Private Relay and, since the service can't be disabled for individual websites, to edit Wikipedia I have to toggle it off-and-on globally and restart my browser. ProcrastinatingReader (talk) 15:19, 16 May 2022 (UTC)

I share this position, or a closely-related one: well-established accounts should not be forbidden from editing over open proxies or commercial VPN services. Blocking anonymous and young-account edits from such services may be unavoidable in the near term, but old accounts with varied contributions are a scarce resource. Zwilson (talk)

@DannyH (WMF): Thank you for your request. I think this Task can be related: phabricator:T309328 --Valerio Bozzolan (talk) 15:29, 9 November 2022 (UTC)

Any movement on this?

Wikipedia's stance on VPNs is still asinine and utterly unjustified several months later...PDMagazineCoverUploading (talk) 10:24, 22 July 2022 (UTC)

Hi PDMagazineCoverUploading, and everyone following the page. I've been working with a group of people at the WMF to understand the increased proxy blocking, and other changes on the internet over the last year that affect how we use IPs. Using the software and policies that we have, it's become increasingly hard to block long-term, bad-faith users without also blocking good-faith contributors. Unfortunately, there isn't an obvious fix for this problem.

I'm putting together a group of people right now to hold a movement-wide consultation on how we use IPs, to bring together as many ideas and perspectives as we can, and figure out a path forward. There won't be one big conversation; it'll be lots of conversations in different places and using different platforms. That's a big project and it's still in early stages, so I can't say exactly when it's going to start yet. When I know more, I'll definitely be updating this page and making sure that the folks who have posted here will be involved. — DannyH (WMF) (talk) 21:12, 29 July 2022 (UTC)

@DannyH (WMF): Thanks for that update. I'm sad this is going to take so long. While this is no criticism of you personally (we had a great conversation about this), I do take issue with how we prioritize this as a movement. Something tells me that if a similar percentage of UK or US editors were affected as currently low-income country inhabitants are affected by this, we would have prioritized this very differently. Each time that we turn away a constructive editor because they have to jump too many hoops when trying to edit from their phone, we potentially lose a future colleague that would help improve diversity of our community.

I wish there were some short term quick fixes we could look at to at least work around the overly painful process to get block exempts. From what I understand this is probably the only part that has a reasonably straightforward fix. I would like to hope that there might be a volunteer or affiliate that is willing to step into this problem, and provide a bandage. Effeietsanders (talk) 20:21, 25 September 2022 (UTC)

Ip address block

Sometimes i can't edit due to the ip address block — The preceding unsigned comment was added by SIRTEE1 (talk) 00:29, 14 September 2022 (UTC)

@SIRTEE1: If you are still experiencing this problem, see the response two sections below this one. I moved your query to the right place on the page. Graham87 (talk) 07:36, 5 June 2023 (UTC)

Diff posts December 2022

Three-part series on proxy blocks, covering peer-to-peer proxies and responses -- Anthere (talk) 14:26, 12 December 2022 (UTC)

• • https://diff.wikimedia.org/2022/12/02/whats-happening-with-proxy-blocks/
  • https://diff.wikimedia.org/2022/12/09/proxy-blocks-automation-and-scope/
  • https://diff.wikimedia.org/2022/12/16/proxy-blocks-equity-and-growth/

Global IP Ban Exemption

Hello. Could I get the Global IP Ban Exemption? I am one of active Polish Wikipedia Editors. I'm asking about GIPBE, because I usually use VPN due to my safety. Thank you. Rhodesian05 (talk) 19:50, 28 April 2023 (UTC)

@Rhodesian05 please read Global IP block exemptions and submit your request at Steward requests/Global permissions Johannnes89 (talk) 06:12, 29 April 2023 (UTC)

Why are long-time logged-in users also blocked by IP?

I have been trying to read the reasons for blocking IP addresses, on several different pages, but I didn't find anyone explaining why we block long-time users with many edits when they happen to edit via an "open proxy", such as a VPN.

It happens once in a while for me, for instance when I am abroad wanting to watch TV from my home country and then connect to my home country using VPN, and then just want to correct something I read on Wikipedia (I often look up things they talk about on TV). For me it's not a huge issue like it certainly is for many especially in Africa who cannot simply turn a VPN off (or even users from countries with censorship). It just means I won't make that correction, of course. But it's still annoying because I do not understand the reasoning: Why do we block logged-in long-time users with no history of bad behaviour, just because they happen to log in via VPN or another so-called "open proxy"? It doesn't make any sense to me. I am the same person no matter where I log in from. Nobody else can log in as me. So my IP address really doesn't matter, when I am logged in as me. We can block people who try to edit from certain IP addresses without logging in, of course; that makes full sense and is well explained. But this just doesn't make sense.

It's much easier to accept annoyances when you can get an explanation that makes complete sense, even if it's just a dilemma that has no good solution. But among all the reasoning I have been trying to read, I haven't found anyone explaining why long-time logged-in users with a long history of good faith edits are blocked by IP. Nobody explained that.

Why is that? Jhertel (talk) 12:17, 31 July 2023 (UTC)

@Jhertel there are many trolls and vandals using proxy / vpn connections to hide their real IP address and/or escape autoblock. Applying proxy blocks to logged-in users who use the blocked proxy IP address is a way to prevent LTAs from escaping their block.

If you are frequently affected by proxy blocks, please read IP block exempt (or at your home wikis en:WP:IP block exemption / da:WP:IP-blokeringsundtagelser) and request global IP block exemption or follow the process described at the linked local policies to ask for local exemptions. Johannnes89 (talk) 17:24, 31 July 2023 (UTC)

Thank you for your answer, and for your directions of how to get a personal exempt.

I still don't understand the reasoning, though. I am not really asking for an exempt; I am asking for the reasoning.

What is an "LTA" by the way? Could you please type out the concepts you use, because I am not into all these specific terms; I just want a simple explanation (and I think many more would like it too). If I was into all the technical jargon, I would probably know so much that I already had the answer I am writing to ask about. I looked it up on Google but still couldn't find any meaningful meaning of "LTA" in this context.

You say that "there are many trolls and vandals using proxy / vpn connections to hide their real IP address and/or escape autoblock". So you are effectively saying that trolls and vandals that are logged in 1) have a long history of many edits and good behaviour without issues, and 2) cannot have their specific user account blocked (or perhaps just blocked if they use proxies)?

I just don't get it. All the answers I find are like yours, but none of them seem to understand the actual question. Or at least they don't seem to address it.

I'll try again: Why are long-time logged-in users with a long history of good faith edits blocked by IP? It's fine to block user accounts that are known trolls and vandals, but why the rest of us? You know who the good guys are. Why block us? We are logged in. I'm sure we are already in some category of specially trusted, such as "auto-confirmed" or something like that. You can block us on the user account level any time you want if we troll or make vandalism. Why block us on proxies, but not on non-proxies?

I just can't find the sense in it. Why does it matter which IP address I am on when I am a logged-in long-time good faith user with lots of good edits?

I get that we are trying to solve a specific problem, but I don't get why the current "solution" has to block me? It seems completely unnecessary. Block bad users, that's fine, block specific IP addresses for people that are not logged in, but why block good users at all?

If there is a place where this is explained, then please direct me there. 🙏

Another way to explain my question is: We are currently arresting everybody from a very large area, no matter who they are, except for those who have specifically applied for an excemption to being arrested. Why don't we instead refrain from arresting all the good guys, and only go after the few bad guys? Why not just check the ID of everybody in that area, and if they have a long history of being good citizens (which can be checked in the log) just don't arrest them? Of course arrest those who won't show ID (those who won't log in), but why arrest the rest of us, when you can see in our log that we didn't do anything bad?

My whole point is to get an explanation. And then, preferably, if there is a good one, to have it stated to those who get the rather offending message "You have been blocked" (which really should be changed to "The IP address you are using has been blocked", as I am pretty sure that by far the most people who are blocked by IP are not the criminals we are after). Jhertel (talk) 13:56, 1 August 2023 (UTC)

An LTA is a 'long term abuser', of which there have been many hundreds or thousands. It's a catch-all phrase for banned users, trolls, sockpuppets, vandals, spammers, and other returning nuisances. So let's say you're a "long-time good faith user with lots of good edits". You would probably qualify for block exemption if you ask for it. Why do we ask that you have to ask for it? This is a basic security principle called the Principle of least privilege. If you don't need it there's a risk involved with that, including if you suddenly went rogue or your account were to be compromised. You say, "You know who the good guys are". Sure, most of the time we can make a good guess, but the software doesn't automatically detect when it's the case. So you're a long-time good user with a reason to have block exemption, ask for it. In practice we don't even need you to be a long-time user, just someone with a reason and who isn't going to abuse it. -- zzuuzz ^(talk) 19:49, 9 August 2023 (UTC)