跳转到内容

维基百科讨论:IP封禁豁免

页面内容不支持其他语言。
维基百科，自由的百科全书

就添加mw:Extension:ContactPage辅助申请征求意见

社群正在就添加mw:Extension:ContactPage辅助申请一事征求广泛意见，现邀请关注维基百科:IP封禁豁免方针的用户参与讨论。--路西法人 2024年2月17日 (六) 01:53 (UTC)[回复]

关于IPBE申请的问题

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2024年7月20日 (六) 08:14 (UTC)。[回复]

哈啰大家好，我是IPBEG，我想就以下几个问题请社群讨论，给予我们明确的共识，这个是我个人发起的讨论，并没有与其他授予者讨论，希望大家尽量参予。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

不强迫备案WP:RFR/IPBE

目前的情况是都会备案到权限申请，我希望可以不强迫，应该说不知道从何时开始有了惯例会备案至权限申请，事实上日志都写得很清楚，这个备案会让我们多一个步骤，备案时所描述的内容事实上并没有提供到多大的帮助，邮件列表只有订阅相关邮件列表的人才能查询。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

  • @ASid：我在一些比较重要的操作的情况下会备案。备案相比日志确实能够起到公告的作用。但是IPBE这种非常日常的操作，不备案我觉得没有问题。我赋权IPBE的时候统统没有备案。Bluedeck 2024年8月5日 (一) 17:16 (UTC)[回复]

授权标准

目前基本上都是授予永久权限，各位应该有注意到我授权会经常授予临时权限，这是因为有人反映说授权过于宽松，所以我希望可以针对这一部分进行讨论，在不使处理变繁杂的情况下，兼顾标准的部分。有关于这一部分我是希望本地恢复CU，交由CU来定期随机查核使用者是否确实有需要用到IPBE，不是授予者与管理员们提高标准，即便提高也无法防止有意骗取IPBE的使用者。--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

我理解有一些人可能会觉得这个讨论有点多余，然而我的目的是在于确保社群有一定的共识，不会单方面变更后有人跳出来说，你怎么这么做你应该这么做：​（--~~Sid~~ 2024年7月9日 (二) 14:33 (UTC)[回复]

稍微解释一下为什么是永久权限。曾经首次授权一般都是临时权限的，但是后来发现没有太多意义。基本上所有到期之后还想要继续编辑的都会申请续期，这里也没有太多可以审查的东西，基本上遇到申请都会转成永久权限。所以没有续期的那些，也就是没有实际编辑，到了时间就忘了的人。这部分人的除权，现在由机器人自动执行。所以永久权限和首次的临时权限本质上区别也就不大了，而且还减少处理的负担。这部分是有过讨论的，找一下的话应该是可以找到讨论的。--Tiger（留言） 2024年7月9日 (二) 14:45 (UTC)[回复]
感谢Tiger。--~~Sid~~ 2024年7月10日 (三) 06:46 (UTC)[回复]

Unblock-zh.org

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2024年9月8日 (日) 16:14 (UTC)。[回复]


Unblock-zh.org网站的样子

很久以前讨论过的一个项目，也就是unblock-zh的网站版，我最近给他做出来了，如果对测试版软件感兴趣的话，请去 https://unblock-zh.org 这里去看看。（注意测试版软件，你的用户最后很可能被删掉！）7月7日update：软件进入试运行阶段，此时产生的工单等数据将永久保留。Bluedeck 2024年7月8日 (一) 19:21 (UTC)[回复]

附带一个教学视频 https://www.youtube.com/watch?v=IImfyNnRB4M

目前站外用户申请账户的方式是Wikipedia:账号请求发送邮件，其实也没有太不方便。但是这个途径我觉得还是更直观一点，比邮件列表好用一点，尤其是管理员处理的时候。我的想法是网站可以和邮件列表并存，或者以后达成互联。欢迎提出意见。Bluedeck 2024年4月29日 (一) 04:05 (UTC)[回复]

PS. 已经收到tigerzeng的意见，允许用户自定义提供的IP地址字段，以解决部分代理的问题。Bluedeck 2024年4月29日 (一) 04:22 (UTC)[回复]
超 英 赶 美 —— Eric Liu 創造は生命（留言・留名・学生会） 2024年4月29日 (一) 08:09 (UTC)[回复]
我最期待的画面出现了。--AT 2024年4月29日 (一) 09:14 (UTC)[回复]
好吧，终于把这个弄出来了——是蓝桌弄的？那就不出奇了。👍 赞——Sakamotosan路过围观 | 避免做作，免敬 2024年4月29日 (一) 09:29 (UTC)[回复]
非常好UX。至于是否方便了用户，我好奇能否在合理的范围内收集一些统计数据作对比，这样最有说服力。--碟之舞📀💿 2024年4月29日 (一) 14:10 (UTC)[回复]
另外这个工具让我想到了我很久之前做的维基媒体服务器连通性面板。--碟之舞📀💿 2024年4月29日 (一) 14:37 (UTC)[回复]
非常好软件。
不必要的功能建议：1.通过遍历封禁日志的摘要有无对应模板，显示是否是ip封禁。2.通过接口调用在界面一键创建账户（和授予ipbe？）
另外问一下数据托管在哪里？将来投入使用的话需要作为存档使用，所以数据需要备份好。--落花有意12138 2024年4月29日 (一) 14:42 (UTC)[回复]
一键创建账户/授予PIBE的话，有两种途径。第一，管理员通过oAuth授权unblock-zh.org，通过管理员账户操作，然后从本地日志看来，操作者是管理员。第二种途径是，成立一个机器人账户，比如名叫 unblock-helper-abot，并且赋予机器人管理权限，然后通过机器人操作，并在摘要里说明是根据哪个管理员的指令操作的。让我来决定的话，我倾向于使用第二种方式，因为我希望尽量不要向第三方授权我自己的账户，但是第一种方式的日志更加清晰。请问一下其他人的想法。Bluedeck 2024年4月29日 (一) 17:39 (UTC)[回复]
使用OAuth可以只需要简单的身份识别获得权限，用于确认是不是登录系统的对应是wiki的哪个用户。然后代理操纵的机器人可以标记操作人员的wiki用户名（通过前面获得的信息）。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:33 (UTC)[回复]
如果不改变单管理员授权模式，我倾向于第一种，这样和原先的工作模式保持一致，便于查询。
mw:OAuth/For_Developers称应用做的操作会有标签。--落花有意12138 2024年4月30日 (二) 11:04 (UTC)[回复]
在这里没有看到可以使用oauth给用户添加组别的选项，那么也是说IPBE的授予只能透过abot进行了。Bluedeck 2024年5月1日 (三) 21:41 (UTC)[回复]
的确只能这样。——Sakamotosan路过围观 | 避免做作，免敬 2024年5月2日 (四) 03:40 (UTC)[回复]
咱好像记着这种权限似乎不需要特别勾上某个选项就默认拥有，您要不尝试一下？ Stang★ 2024年5月8日 (三) 01:14 (UTC)[回复]
真的假的，在授权的时候不声明却可以操作改变用户组这么重要的操作？如果是真的那也是个bug吧 Bluedeck 2024年5月11日 (六) 08:40 (UTC)[回复]
用API能查IP有没本地封或者全域封，好像不是必要。——Sakamotosan路过围观 | 避免做作，免敬 2024年4月30日 (二) 02:26 (UTC)[回复]
👍 赞👍 赞👍 赞 牛逼--Dnaimfz（留言） 2024年5月11日 (六) 04:04 (UTC)[回复]
@Bluedeck：话说可给管理员布告板抄送一份通知连结至此？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月1日 (六) 08:43 (UTC)[回复]
@Bluedeck：想好奇请问是否有考虑过部属在wikitech:Help:Cloud VPS？如果有，为什么不选择部属在该处？--SunAfterRain 2024年6月4日 (二) 09:30 (UTC)[回复]
管理员通告版：不知道效果会怎么样啊。等上线后在ASN通告一下，然后TG呀IRC呀广播一下应该就行。CloudVPS：他的介绍说自己是标准的VPS，但是又有迹象表明他不是完全标准的环境，导致我不想把时间花在部署，测试，更换环境，以及踩坑上面。对我来说，写软件是趣味十足的事情，而调试环境则是让我胃肠不适的事情。目前我没有换环境的需求，因为开销太小。如果有我再考虑cloudvps。cloudvps的另一个问题是只有在virginia有DC，但这不是一个大问题。Bluedeck 2024年6月8日 (六) 04:00 (UTC)[回复]
以我个人看法，部属在CloudVPS的隐私疑虑绝对会比一个外部网站好很多，当然你维社群愿意接受那我也没什么意见就是了。虽然不清楚是笔误还是什么的，如果开销太小的话我自己是会考虑换过去啦。--SunAfterRain 2024年6月10日 (一) 17:54 (UTC)[回复]
可以理解你所说的。我可以把cloudVPS当作一个长期目标，最终迁移到那上面去。Bluedeck 2024年6月14日 (五) 05:29 (UTC)[回复]

试运行

在过去的几周里，我增加了最后的一些的功能，分别是1）按日期搜索排列工单；2）邮件回复模板；3）管理员删除工单、删除消息界面；4）用户改名功能。我想知道大家觉得还缺少哪些网站本身的功能（邮件服务器、机器人授予IPBE除外）。如果感觉差不多了，那么可以进行试运行。试运行期间，再对可能发现的新的功能需求进行补充。试运行的提议正在进行公告。如果通过，将会将网站首页文字改为试运行，并暂时移除一些只具有展示效果的链接，然后在用户无法注册的提示页面加入网站的链接，这些操作大概最多需要一天就能完成。在试运行决议通过前，如果对网站有任何问题，欢迎在此讨论。Bluedeck 2024年5月13日 (一) 23:30 (UTC)[回复]

功能方面，个人认为管理员不应该有删除工单的能力，这个应该由维护者来做，比如遇到spam/扰乱性工单就打上相应的标签，若干天后自动删除；可不可以出个statistics大概写一下某月某人处理了多少工单之类的；反spam方面怎么样，你觉得需要加个recaptcha吗；模板建议是放到Github或者类似公开的地方，需要改的人发pr；可以考虑加一个link/merge功能么，比如一个用户就一个问题发了多个ticket，这个时候可以把它们关联起来；感觉可以把login改的小一点，或者让非管理人员意识到不需要登录就可以发ticket。
另外就是建议放到toolforge或者cloud VPS上。顺便问个问题，你觉得这个系统需要承担unblock-zh最原始的封禁申诉职能吗 Stang★ 2024年5月14日 (二) 01:47 (UTC)[回复]
  • 谢谢提议！简短回应：
  • 删除工单就是为了应对扰乱才设计的功能。删除之后可以恢复或检视。（UI需要另外添加）工单的永久保留或删除问题在下面讨论。
  • 反spam：UTRS目前是阻止同一个IP地址多次发送工单。但是我的方案不记录IP地址，无法阻止。我可以考虑一下记录ip地址的hash，并由此进行rate limit。我个人完全不喜欢captcha，除非不得已，我可能会考虑上captcha。在此之前我会尽量用其他手段处理spam问题。我有一些asymmetric proof of work的方法能防止自动化的spam。如果有人无聊到要手工spam，那么唯有记录IP并进行区段查封这一个办法。（但是这样一来，不就把本身的目的给击败了？？）
  • 邮件模板：我不会放在github，毕竟不是每个管理员都会开PR，我简单的开一个用户页面存储目前的模板，谁想添加，给我留个言即可。邮件模板都是非常简单的纯文字模板。当然，如果你喜欢用gh，那么在前端的repo里有一个文件，你也可以直接PR这个文件。
  • link/merge：race condition太多，最多做成stack overflow/github issues那样，“标记为#109的duplicate。关闭”这种解决方案。
  • login改小：我肯定会让新用户看到不login就能发工单，这是一个重要的因素。
  • statistics：这个我一定会做，因为这会让处理工单变得很有趣，我的设想是做一个leaderboard，能够激发人们对于处理工单的无限潜能，哈哈哈哈。
  • Hosting：toolforge不能满足我的要求，CloudVPS不熟悉。将来打算支持图片上传，需要一个能挂载S3的环境，另外多区域host允许你把服务器托管在东京/首尔/LA。目前，服务器托管在Vultr的新泽西区上面。
  • 这个网站做成网站的形式，是为了新用户方便的注册+IPBE（也就是unblock-zh-ipbe的功能）。处理被长期封禁的用户在邮件列表中50-100封邮件那么长的申诉，并不是网站初衷。如果有人就是要在网站上申诉，管理员也选择在网站上处理，那我不会站出来阻止，但是如果网站上出现了对维基百科历史有一定意义的讨论内容，我觉得有应当抄送一份到邮件列表。
Bluedeck 2024年5月14日 (二) 04:12 (UTC)[回复]
update: 已经增加了查看和恢复已删除工单的功能。Bluedeck 2024年5月19日 (日) 06:40 (UTC)[回复]

另外还有两个别的需要讨论的问题：

  1. 工单是否永久保存？永久保存是目前的默认，而且邮件列表也是永久保存的。但是我觉得比如挂上“处理结束”标记90/180天之后永久删除相关信息这个是更安全的做法，想征求一下大家的意见。
  2. 开源：从一开始我就设想开源。这个项目有4个repo，其中3个可以在最近开源。一个需要我检查一下有没有API Key之类的物品遗落在代码中，然后才能开源。请期待。
  3. 共同参与：如果您想共同参与开发，或者参与对服务器的运维，欢迎在这里提出来。Bluedeck 2024年5月14日 (二) 04:49 (UTC)[回复]
感谢贡献，整体非常完善。如有需要可以协助维护。--Borschts™ 欢迎外带一碗罗宋汤 2024年5月14日 (二) 13:32 (UTC)[回复]
存档应保留，只是可以限制普通使用者存取。另外，也应考虑先行在站内撰写说明页面，或补充现有方针与指引不足，以便利用。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年5月14日 (二) 15:05 (UTC)[回复]
注意到两点可以改善：
  • 无法创建账号者不应提供“我不想提供邮箱”的选项，创建账号时需填写对方电邮地址才能安全发送临时密码。如果不想提供邮箱则难以协助创建账号。
  • 需要添加提示文字，若不提供IP地址则申请有可能不获受理（始终审批IPBE时需要验证用户是否使用proxy）。
--路西法人 2024年5月15日 (三) 07:52 (UTC)[回复]
我脑海中预想的不提供邮件的处理方式：网站生成一个强的随机密码并记录在工单中，用户通过随机密码登入。优点：用户不需要邮箱地址。缺点：不提供邮箱的用户等于需要不断的刷新页面查看处理进度，是一个糟糕的体验。对于管理员，需要复制粘贴网站生成的密码来创建账户，也是多了一个步骤。上面我只是说明了操作的可行性，至于这个功能是否保留，可以继续讨论决定。对于第二点，IPBEG如果有这个要求，那我完全可以添加这个提示文字（甚至可以在维基百科设置一个页面，比如Template:Unblock-zh/strings/new-ticket-notice，然后网站可以反映这个页面的任意文字。）Bluedeck 2024年5月19日 (日) 06:22 (UTC)[回复]
我的想法是只要有任何第三方人员可以接触到任何密码的方案都是不安全的，尤其在发送邮件时在此类第三方网站留存临时密码亦是相当危险的；即使我信任你会尽力保障网络安全，但显然不安全的操作应尽可能完全避免。邮件、代理IP地址等都尚算不太危险的资讯，密码真的不行。--路西法人 2024年5月21日 (二) 01:25 (UTC)[回复]
我想了一下觉得你说得很有道理。如果有的用户收到临时密码后不加更改，那么等于这个用户的密码永远的挂在一个所有管理员都能看到的地方，是不妥的。我已经把界面改成如果请求账户，必须提供邮箱，否则无法提交。Bluedeck 2024年5月21日 (二) 01:50 (UTC)[回复]
一些minor的建议：about一页，Puzzle Globe似可译为“拼图球”，Wikibooks译名应为“维基教科书”非“维基图书”。不提供邮件的提示，“一串30几位的工单”应作“三十几位”。login界面没有明显的返回按钮，侧栏也消失了。lookup界面可以考虑加注工单号和邮箱择一提供即可。 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月21日 (二) 03:01 (UTC)[回复]
另外我在想让其选择点选提交IP的选项是否也应该把UA也提供给审核用户检阅（方便反破坏比对）。--路西法人 2024年5月23日 (四) 07:54 (UTC)[回复]
统一回复。1）login界面有意如此设计。2）必须同时输入工单号和邮件，否则任意人士可以通过广泛查询邮件探知私密工单。3）UA信息只有CU才能访问，所以显然不能提供。另外就算用户主动提供了，那么IPBE处理者拿什么进行比对呢？毕竟你又看不到LTA的UA。Bluedeck 2024年5月27日 (一) 06:11 (UTC)[回复]
2) 啊那就是提前提示创建工单时未提供电子邮件的须放空？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月27日 (一) 06:29 (UTC)[回复]
没有提供电邮的工单号会比较长，所以我可以改一下软件，让这种工单号不论是否输入电邮都能够正常查询。这样可以不破坏界面简洁易用。Bluedeck 2024年5月29日 (三) 06:45 (UTC)[回复]
好的👍 赞 ——魔琴［身份声明 留言 贡献 新手2023］ 2024年5月29日 (三) 07:32 (UTC)[回复]

将开始试运行。公示已经进行了一个多月，收集到了很多改进意见，并实施了很多更新。今天起，我将正式修改MediaWiki软件界面，在网站上标注试运行字样，并在公告栏和ASN中对社区和管理员们进行公告。Bluedeck 2024年7月7日 (日) 16:26 (UTC)[回复]

@Bluedeck：请问IPBEG们可以如何存取工单？--路西法人 2024年7月10日 (三) 03:25 (UTC)[回复]
@LuciferianThomas：我正在编写为IPBE权限持有者提供权限的功能。完成后，IPBE将获得和管理员基本一致的功能。目前编写的功能是对于下方讨论中方案一的实现。编写完成后，我将会在用户讨论页面通知IPBEG权限持有者。Bluedeck 2024年7月10日 (三) 18:46 (UTC)[回复]
@Bluedeck：能更新进度吗？--路西法人 2024年7月22日 (一) 02:49 (UTC)[回复]
现在IPBE已经能取得权限使用了，但是目前用户界面和IPBE权限能做的事情不吻合，比如IPBE无权删除工单，但是会显示删除按钮，我正在改这些小问题。Bluedeck 2024年7月29日 (一) 07:08 (UTC)[回复]
@Bluedeck：预计试行多久？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月20日 (六) 17:44 (UTC)[回复]
不知道，但是目前肯定不是一个完善的状态。比如我就发现了好多好多想要改进的地方，写在Roadmap中。Bluedeck 2024年7月29日 (一) 07:08 (UTC)[回复]
IPBEG的权限基本设置完成，测试可用，在此通知IPBEG组成员@user:AINH，@user:ASid，@user:Borschts，@user:LuciferianThomas，@user:SCP-2000，@user:だ＊ぜ。Bluedeck 2024年8月1日 (四) 01:43 (UTC)[回复]
感谢。希望未来能添加罐头回复（请求提供更多资讯如封锁讯息、已授权〔时长〕）等。--路西法人 2024年8月1日 (四) 02:21 (UTC)[回复]
是的，我自己在处理中，也发现了罐头回复的重要性。我将会加入这个功能。Bluedeck 2024年8月2日 (五) 20:35 (UTC)[回复]

繁体支援

这个网站估计主要的受众是大陆梯子人士。但是，由于很多管理员是繁体使用者，那么我就增加了一系列的繁体支援，但是都是Google翻译的。请繁体管理员看看管理界面的翻译如果有很不和谐的地方，请指出来。如有需要，网站可以支援香港、台湾和澳门繁体的分别翻译。Bluedeck 2024年5月30日 (四) 08:15 (UTC)[回复]

感谢蓝桌照顾繁体使用者，但我目前检视似乎有一些界面仍然是简体中文的，例如新建工单的部分，另查台湾的教育部字典，work order这个词在台湾可以翻译为“工令”、“工作命令”、“工作通知单”或“工作单”等，就是没有查到称之为“工单”之翻译，惟我日常生活中前开所有词汇均较为少见，平常类似功能之提交申请平台反而被称之为“电子表单”，这部分可能需要更多繁体使用者来指出正确的翻译。--小过儿（留言） 2024年5月30日 (四) 15:30 (UTC)[回复]
新建工单的繁体化已经完成。关于工单这个用语的翻译，我参考了一下asus的网站，叫做“请求支援”、“搜寻案件”。不知道这算不算合适的翻译。如果觉得“案件”听其来正确，那么我就把繁体语言的工单改称案件。Bluedeck 2024年5月30日 (四) 23:49 (UTC)[回复]
“工单”是对应“ticket”而不是“work order”，比如Zendesk香港也是叫ticket作“工单”[1]。再甚者，直接“搜寻申请”也是得了，不需要特地什么ticket不ticket的了。--路西法人 2024年6月1日 (六) 08:37 (UTC)[回复]
@Bluedeck：怎么查阅或更改翻译？—— Eric Liu 創造は生命（留言・留名・学生会） 2024年7月1日 (一) 19:44 (UTC)[回复]
通过改变浏览器的语言设置并刷新页面，可以查看不同的语言版本。目前要修改，可以直接留言告诉我哪里需要改。以后，会开放一个repo在github上可以pr。不熟悉sveltekit和github的用户仍然可以直接联系我。Bluedeck 2024年7月2日 (二) 06:00 (UTC)[回复]
理论上可以开twn（translatewiki.net） project啦，不过要担心被乱改的问题。--SunAfterRain 2024年7月22日 (一) 07:02 (UTC)[回复]

工单的永久删除

目前没有这个功能。不过，根据欧盟GDPR要求，在用户请求的情况下，应该提供一种方法永久移除其个人信息。我想让管理员能够在工单上添加一个标记，被标记的工单约一个月后真正的删除。删除真正执行前可取消。这种删除只应该在特别的情况下进行（也就是用户请求）。（也可以单独只允许行政员执行真正删除，但是我觉得管理员已经足够可信，并且还有一个缓冲期间。）Bluedeck 2024年5月31日 (五) 23:04 (UTC)[回复]

这个功能不错。( π )题外话：我想知道维基百科不能删除账号是否符合GDPR，以及即使OS似乎也不是真删除，这是否符合GDPR。有人去举报一下是不是基金会就会实现这个功能了。--桐生ここ★[讨论] 2024年5月31日 (五) 23:25 (UTC)[回复]
应该是不符合的，而且显示未登录用户ip这个似乎也有一定问题。然而我们要团结一致，不要把基金会举报给欧盟。Bluedeck 2024年6月1日 (六) 05:34 (UTC)[回复]

让 IPBEG 在 Unblock-zh 上获得和管理员一样的权限

因为我觉得 IPBE 也是一大痛点，所以我觉得让 IPBEG 能够一起帮助处理会大有裨益。现在抛出几个方案讨论：

  1. 让IPBEG组和管理员同在unblock-zh.org/zhwp下有一样的（或者接近的）权限。
  2. 像邮件列表一样，单独新建 unblock-zh.org/zhwp-ipbe空间。
    1. 网站面向用户的界面不改变，根据用户是否需要 IPBE，自动将工单分发至 zhwp 或 zhwp-ipbe
    2. 网站设计改变，入口页面一分为二，用户需要自己选择是投递给zhwp还是zhwp-ipbe
  3. 不支持 IPBEG。

我觉得，从用户体验的角度，不希望入口一分为二。另外，不管选择 1 还是 2，都需要一段时间来修改网站的代码，但是 2 所花时间会更久一点，并且会增加日后维护的工作量（主要是会出现两套表单同步的问题）。关于用户隐私，由于 IPBEG 是签署 NDA 的，应该视为可信人员，所以我比较倾向 1。Bluedeck 2024年6月1日 (六) 09:25 (UTC)[回复]

设立IPBEG的本意就是许可IPBEG处理该类申请邮件，理论上可以说已有社群共识支持选项2，但已有共识未必支持选项1。IPBEG不能处理unblock-zh上非申请IPBE的工单。我是认为，一般而言封锁申诉本应都是在公开场合发起，申诉内容多数都应该可被所有用户检视，实质需要使用邮件申诉封锁的仅有无法编辑讨论页的情况。如你所言，IPBEG本有签署NDA，就算看了也不应该会造成什么问题（虽然能避免最好）。如果是最后采用最简化的选项1，那我觉得您可以最低限度在处理人员的界面中加入标签工单的功能，让IPBEG能明确标记跟他们职务无关的申请，从IPBE队列隐藏，仅能由添加标记的IPBEG（直至工单标签被管理员确认）及管理员检视。--路西法人 2024年6月2日 (日) 11:58 (UTC)[回复]
如果要让IPBEG不能看到非IPBE工单，那应该执行方式2更优。如果执行方式2，那么管理员、行政员也应该自动获得zhwp-ipbe空间权限，并进行工单自动分发。Bluedeck 2024年6月3日 (一) 08:34 (UTC)[回复]
不是“不能看到”，而是“不再跟IPBE有关的就没必要继续显示在同一队列，令其他正在处理IPBE申请的用户不小心点进去”。“看到”大概是不会有什么大问题的。--路西法人 2024年6月5日 (三) 02:22 (UTC)[回复]
分成两列或许方案2实现起来更简单？--桐生ここ★[讨论] 2024年6月5日 (三) 09:51 (UTC)[回复]
不是不行，但必须考量没签署NDA的管理人员是否有权限接触unblock-zh内的工单，一般视乎工单是否涉及IP地址等可辨识资讯。如果要再这样分就分成三列了。--路西法人 2024年6月6日 (四) 00:04 (UTC)[回复]
还是那句话，我无法理解WMF要求邮件列表内的IP必须有签署NDA才能接触，但允许使用unblock模板直接把IP公开。--桐生ここ★[讨论] 2024年6月6日 (四) 09:48 (UTC)[回复]
我一开始听说IPBEG需要NDA，但管理员不需要NDA的时候，我也觉得很费解。而且你知道吗，你用的任何JS组件要是对外部资源进行请求，那么就可能有意无意泄露IP。甚至你收到一封邮件，邮件里带个图，这图也能泄露IP。虽然说IP在wiki上被当作隐私，其实整个互联网对IP的保护可以用奇差来形容。Bluedeck 2024年6月8日 (六) 04:05 (UTC)[回复]
似乎是祇有涉及IP等隐私资讯时，才要求管理员签署相关协议。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月23日 (日) 02:13 (UTC)[回复]
@Bluedeck：只要不僭越社群赋予之权限，应尽可能以您自身方便为宜。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年6月6日 (四) 00:11 (UTC)[回复]

提供的IP问题

现在有个问题

  • 如果申请者没有使用代理时使用此网站提交工单，被此网站自动带入的IP是其真实IP，而非使用代理且受到IP封禁的IP，对于IPBEG应该使用真实IP还是受到封禁的IP判断？如果有人使用代理访问此网站，有人不使用代理访问此网站，也会产生差异。
  • 是否像传统邮件列表一样另外要求用户手动填入封禁界面上显示的受封禁的IP或封禁ID？这样也有好处，就是IPBEG可以看到申请者被封禁IP同时也能看到真实IP，确定申请者处于中国大陆等受限地区。但产生另外一个风险，就是如果确实提供的是中国大陆IP地址，一旦泄露可能产生严重后果。--桐生ここ★[讨论] 2024年6月6日 (四) 10:00 (UTC)[回复]
    • 技术上有很多方法可以尽量避免记录IP，比如只记录部分IP、以及对管理员不显示IP，只显示IP是否处于封禁列表中。但是这些方法无一例外的会对管理员处理造成问题。我想到的各种方法中，只有一个值得实践的，是在工单解决之后将IP相关信息从工单中清除，避免永久留存。除此之外，就只有请管理员和IPBEG不要泄露IP地址。对于代理的问题，我可以加一个提示让用户记得开代理，再者就是干脆取消自动侦测IP这个功能，让用户自己填写IP和查封ID，和邮件列表保持一致。Bluedeck 2024年6月7日 (五) 07:43 (UTC)[回复]
      我有一个方案
      • 申请者不提供IP：不提交IP
      • 申请者选择提供IP：检测IP是否中国大陆或其他受限地区
        • 是：不提交IP地址，只自动提交申请者IP地区，并且要求申请者手动填写受封禁IP
        • 否：自动带入IP地址
      --桐生ここ★[讨论] 2024年6月7日 (五) 09:10 (UTC)[回复]
      补充：IP地区是提交由服务端判断，而不是在前端处理，所以实际上仍然会提交中国大陆IP，只是不会储存在服务器上。--桐生ここ★[讨论] 2024年6月7日 (五) 09:13 (UTC)[回复]
      检测IP是否中国大陆或其他受限地区 这个感觉不是长久之计，GFW未来可能会给Unblock-zh上SNI封锁，用户会不得不套代理访问，这样Unblock-zh获取到的就不是真实IP--Yuki Rutygr (留言) 2024年7月9日 (二) 13:15 (UTC)[回复]
      • 我想过geoip定位这个方案，但是ip定位数据库需要每个月更新，而且并不完全准确。连维基媒体基金会都放弃了自己的geoip API（否则我就可以利用了）。有一个折衷办法，那就是查询封禁数据库。如果用户目前的IP不再封禁列表中，大概率说明没有开代理，此时我弹窗提示开代理。Bluedeck 2024年6月7日 (五) 19:59 (UTC)[回复]
(－)反对，考虑到Unblock-zh未来极有可能受到GFW封锁。--mije meli carrot_233 -- 讨论 2024年7月25日 (四) 11:33 (UTC)[回复]
网信办说的？ ——魔琴［身份声明 留言 贡献 新手2023］ 2024年7月25日 (四) 15:07 (UTC)[回复]
这种网站大概率被墙。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:42 (UTC)[回复]
这反对理由太怪了，你维本来就被GFW刀了，有差吗？--SunAfterRain 2024年7月27日 (六) 04:23 (UTC)[回复]
问题在于，如果Unblock-zh被GFW封锁，则中国大陆无法直连Unblock-zh，故无法获取真实IP。--mije meli carrot_233 -- 讨论 2024年7月30日 (二) 07:41 (UTC)[回复]
我们本来就不是为了获取用户的国内IP，因为目前邮件列表也只是看到你的查封ID和IP地址就对你进行授权，这被查封的IP地址往往都是VPN、代理地址。如果被墙后，还能解决代理不是全局的问题。因为没有被墙，有的代理会把没被墙的网站不走代理，导致我们接收到用户的没有被查封的IP地址，反而不是我们想要的。Bluedeck 2024年7月30日 (二) 16:50 (UTC)[回复]

罐头回复

经由路西法人的建议，增加了‘罐头回复’功能。将常用的语句加入罐头回复列表，就能快速的一键回复工单。详见WP:Unblock-zh.org#罐头回复功能 Bluedeck 2024年8月12日 (一) 21:51 (UTC)[回复]

`ChooseNewName`标签

这是一个比较新的功能，当请求用户选择新的用户名时，加入`ChooseNewName`标签，同时摘掉`回复关闭`标签的情况下，工单用户界面会多出一个小工具，便于用户确认自己所选择的用户名是否可以注册。Bluedeck 2024年8月20日 (二) 08:16 (UTC)[回复]

长期维护展望

本站不乏一工具或机制，于原维护者隐遁后即生极大之运行困难。若来日Bluedeck不再活跃，此工具是否有办法由他人接手维护？有必要提前考虑。—— Eric Liu 創造は生命（留言・留名・学生会） 2024年8月29日 (四) 10:14 (UTC)[回复]

修订IP封禁豁免及IP封锁豁免权授予者方针

本主题或以下段落文字，移动自Wikipedia:互助客栈/方针。执行者：Jimmy-bot（留言） 2024年9月20日 (五) 16:14 (UTC)。[回复]

于Phabricator查看
编号T374504的工单
状态：已解决
IP封禁豁免

由于Unblock-zh.org已经试营运近50日，本人现在提出修订现有IP封禁豁免方针（WP:IPBEPROXY部分），详细修订条文见下：

原条文

用户可在维基百科:权限申请/申请IP封禁豁免权提交申请，若无法编辑该页则应发送电邮至wikipedia-zh-ipbe邮件列表。

修改后的条文

用户可在维基百科:权限申请/申请IP封禁豁免权提交申请，若无法编辑该页则应透过发送电邮至wikipedia-zh-ipbe邮件列表或者在Unblock-zh.org建立工单申请。

--Benho7599 | Talk 拥护以李家超同志为核心的党中央 2024年8月26日 (一) 11:07 (UTC)[回复]

提案OK的。对了我有个不请之情，我做为IPBEG处理的IPBE申请相对于其他IPBEG是多很多的，再处理的时候我发现有时会需要调整IPBE的期限，然而碍于User:Xiplus/unblock-zh-helper-gmail小工具尚未有选择IPBE期限的原因，导致必须使用Special:Userrights手动给予有期限的IPBE，加上一直以来社群有个声音是希望适当的提高标准，参考其他站点meta的GIPBE或enwiki的IPBE都是给予有期限的，我希望可以给予IPBEG权限组移除IPBE的权限，以利在申请是需要赋予短期IPBE的申请时，IPBEG使用User:Xiplus/unblock-zh-helper-gmail赋予永久权限后可以直接透过Special:Userrights调整IPBE的期限，当然我知道社群有一部分人会忧心IPBEG会滥权但我想经过如此长的时间，社群对现任的IPBEG都已有相当的认识，应该是不太需要担心会有滥权的情况发生，即便有新的志愿者申请成为IPBEG我想社群也是使用高标准在看待的，这理论上来说也不太需要担心。
至于方针的部分则是软性规定（透过方针规范），非硬性（透过技术层级限制），仅允许IPBEG在申请有需要赋予短期权限时才可更改，不得用于处理WP:RFDR的除权申请。@AINH、Borschts、LuciferianThomas、SCP-2000、だ＊ぜ：不好意思打扰各位，由于我的意见与各位有相关所以想请各位过来讨论，如有打扰还望见谅，谢谢。
以上请社群考虑一下我的意见，十分感谢。--~~Sid~~ 2024年8月26日 (一) 14:49 (UTC)[回复]
@Hoben7599：哈啰打扰了，我上面的意见如果可以的话希望您可以顺便推动一下，如果社群同意这么做的话。--~~Sid~~ 2024年8月26日 (一) 14:53 (UTC)[回复]
(＋)支持。使用该网站较为方便。--WiiUf ——青龙出世，傲视苍穹 的第1000次编辑！ 2024年8月29日 (四) 04:58 (UTC)[回复]
IP封锁豁免权授予者

现在提出修订现有IP封禁豁免权授予者方针，详细修订条文见下：

原条文
  • 不受速率限制影响（noratelimit）
  • 强制为全域账号创建本地账号（centralauth-createlocal）
  • 添加用户组：IP封禁豁免者
  • 移除自己账号的用户组：IP封锁豁免权授予者
修改后的条文
  • 不受速率限制影响（noratelimit）
  • 强制为全域账号创建本地账号（centralauth-createlocal）
  • 添加用户组：IP封禁豁免者
  • 移除自己账号的用户组：IP封锁豁免权授予者
  • 移除被授权用户权限组：IP封禁豁免者（不得用于处理除权申请，仅可变更无需长期或永久IP封锁豁免的用户的豁免权限为短期权限、或移除错误的授权）

--Benho7599 坚决拥护以芙宁娜同志为核心的枫丹 2024年8月26日 (一) 15:27 (UTC)[回复]

谢谢你的帮忙，不好意思我这部分没有说清楚“仅允许IPBEG在申请有需要赋予短期权限时才可变更”，我这部分是指说IPBEG仅可因申请信件缩短IPBE期限（例子：IPBEG在处理申请时遇到一位需要赋予短期权限的人，先透过Xiplus开发的小工具一键建立账号、赋权（此处会是永久赋权，原因是小工具尚未有选择IPBE期限的功能）与用户讨论页通知，再直接透过Special:Userrights更改为短期权限即可），不是指说仅可移除短期的IPBE，抱歉让您误会了。
我建议可以写成“不得用于处理除权申请，仅可变更无需长期或永久IP封锁豁免的用户的豁免权限为短期权限，或移除错误的授权”会比较好，当然这么写会让不清楚IPBE处理状况的人看到会觉得有点奇怪。--~~Sid~~ 2024年8月26日 (一) 16:14 (UTC)[回复]
已订正--Benho7599 坚决拥护以芙宁娜同志为核心的枫丹 2024年8月27日 (二) 02:21 (UTC)[回复]

最后留言距今已有五日，就Hoben7599君提请的修订 公示7日，2024年9月10日 (二) 14:20 (UTC)结束--人间百态,独尊变态(讨论) 2024年9月3日 (二) 14:20 (UTC)[回复]

公示通过，已修改方针。--人间百态,独尊变态(讨论) 2024年9月10日 (二) 14:41 (UTC)[回复]

问一下，现在在哪里申请全域IP封禁豁免？

本主题或以下段落文字，移动自Wikipedia:互助客栈/其他。执行者：Jimmy-bot（留言） 2024年10月1日 (二) 08:14 (UTC)。[回复]

如题，刚在英文那边，看到有小问题就想fix一下，结果受到IP封禁影响（我显然是登陆状态下，也显然我这是本地豁免？）废了老大的劲才找到一个可用的...为了避免这种窘境，还是申请一下算了（记得我几年前去英文的时候不这样啊）--我是火星の石榴（留言） 2024年9月18日 (三) 11:37 (UTC)[回复]

全域的在m:Steward requests/Global permissions，即使申请了全域，好像英维也还需要单独申请。--Kethyga（留言） 2024年9月18日 (三) 12:05 (UTC)[回复]
中英俄、波斯语等维基百科均在本地封禁已知开放代理，部分语言的维基教科书等站点也采取此策略。——暁月凛奈 (留言) 2024年9月18日 (三) 13:15 (UTC)[回复]
封禁申诉票证系统处理速度挺快的——即请秋安 ZhaoFJx(论•签) 2024年9月19日 (四) 01:29 (UTC)[回复]
遗失了key怎么办？--Txkk（留言） 2024年9月20日 (五) 01:21 (UTC)[回复]
Email里应该有回执，查查收件箱和垃圾信息里有没有——即请秋安 ZhaoFJx(论•签) 2024年9月20日 (五) 01:23 (UTC)[回复]
我没看到什么回执邮件。我给UTRS 2的管理员发过邮件，他们也没搭理我。--Txkk（留言） 2024年9月20日 (五) 01:29 (UTC)[回复]
奇怪，我当时就有收到wiki@wikimedia.org发来的确认单。要不你看看浏览器历史记录？说不定也能找到。实在不行就消极方案，等一段时间后可能就处理好了。——即请秋安 ZhaoFJx(论•签) 2024年9月20日 (五) 01:48 (UTC)[回复]
这都是去年的事了 捂脸--Txkk（留言） 2024年9月20日 (五) 02:17 (UTC)[回复]
作为不保留好key的惩罚，再提一个工单吧——即请秋安 ZhaoFJx(论•签) 2024年9月20日 (五) 02:22 (UTC)[回复]
一个账号只能提一个工单。--Txkk（留言） 2024年9月20日 (五) 02:24 (UTC)[回复]
要不我去全域IP封禁豁免申请页手动帮你提交一个章节？——即请秋安 ZhaoFJx(论•签) 2024年9月20日 (五) 02:26 (UTC)[回复]
谢谢。--Txkk（留言） 2024年9月20日 (五) 03:51 (UTC)[回复]
meta:Steward_requests/Global_permissions#Global_IP_block_exempt_for_Txkk——即请秋安 ZhaoFJx(论•签) 2024年9月21日 (六) 03:24 (UTC)[回复]
meta有封锁代理吗？
我使用vpn时从来没有遇到过被meta封锁的情况。--Miyakoo（留言） 2024年9月20日 (五) 06:54 (UTC)[回复]
有哦，我手上就拿着两年期的meta IPBE ——魔琴［身份声明 留言 贡献 新手2023］ 2024年9月20日 (五) 07:58 (UTC)[回复]
只要等3、4天就可以再次提交了吧。--Miyakoo（留言） 2024年9月20日 (五) 06:45 (UTC)[回复]
@Miyakoo、ZhaoFJx 似乎是因为没有任何管理员处理我的工单导致我不能提交新工单（猜测）。--Txkk（留言） 2024年9月20日 (五) 12:35 (UTC)[回复]
检索自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:IP封禁豁免&oldid=84420657”