Requests for Comment/No open proxies policy

Currently, the No open proxies policy doesn't state how the duration of the block/lock should last, So I wanted to open an RfC to determine the proper procedure. Zppix (Meta &#124; CVT Member &#124; talk to me) 20:26, 28 September 2019 (UTC)

Proposal 1
Block/Lock duration is determined by the blocking/locking CVT member or Steward.

Support

 * 1) if proposal 2 fails Zppix (Meta &#124; CVT Member &#124; talk to me) 20:27, 28 September 2019 (UTC)
 * 2) If proposal 4 fails.-- 09:48, 2 October 2019 (UTC)
 * 3)  Always pro-choice on blocking and enforcement. John (talk) 23:31, 2 October 2019 (UTC)
 * 4)  per above. Reception123  (talk) ('C' ) 04:59, 3 October 2019 (UTC)
 * 5)  How would any CVT block a proxy with a fixed duration for all proxies OwenFung87 06:44, 3 October 2019 (UTC)

Abstain

 * 1) Rathering for a clear time. Sentence to tweak a little bit. Which options, in which conditions etc. Nocturnal-Galatea (talk) 13:16, 3 October 2019 (UTC)

Proposal 2
Blocks/locks will be set to a 6 month length unless the situation shows a need of needing to be longer.

Support

 * 1) Zppix (Meta &#124; CVT Member &#124; talk to me) 20:27, 28 September 2019 (UTC)
 * 2) – Aνδρέας  talk&#124;contributions 21:44, 2 October 2019 (UTC)
 * 3)  makes sense. Reception123  (talk) ('C' ) 04:59, 3 October 2019 (UTC)
 * 4)  Follow everything nowhere except for the English Wikipedia and Wikimedia Meta Wiki. --OwenFung87 12:13, 3 October 2019 (UTC)
 * 5)  Seems enough. Nocturnal-Galatea (talk) 13:09, 3 October 2019 (UTC)

Proposal 3
Blocks/locks will be set for 1 year unless the situation shows a need of needing to be longer.

Support

 * 1) If proposal 4 fails.-- 09:48, 2 October 2019 (UTC)

Oppose

 * 1)  prefer 6 months as the "default". Reception123  (talk) ('C' ) 04:59, 3 October 2019 (UTC)
 * 2)  ?????????????????? OwenFung87 12:13, 3 October 2019 (UTC)
 * 3)  Too much. Already saw IP users changing within 6 months. Nocturnal-Galatea (talk) 13:10, 3 October 2019 (UTC)

Proposal 4
'''Blocks will be set indefinitely. The IPs can be unblocked when we confirm that they no longer work as proxies/VPNs/hostings (the confirmation will be done whenever such cases are reported). Those who can only access Miraheze from proxies/VPNs/hostings, etc. can ask for account creation by e-mailing our staff.'''

Support

 * 1) It's not very creative or productive to reblock almost the same IP ranges every time they reappear. This way we can finish it once and for all.-- 09:48, 2 October 2019 (UTC)
 * 2) if proposal 1, or 2 fail. Zppix (Meta &#124; CVT Member &#124; talk to me) 20:30, 2 October 2019 (UTC)
 * 3) and I'm very surprised that we aren't doing this already. It's a good site security practice - anything going through a proxy needs to have an account attached to it. Ref: CSEC ITSG-22 (UNCLASSIFIED). --Robkelk (talk) 00:22, 3 October 2019 (UTC)
 * 4) -The world's weakest support Per Zppix. --OwenFung87 12:13, 3 October 2019 (UTC)
 * 5) The "weak" is for the first sentence (rathering proposal 2 instead for this). Be aware an user using a VPN may not always have bad intentions, despite the abuses. Fine with unblocking the IPs when they're confirmed to be "safe". Also fine for e-mail creation - just be careful and not take this lightly, assure yourselves there are no abuses. Nocturnal-Galatea (talk) 13:14, 3 October 2019 (UTC)

Oppose

 * 1)  Absolutely not. Under no circumstance would I ever indef block an IP, even if a policy told me I had to. It's an unmanageable system, requires a higher level of understanding than is expected of stewards and likely even sysadmins to fully understand when something is a static and never going to change proxy and even then I'd argue against such a practise. John (talk) 23:30, 2 October 2019 (UTC)
 * 2)  Per what John said, we never indefinitely block IPs for any reason, so why should this be different? Reception123  (talk) ('C' ) 04:59, 3 October 2019 (UTC)
 * 3)  I do two votes because I think that this is the WORST option ever, however I follow Zppix. --OwenFung87 12:13, 3 October 2019 (UTC)

Comments

 * Indefinite blocks are NOT infinite blocks. It can be unblocked in the future (when a good-faith user report us that they no longer work as proxies; we can leave it to their reports for initial actions). The thing is, a lot of hosting IP ranges (including DO, AWS, etc.) are quasi-static in practice, and our blocking has been renewed every time it expires. So why not we just block them once until we find the situation has changed? Since the number of IPs are limited, proxies are as well, and having a control on the unblocking side will bring an end to the never-ending anti-spam wars in the near future.-- 05:19, 3 October 2019 (UTC)
 * Even if the policy about indef blocks passes, they should always be set to autoblock disabled unless users in that IP proxy are likely to abuse this wiki or even the global system. See below for a more detailed explanation. --OwenFung87 12:13, 3 October 2019 (UTC)
 * That has always been a practice. Our global blocks targets usually anonymous users and anonymous users only.-- 07:51, 4 October 2019 (UTC)

Overall comments

 * I don't think NOP is related to locking, as it only targets anonymous users.-- 09:48, 2 October 2019 (UTC)
 * You are right. However, Ip ranges (especially web hosts (which should be tagged/pinned with Webhostblock) and open proxies (which should have Proxyblock on their talk page)'s open proxies) or proxies may hide or unhide their IP at any time. Everything block about open proxies should have autoblock disabled and account creation enabled (unless at the most exceptional, and the rarest cases where a user is editing under an open proxy and their originating IP is an open proxy (IP address hidden) and their accounts abuse their power (e.g. spamming links to external sites, creating attack pages, serious/persisting vandalism, etc), they should have their block parameters as account creation blocked, including logged-in users. So all the proposals are good, and so even if an indef block is absolutely needed, autoblock disabled is the priority, and people should be able to create accounts that don't abuse the wiki. That's why indef blocks are completely NOT beneficial to legitimate users who are stuck in a proxy block so they can edit. If course, those accounts should be verified as legitimate, if not then it follows the same procedure (warning, blocking, locking) to protect our wiki farm. --OwenFung87 12:13, 3 October 2019 (UTC)