跳转到内容

维基百科讨论: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”