維基百科討論:IP封禁豁免

就添加mw:Extension:ContactPage輔助申請徵求意見

社群正在就添加mw:Extension:ContactPage輔助申請一事徵求廣泛意見，現邀請關注維基百科:IP封禁豁免方針的用戶參與討論。--路西法人 2024年2月17日 (六) 01:53 (UTC)

關於IPBE申請的問題

哈囉大家好，我是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

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封鎖豁免權授予者方針

於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封禁豁免？

如題，剛在英文那邊，看到有小問題就想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)

奇怪，我當時就有收到wikiwikimedia.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)

改為{{@}} ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年9月20日 (五) 02:20 (UTC)