"lack of infrastructure" and lack of "current volunteers" weren't addressed in your email at all, given that you're relying upon wrong premises by assuming checkusers' bad faith and non-existing practices.

Vito

Il giorno sab 23 apr 2022 alle ore 19:58 Lane Chance <zinkloss@gmail.com> ha scritto:

On Sat, 23 Apr 2022 at 15:17, Rae Adimer via Wikimedia-l <wikimedia-l@lists.wikimedia.org> wrote:

Hi Lane,

I would appreciate if you could take the time to learn about an issue before holding strong, accusatory opinions about it. 

Maybe reading the facts in my email would be a good starting point. Your response has not refuted any of those facts, in fact as a checkuser you no doubt could confirm exactly how many times in the past checkuser tools have been misused and how they are still open to being misused.

 

gIPBE is granted to people in China and other areas where they want to use proxies for security reasons. A significant portion of current gIPBEs are for people in China. The issue here is not people being declined gIPBE, it’s the sheer amount of people who need it and the lack of infrastructure for current volunteers to handle those requests. 

 Declining was not mentioned and is not the issue. Alternatives for "lack of infrastructure" and lack of "current volunteers" was addressed in my email. Lacking volunteers is not a reason to fail to provide access to new joiners editing in good faith.

 

What isn’t feasible is automatically giving everyone IPBE, global or local, as it would make CU next to useless. Anyone intent on abuse could just flip a VPN on. This isn’t “the convenience of current checkusers”, this is an indisputable fact. People subject to bans often try to get IPBE so they can edit on a VPN without concern for that account being found in relation to previous ones. Any human review is better than mass-granting it to tens of thousands of accounts. We just need to speed up the time it takes to do that human review.

No, it would not "make CU next to useless". If people are contributing as part of editathons or similar, and if 100% of all their contributions are valuable good faith contributions, nothing else should matter. Literally they are not using the account for anything wrong, so why would anyone care? It is not the job of checkusers to be secret police and see all new joiners in bad faith, that is neither useful, nor a good use of volunteer time.

 

Regards,

Rae

On Sat, Apr 23, 2022 at 04:48 Lane Chance <zinkloss@gmail.com> wrote:

"Granting IPBE by default to [...extendedconfirmed]/etc. users is not feasible."

Granting IPBE to large groups of good faith editors is feasible, such as entire classes of people during editathons, all registered accounts joining a virtual conference, or everyone with more than 1,000 edits on wikidata.

"also make CU next to useless" is a unverifiable hypothesis which puts the convenience of current checkusers and the existing practices against the safety of new and regular users.

Checkusers are not legally accountable for their use of privileges, and in the past checkusers have been found to have kept their own private records, despite the agreement not to do it and simply been allowed to vanish without any serious consequences.

Considering that the risks to some users is prosecution, imprisonment or harassment by state actors which may be instigated by leaking this information, simple precautions like GIPBE should be automatic and preferably unquestioned for some regions or types of editathon or competition, such as for good faith contributors to the articles about the Ukraine war or human rights in China. If that's inconvenient for volunteer checkusers, than it's pretty certain that the WMF can fund an support service under meaningfully legally enforceable non-disclosure agreements, even independent of the WMF itself if necessary, to run necessary verification and ensure that the editors are not just vandals or state lobbyists.

Lane

On Fri, 22 Apr 2022 at 20:49, Rae Adimer via Wikimedia-l <wikimedia-l@lists.wikimedia.org> wrote:

It would result in every block effectively being anon-only, and it would also make CU next to useless. Granting IPBE by default to autoconfirmed/extendedconfirmed/etc. users is not feasible.

~~~~~~~~~~~~~~~~

User:Vermont on Wikimedia projects

they/them/theirs (why pronouns matter)

On Thu, Apr 21, 2022 at 4:00 PM Vi to <vituzzu.wiki@gmail.com> wrote:

IPBE for autoconfirmed is a local matter, it would imply that any block (TOR included) will, in practice, almost turn into anon-only.

Expiration is an option, as for any global group.

Vito

Il giorno gio 21 apr 2022 alle ore 19:51 Nathan <nawrich@gmail.com> ha scritto:

How significant is the risk in just granting autoconfirmed (or similar) users IPBE by default? Why does IPBE expire anyway? 

On Thu, Apr 21, 2022 at 10:50 AM DerHexer via Wikimedia-l <wikimedia-l@lists.wikimedia.org> wrote:

Hi,

Thanks for raising the topic. Being a steward for 14+ years, I've followed closely the evolution of that problem.

“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).”

Why the quotation marks? Because I've posted that very same message to the metawiki page and understand it as one step towards a solution. In my opinion, it makes way more sense to talk publicly about the issue and possible solutions than losing good ideas (and there have been some already in this thread!) in the wide world of this mailing list. Let's have that conversation onwiki—and I also encourage the WMF tech departments to join in that conversation. Because we as stewards have reported our problems with the current situation multiple times, sought for technical solutions (e.g., better reporting tools), indeed did get a better rapport with the WMF teams but still are not where we need to be in order to serve both interests (openness and protection). Unsurprisingly, also stewards are individuals with different opinions and (possible) solutions to that one problem. As Vito said, we will once again discuss it and will share our thoughts and solutions.

Best,

DerHexer (Martin)

Am Mittwoch, 20. April 2022, 20:19:48 MESZ hat Florence Devouard <fdevouard@gmail.com> Folgendes geschrieben:

Hello friends

Short version : We need to find solutions to avoid so many africans being globally IP blocked due to our No Open Proxies policy.
https://meta.wikimedia.org/wiki/No_open_proxies/Unfair_blocking

Long version :

I'd like to raise attention on an issue, which has been getting worse in the past couple of weeks/months.

Increasing number of editors getting blocked due to the No Open Proxies policy [1]
In particular africans.

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. »

I repeat -----> ... legitimate users... may freely use proxies until those are blocked. the Editors can be permitted to edit by way of an open proxy with the IP block exempt flag <------ it is not illegal to edit using an open proxy

Most editors though... have no idea whatsoever what an open proxy is. They do not understand well what to do when they are blocked.

In the past few weeks, the number of African editors reporting being blocked due to open proxy has been VERY significantly increasing.
New editors just as old timers.
Unexperienced editors but also staff members, president of usergroups, organizers of edit-a-thons and various wikimedia initiatives.
At home, but also during events organized with usergroup members or trainees, during edit-a-thons, photo uploads sessions etc.

It is NOT the occasional highly unlikely situation. This has become a regular occurence.
There are cases and complains every week. Not one complaint per week. Several complaints per week.
This is irritating. This is offending. This is stressful. This is disrupting activities organized in good faith by good people, activities set-up with our donors funds. And the disruption is primarlly taking place in a geographical region supposingly to be nurtured (per our strategy for diversity, equity, inclusion blahblahblah).

The open proxy 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, 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 User:Tks4Fish. This editor is involved in vandalism fighting and is probably the user blocking open proxies IPs the most. See log
  

So...
Option 1: contacting stewards : it seems that they are not answering. Or not quickly. Or requesting lengthy justifications before adding people to IP block exemption list.
Option 2: posting a request for unblock on meta. For those who want to look at the process, I suggest looking at it [3] and think hard about how a new editor would feel. This is simply incredibly complicated
Option 3 : user:TksFish answers... sometimes...

As a consequence, most editors concerned with those global blocks... stay blocked several days.

We do not know know why the situation has rapidly got worse recently. But it got worse. And the reports are spilling all over.

We started collecting negative experiences on this page [4].
Please note that people who added their names here are not random newbies. They are known and respected members of our community, often leaders of activities and/or representant of their usergroups, who are confronted to this situation on a REGULAR basis.

I do not know how this can be fixed. Should we slow down open proxy blocking ? Should we add a mecanism and process for an easier and quicker IP block exemption process post-blocking ? Should we improve a process for our editors to pre-emptively be added to this IP block exemption list ? Or what ? I do not know what's the strategy to fix that. But there is a problem. Who should that problem be addressed to ? Who has solutions ?

Flo 

[1] https://meta.wikimedia.org/wiki/No_open_proxies

[2] https://meta.wikimedia.org/wiki/Special:Log/Tks4Fish

[3] https://meta.wikimedia.org/wiki/Steward_requests/Global_permissions#Requests_for_global_IP_block_exemption

[4] https://meta.wikimedia.org/wiki/No_open_proxies/Unfair_blocking

_______________________________________________
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/UU76SJ5LZI5MA5F3WC3NSY4UMGDQTGXR/
To unsubscribe send an email to wikimedia-l-leave@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/Y5UMK72JMT2FZY5V455QHEWHZ3W2QGXQ/
To unsubscribe send an email to wikimedia-l-leave@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/5TMQ4I27YE6F4FIMFLGBVWJ34YLEFXHE/
To unsubscribe send an email to wikimedia-l-leave@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/KZ2A3TFAQXKKCLHUQXEXHMXF6PNAGD5N/
To unsubscribe send an email to wikimedia-l-leave@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/QUSR3JGDUKF7E6I63II3CNOGIKKQF6DE/
To unsubscribe send an email to wikimedia-l-leave@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/FRJAYBQCD4YYE3H2MQ4UIXLWONTLOHRN/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org

--

~~~~~~~~~~~~~~~~

User:Vermont on Wikimedia projects

they/them/theirs (why pronouns matter)

_______________________________________________
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/RXJ2MVTDNWYGGTTW6K3ZS4CIMX7M4DG2/
To unsubscribe send an email to wikimedia-l-leave@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/VEAJVQ6H5CQSVWP7MGIMER25YV6H3SES/
To unsubscribe send an email to wikimedia-l-leave@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/ZT6VGP47MGYAWY64E2Q34CP5CDCV5O6U/
To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org