說明討論:如何訪問維基百科

Android（移動）端的直接連接方法

似乎#直接連接方法中的所有方法都只能在電腦上使用？有沒有能在Android端使用的類似方法？（注意，我指的不是使用代理服務器的方法）--Wnotieagusdr（討論 | 貢獻） 2024年2月1日 (四) 06:10 (UTC)

見「本地代理工具」，Accesser可以在Termux中運行[1]，然後你要配置瀏覽器使用http://localhost:7654代理。--Shinohara Chihiro（留言） 2024年2月1日 (四) 07:23 (UTC)

我不太會用，還遇到了問題……先問一下我的操作對不對：一行一行地輸入這個鏈接中的命令。但這樣，我在執行python -m pip install -i https://mirrors.bfsu.edu.cn/pypi/web/simple --upgrade pip時遇到提示（紅色字）：

ERROR:Installing pip is forbidden, this will break the python-pip package(termux).

這該如何是好……

--Wnotieagusdr（討論 | 貢獻） 2024年2月3日 (六) 07:17 (UTC)

這段錯誤是因為Termux不允許pip自己更新自己，只允許通過其pkg包管理器更新它。這行命令不是必要的，你可以直接略過。--Shinohara Chihiro（留言） 2024年2月3日 (六) 09:37 (UTC)

抱歉啊，作為非專業人士，我覺得在沒有一個系統的教程或者便捷的方法的情況下，我可能是沒法完成了（笑）。我把每一步都做了，最後卻連網都連不上了，說是要驗證什麼的（或許是安裝證書或者配置代理的問題……所以我覺得我可以暫時放棄了233，感謝您的指導。--Wnotieagusdr（討論 | 貢獻） 2024年2月13日 (二) 12:04 (UTC)

@Wnotieagusdr：你應該不是在瀏覽器，而是在WLAN設置里添加代理的，才會讓系統誤以為網絡需要認證。如果你的瀏覽器沒有設置代理的選項，可以試試這個[2]，在其「設置」的「隱私和安全」中找到Proxy configuration，然後選擇Use a single proxy，填入PROXY localhost:7654，然後Apply就可以了。--Akishima Yuka（留言） 2024年2月13日 (二) 13:21 (UTC)

然後需要讓瀏覽器信任Accesser的證書，先去系統設置的隱私和安全中安裝Termux應用目錄中的root.crt作為CA證書，然後去Cromite瀏覽器的Cromite flags list中啟用Allow user certificates。--Akishima Yuka（留言） 2024年2月13日 (二) 13:25 (UTC)

@Akishima Yuka：感謝，我照做了，但是我如果訪問zh.wikipedia.org，瀏覽器就提示「您的連接不是私密鏈接」（NET::ERR_CERT_AUTHIRITY_INVALID），Termux中提示ssl/tls alert certificate unknown (_ssl.c:1006)。我懷疑是證書安裝有問題，我是在 系統設置-安全-更多安全設置-加密和憑據 里安裝的，在其中的 受信任的憑據-用戶 里能看到叫Accesser的證書（我是HarmonyOS的系統），然而可能還是有問題……--Wnotieagusdr（討論 | 貢獻） 2024年2月17日 (六) 13:55 (UTC)

@Wnotieagusdr：

Cromite瀏覽器的Cromite flags list中啟用Allow user certificates。

在「設置」-「隱私和安全」-「Open Cromite flags list」，設置為「Enabled」。--Akishima Yuka（留言） 2024年2月17日 (六) 15:17 (UTC)

@Akishima Yuka：是的，我已經做了……--Wnotieagusdr（討論 | 貢獻） 2024年2月21日 (三) 02:00 (UTC)

🤔...--Shinohara Chihiro（留言） 2024年2月21日 (三) 05:25 (UTC)

斜坡計劃的安全補丁

先前討論：1 2

簡易流程圖

很抱歉再次提出這個計劃來打擾大家。針對先前討論中各位比較關注的安全問題（政府可能留下門戶的訪問記錄，可以與註冊日誌一一對應），在下最近想出一個解決辦法：門戶只發放臨時賬號，永久賬號轉發給IPBE授予系統處理。

大致思路是：用戶在註冊門戶註冊時，如果希望長期貢獻，可以選擇註冊永久賬號。提交申請後，門戶提供一個臨時賬號用於編者即時編輯（可以限制使用時間，如一個月，或者根據ipbe授予的積壓情況決定），同時將希望註冊的用戶名等信息發送給IPBE授予者。這樣政府可能留下的訪問記錄只能對應到臨時賬號。可以在右側查看此方案的簡易流程圖。

如果安全問題能夠解決，我覺得應該不會有太大的阻礙，希望這次能夠達到實行此計劃的共識。謝謝各位。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月15日 (四) 11:39 (UTC)

沒看懂。是自動發放一次性賬號？怎麼避免濫用。如何使門戶可信。用戶貢獻歸屬等需求。註冊日誌時間問題，隨機延遲不就行了，不過我覺得意義不大，因為訪客數量有限、網絡特徵公開。--YFdyh000（留言） 2024年2月15日 (四) 16:37 (UTC)

如果門戶是維基媒體基金會的網站，不存在什麼可信不可信。用戶貢獻歸屬，新用戶會在意這個？別人只想編輯。濫用這個詞太抽象，不知道你指的是什麼，最好說明一下更具體的情況。--日期20220626（留言） 2024年2月15日 (四) 17:00 (UTC)

1. 不看好基金會為此系統投入和有效地得出成果。這還不如研發與優化開放代理與反破壞機制的關係，使通過代理的註冊和編輯更可見和可控（Tag/每筆人機驗證/反破壞更敏感/二次審核，等等），將有益全域。
2. 如果有用戶聲稱自己用了門戶但出事，是門戶的問題（運維或網絡特徵），還是其他問題，如何解決信任危機。
3. 會的，並且牽扯到傀儡判定、條目主編者等問題。
4. 不太懂這樣做對隱藏身份的意義，IP連接有日誌，使用門戶在特定時點做出收發（及對應流量特徵）反而範圍很小。
5. 創建臨時賬號非人工審查，LTA可以用完就扔，未見反破壞機制，人工審封IP不太可靠、會誤傷。
6. 如果門戶是為保障時間點隱私，就不宜支持即時提交編輯。

--YFdyh000（留言） 2024年2月15日 (四) 19:28 (UTC)

1. 「研發與優化開放代理與反破壞機制的關係」，基金會這方面有什麼動作嗎？沒有吧。談一個不存在的事情有什麼意思。我就是顧慮基金會的人可能會比較懶，不會特地去為了中維去開發這麼一個門戶。
2. 那你等有人真的用了門戶出事情再說，不要自己去憑空臆測。本來就有人因為翻墻上維基百科被抓[3]，說明翻墻上維基百科本身就有一定風險，也沒見基金會出來說要保護或者出面去介入。
3. 傀儡判定，之前討論說允許把本地IP提供給查核員，這個可以再討論一下。不過本身在不用翻墻的地區，傀儡就可以隨意創建賬號登入編輯。非大陸地區的LTA本身就會用完賬號就扔。你看影武者都有多少賬號了。這個門戶主要面對新用戶的，新用戶不會想到條目主編者這一層面。你10年前剛編輯的時候你會考慮這個？

--日期20220626（留言） 2024年2月16日 (五) 05:23 (UTC)

1. 從基金會的開發效率及意願來說，我傾向不讓基金會做這個。維基人做這個又有信任度問題。2. 提議中的臨時賬號就是為了所謂安全，如果無所謂，IPBE申請表單系統就足夠了——維基人可以幫忙。3. 如果臨時賬號提交一份條目，註冊賬號編修，或者多個臨時賬號編寫，DYKC主編、傀儡活動怎麼算。註冊時間隱藏，聽上去需要提前註冊儲備一些臨時賬號。如果是先用後審，似乎沒意義啊。--YFdyh000（留言） 2024年2月17日 (六) 05:11 (UTC)

3. 臨時賬號的用戶名應該有特定規律，視作因為隱私問題而不公開披露sockpuppeteer的分身賬號。臨時賬號的註冊時間不隱藏，門戶界面告知使用有安全風險。如果編輯不敏感的條目或者頭鐵的自然承擔風險就是。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月17日 (六) 05:34 (UTC)

補充，我的臨時賬號想法是IPBE申請系統自動/半自動創建所請求賬號，限制有效時長和編輯次數，超出有警告與自動封禁/剝奪IPBE，配合過濾器自動封禁，之後人工審核和批准永久IPBE（類似WP:AFC）。這之前講過。我的想法中IP驗證並非必選項，甚至不考慮，但如何避免傀儡反覆註冊，暫時只想到人機驗證；答題可選；網頁版工作量證明也許會有幫助。--YFdyh000（留言） 2024年2月17日 (六) 05:22 (UTC)

這樣甚至比現行IPBE還嚴格，要知道目前IPBE授予和自動授予沒有太大的區別，如果我沒搞錯的話，如果填寫正確且用戶名不是明顯破壞者的話都會給過。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月17日 (六) 05:36 (UTC)

目前問題是處理時延太久，而我的提議為人機校驗（及其他自動檢測）後先發後審但限制編輯能力（次數和範圍），是否永久批准仍是傳統流程。--YFdyh000（留言） 2024年2月17日 (六) 05:48 (UTC)

誰會用這個門戶？當然是新用戶和一些圖謀開傀儡的被封的賬戶。如果這一門戶機制不影響查傀儡的話問題不大。--日期20220626（留言） 2024年2月16日 (五) 05:30 (UTC)

4. 永久賬號給IPBEG發，和門戶就沒關係了，也無法通過門戶來精準索敵 5. 同日期君。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月17日 (六) 05:32 (UTC)

防濫用措施的可行方案已經寫在用戶頁上，譬如設置管理員、封禁開放代理、同步封禁列表等手段。不清楚門戶可信是什麼意思，這個系統應該不會處理敏感信息，可以建議開發者開源。署名問題可以提前在註冊頁告知，臨時賬號事實上相當於IP用戶，也沒人關心IP用戶或者IP masking的臨時賬戶怎麼署名啊。隨機延遲可能有用戶名撞名的問題，其實解決這個問題也行() ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月17日 (六) 05:28 (UTC)

門戶只是申請表單的話，我之前可能想錯。臨時賬號統一命名、提前註冊，永久賬號等待審核，可能不需延遲。總感覺以IP為IPBE信任元素，很容易濫用，不過非開放代理似乎能達成相同目的。--YFdyh000（留言） 2024年2月17日 (六) 06:07 (UTC)

@魔琴、YFdyh000、日期20220626：請問考不考慮讓這討論改走RFC機制？Sanmosa _{起視四境　秦兵又至} 2024年2月16日 (五) 06:40 (UTC)

我無所謂。--日期20220626（留言） 2024年2月16日 (五) 06:42 (UTC)

太多想法未確定，為免含糊的支持/反對，目前傾向不要。--YFdyh000（留言） 2024年2月17日 (六) 05:12 (UTC)

IPBE授予員討論尚主要涉及權限方針修訂，這個初步概念應該VPO討論吧。--路西法人 2024年2月17日 (六) 06:19 (UTC)

前幾次討論都是在其他區；此案目前尚未涉及實際方針與指引修訂。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月17日 (六) 07:30 (UTC)

這樣的話，考慮到VPP這裏的長度問題已經比以前改善不少了，那就不一定要搬了。Sanmosa _{Šče ne wmerla Ukrajina, ale ne Wže woskresla Ukrajina} 2024年2月17日 (六) 08:50 (UTC)

已移動到VPO ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月17日 (六) 09:36 (UTC)

認為應該在易於申請、保護隱私和反破壞中尋求平衡。這應該是一個排序題，而不是選擇題。

應該如何給申請人分發臨時賬戶，又該如何收回？我建議使用一個獨立的表單，讓用戶提交要發送的代碼和延時時長，以達到編輯目的。

這個提案不同於大部分討論，是在商議軟件需求。我們不能寫一個複雜而模糊的需求難為開發人員，所以我們要把所有細節敲定了，再和開發人員提出。考慮到本地實際，這必然需要長久的討論，因此提案人不必擔心重複提出。

( π )題外話如若通過，可否將IPBE授予系統一併開發？--落花有意12138 2024年2月17日 (六) 15:51 (UTC)

臨時賬號我傾向一次性而不是回收再利用，避免貢獻混淆。預先批量申請，通過時發放賬號密碼。延時註冊是可選需求，如果IPBE永久授權依舊很費時、批次授予，可能無所謂。如果只是要驗證IP，可以將驗證模塊站點獨立出來，也不需要將申請表單放在上面，直接一個附令牌的網址訪問、自動檢查風險（建議搭配人機驗證）、確認，原網頁/郵件系統發放賬號密碼就可以了，這樣驗證站點只獲得了令牌和訪客IP信息。未理解「IPBE授予系統」，除了風險檢查機制，授予系統是否只是一個表單管理系統。--YFdyh000（留言） 2024年2月17日 (六) 16:08 (UTC)

如果臨時賬戶不收回為什麼不直接把臨時賬戶改名？

認為單設驗證站點可行。--落花有意12138 2024年2月19日 (一) 11:34 (UTC)

用戶更名的複雜度好像較高，比如可能涉及全域賬戶？最低複雜度就是立即創建+有條件IPBE吧。--YFdyh000（留言） 2024年2月19日 (一) 12:28 (UTC)

其實社群可自行開發，並非必須交由基金會開發（例如本站不少小工具就是由社群開發的），更何況基金會資源及人手有限，也不太可能幫助本站開發這規模的系統。謝謝。--SCP-0000（留言） 2024年2月17日 (六) 16:33 (UTC)

非常同意。但該計劃意圖以中國大陸用戶IP地址為認證手段，且需要經常維護（反LTA），並從IPBE與NDA保密條款的近期討論風向來看，我覺得較難有符合信任條件的維基人參與運維建設。--YFdyh000（留言） 2024年2月17日 (六) 16:51 (UTC)

「臨時賬戶」和「永久賬戶」這個概念還是太新穎了。如果用類似IP Masking的機制的話，是不是需要基金會或者其他技術上的配合（IP Masking好像是準備預留一個用戶名前綴）？另外始終無法解決廟的問題：放外面，域名地址維護成本（「游擊戰」對抗）和可用性維護難以維持，甚至可能擴大損害（更多地址被黑洞）；放裡面，有信任風險。臨時賬戶這個概念和現在IP用戶機制類似，可能增加條目質量溝通成本。或者退而求其次：門戶用於地址驗證和提交郵箱地址（等聯繫方式）申請，然後管理員在門戶管理後台審閱並代申請後回發（本來就有代創建賬戶，並通過郵箱回發的機制）；這樣的可行性可以觀望，雖然仍然有廟的問題。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月18日 (日) 06:07 (UTC)

1. 不需要，設定統一的用戶名前綴及過濾器避免外人註冊即可。2. 如前所述，表單等放在需代理的頁面，可以僅將IP與人機驗證頁面放在小型VPS上（及用容器快速部署）、結果回傳主服務器，域名不清楚能否免費或直接用IP+證書，證書用免費的。3. 溝通成本，暫未考慮，其他匿名用戶一樣的。4. 只有地址驗證需要門戶，表單、管理等系統都可以獨立設置。--YFdyh000（留言） 2024年2月18日 (日) 08:38 (UTC)

所以就是廟的問題：這樣的門戶註冊機制真的要搞成打游擊模式？或者簡單來說，我非常不看好這樣的計劃。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月18日 (日) 08:52 (UTC)

另外，「臨時賬號」這個機制我認為就是畫蛇添足，可以考慮給這類申請的賬戶「永久化」並分發一個短期的LIPE（參照現行的不活躍機制的話，6個月為建議上限），同時可以增發一份提醒，可以通過「鍛煉」編輯的方式，積累有助於判斷申請用戶編輯長期性的好感，臨期時允許申請延長LIPE，可以進一步提升上限。這樣可以減少引入更多不必要的技術性改動。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)

在WMF站下搞什麼東西都逃不過廟的問題，也許確實該考慮與第三方網站合作？ ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年2月28日 (三) 14:02 (UTC)

WMF大概不會喜歡社群自己搞工具還將個資放第三方網站，最終出了什麼事也難以追責。--路西法人 2024年2月28日 (三) 14:54 (UTC)

@魔琴：，「LIPE」就是IPBE，「L」就是Local（本地）。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年3月19日 (二) 09:17 (UTC)

悉。 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年3月19日 (二) 09:22 (UTC)

en的en:Wikipedia:Unblock_Ticket_Request_System其實可以一定程度上充當這類賬戶申請和封鎖接觸申請的門戶，甚至不同部署方式主要業務功能也可以面向不同（放裡面，只保留賬戶申請登記和地址信息查驗，不添加項目用戶登錄綁定來實現項目權限功能聯動，就是一個簡易的賬戶申請系統；放外面，加上項目用戶登錄實現權限功能聯動，可以不保留賬戶申請登記，就是UTRS+），當然問題是，誰寫或者引進改造這套系統。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月18日 (日) 06:36 (UTC)

印象里英文那套系統未設計本地化支持，改造可能費時費力、對目前缺乏幫助——只是一個表單管理系統。--YFdyh000（留言） 2024年2月18日 (日) 08:40 (UTC)

UTRS可以參考想法，而不只是實現，實際上現在申請門戶系統就是上面描述的類似設計思路。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年2月18日 (日) 08:59 (UTC)

引進做處理用途似乎可以？--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 17:52 (UTC)

還有OAuth還是有必要的。--Hualin🎗️希望の星は青霄に昇る _Commons|Talk 2024年2月28日 (三) 18:16 (UTC)

這裡還是副知一下@Bluedeck。—— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年2月19日 (一) 08:43 (UTC)

謝謝ping，確實是我很感興趣的話題。Bluedeck 2024年3月3日 (日) 01:44 (UTC)

XD —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年3月4日 (一) 11:37 (UTC)

參考英維做法，VPO也是可以掛RFC的，既然也是要增加曝光度，不防也掛上RFC來嘗試讓更多人看到這個討論？不過RFC仍在早期運作，效果大概不大就是了。--路西法人 2024年2月26日 (一) 00:47 (UTC)

，要不我把幾部分拆分討論 ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年3月9日 (六) 13:59 (UTC)

拆吧--路西法人 2024年3月11日 (一) 08:33 (UTC)

分段1

稍微整理一下上方的發言，目前的討論千頭萬緒混亂不堪。（著作權聲明：下面部分內容原文來自上方討論，CC BY-SA 4.0）括號【】內為可能的解決方案或者我本人的評論：

1. 安全：
   • 1.1 如果有用戶聲稱自己用了門戶但出事，是門戶的問題（運維或網絡特徵），還是其他問題，如何解決信任危機。【門戶界面告知使用有安全風險，不接受的直接走IPBEG流程。信任問題沒什麼頭緒】
   • 1.2 IP連接有日誌，使用門戶在特定時點做出收發（及對應流量特徵）反而範圍很小，意義不大【如果社群同意意義不大的話安全問題似乎沒有了？】
   • 1.3 如果門戶是為保障時間點隱私，就不宜支持即時提交編輯【可能在本計劃的scope之外】
   • 1.4 維基人做這個有信任問題
2. 賬戶問題，比如傀儡和署名：
   • 2.1 牽扯到傀儡判定、條目主編者等問題【一次性臨時賬戶應該可以解決：臨時賬號的用戶名應該有特定規律，視作因為隱私問題而不公開披露sockpuppeteer的分身賬號。】
   • 2.2 創建臨時賬號非人工審查，LTA可以用完就扔。反破壞機制中，人工審封IP不太可靠、會誤傷。【並非這個系統的特色問題，普通反破壞也適用】
   • 2.3 如果用類似IP Masking的機制的話，是不是需要基金會或者其他技術上的配合（IP Masking好像是準備預留一個用戶名前綴）。【設置統一的用戶名前綴及過濾器避免外人註冊即可。-->全域賬戶怎麼辦？】
   • 2.4 可能增加條目質量溝通成本。【和普通匿名編輯的問題相同，不考慮】
3. 效率和運維問題：
   • 3.1 不看好基金會為此系統投入和有效地得出成果。這還不如研發與優化開放代理與反破壞機制的關係，使通過代理的註冊和編輯更可見和可控（Tag/每筆人機驗證/反破壞更敏感/二次審核，等等），將有益全域
   • 3.2 社群可自行開發，並非必須交由基金會開發。另外考慮到基金會資源、人手、開發效率和意願，不太可能開發
   • 3.3 該計劃意圖以中國大陸用戶IP地址為認證手段，且需要經常維護（反LTA），並從IPBE與NDA保密條款的近期討論風向來看，我覺得較難有符合信任條件的維基人參與運維建設。【可能需要簽NDA的來維護，至少接觸到IP的方面需要。此外還需要監管員以方便CU】
   • 3.4 無法解決廟的問題：放外面，域名地址維護成本（「游擊戰」對抗）和可用性維護難以維持，甚至可能擴大損害（更多地址被黑洞）；放裡面，有信任風險。

其他建議：

• 先審後發：自動/半自動創建所請求賬號，限制有效時長和編輯次數，超出有警告與自動封禁/剝奪IPBE，配合過濾器自動封禁，之後人工審核和批准永久IPBE。【可能比現行政策嚴格？】
• 門戶只用於申請：門戶用於地址驗證和提交郵箱地址（等聯繫方式）申請，然後管理員在門戶管理後台審閱並代申請後回發。【似乎和IPBEG那邊的VRT、CP差不多？】
• 延時編輯：獨立的表單，讓用戶提交要發送的代碼和延時時長，以達到編輯目的。【與本計劃無關。另外編輯衝突怎麼辦？】
• 不授權IPBE：門戶只發帳號密碼。【不是，只發帳號密碼有什麼用？？】
• 不需要用臨時賬戶的模式：分發一個短期的本地IPBE（譬如有效期6個月為建議上限），臨期延長。【臨時賬戶方案是針對先前的安全問題（運營商記錄對比註冊日誌鎖定現實人物）提出的，不過這個方案應該可以解決部分維基人對於自動授權的不信任問題？個人倒是覺得沒有什麼好不信任的，畢竟現在IPBE的發放現狀擺在那裡】

大致這樣。也許可以一部分一部分地討論、研究，並且解決？ ——魔琴 [ 留言 貢獻 新手2023計劃 ] 2024年3月19日 (二) 09:37 (UTC)

Wikipedia:互助客棧/其他#Unblock-zh.org--Dnaimfz（留言） 2024年5月15日 (三) 08:08 (UTC)

深度包檢測無法復現

我嘗試復現幫助正文中的深度包檢測: "對於未加密的HTTP連接，該技術可以檢測詳細的傳輸內容，如果觸發敏感詞則立即發起TCP重置攻擊"。根據論文 "Chinese Wall or Swiss Cheese? Keyword filtering in the Great Firewall of China" [4]，我用 postman 先後發送請求 http://github.com/search?q=我的奋斗 (Get 請求，違禁詞: 我的奮鬥)，http://github.com/search?q=法輪功 (Get 請求，違禁詞: 法輪功)，http://github.com/search?q=习近平 (Post 請求，可能的違禁詞: 習近平)，http://github.com/search?q=色情 (瀏覽器訪問，違禁詞: 色情)。結果均接收到了完整且正確的響應 (200 OK)，並未出現幫助正文、論文等提到的 rst。測試環境: 大陸內地，未使用代理等特殊技巧，未做額外加密，github.com 處於解禁狀態，可不需要任何技巧直連。 ---- Space Timee（留言） 2024年5月15日 (三) 13:41 (UTC)

@Space Timee：對HTTP Path檢測是非常老的策略，現在我猜測已經被棄用，敏感詞列表也不再更新。甚至對HTTP協議本身的檢測也已經停止了，比如最近某年被封鎖的i.pximg.net就是只檢測HTTPS SNI而不是HTTP Host頭。這裡有一份出現在HTTP Path中就會觸發重置的關鍵字列表：[5]。目前我看到的在你說的情況會觸發重置的只有兩個詞：「動態網」和「自由亞洲電台」。請求http://github.com/search?q=自由亚洲电台試試吧。--Akishima Yuka（留言） 2024年5月15日 (三) 15:44 (UTC)

是的，我用 postman 成功觸發了「動態網」和「自由亞洲電台」的深度包檢測，並收到了 rst，謝謝你的解答

GFW 的變化速度真的很快，三年前的論文放到現在已經有很多內容過時了 ---- Space Timee（留言） 2024年5月16日 (四) 05:15 (UTC)

成功觸發了「動態網」和「自由亞洲電台」的深度包檢測

其實你這個說法有些問題：DPI不是能不能被觸發，而是一直都在、對每個連接都有，只是沒匹配到預設定詞就不會注入重置，但是即使不注入也可能會記錄訪問日誌，像美國的稜鏡就是只記錄不注入東西。--Akishima Yuka（留言） 2024年5月16日 (四) 06:28 (UTC)

據說現在的DPI改到光貓上了……哈人--Dnaimfz（留言） 2024年5月16日 (四) 15:28 (UTC)

這個幫助頁感覺沒有用

因為沒有被封鎖的用戶可以訪問維基百科，所以不需要這個頁面，被封鎖的用戶無法看到這個頁面。--Jonathan（留言） 2024年6月15日 (六) 19:36 (UTC)

給掛了鏡像又想做編輯看的，或者某些海外註冊又回到牆內的人看的。而且關於服務器IP的信息這裡也能看，方便做配置。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月16日 (日) 03:26 (UTC)

明白了。--Jonathan（留言） 2024年6月16日 (日) 14:30 (UTC)

H:VISIT提到的Xray分片直連方法有沒有可能在手機上使用？

如題，已知v2rayNG使用的是Xray-core，支持數據包分片，理論上可以通過分片法直連維基百科（甚至包括V2EX、Google等其他被SNI的網站），但是VISIT提供的配置文件在v2rayNG上似乎是無效的（至少VPN模式下啟動之後直接上不了網了），所以有沒有可能通過修改一部分配置文件的內容在手機上直接運行它？--忒有錢 🌊塩水あります🐳（留言） 2024年6月24日 (一) 16:38 (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作「工單」[6]。再甚者，直接「搜尋申請」也是得了，不需要特地什麼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)

教學視頻

@Bluedeck：由於YouTube經常刪除用戶上傳的風格，和其最近清理不活躍賬戶的政策，請考慮將視頻上傳至維基共享資源。--Akishima Yuka（留言） 2024年11月23日 (六) 06:45 (UTC)

「Chromium內核瀏覽器啟動參數」方法在Edge上用不了

有可能是目標路徑上有雙引號和空格的原因，導致這一方法失效。Chrome上是可以用的。--Thyj (คุย) 2024年7月26日 (五) 11:30 (UTC)

路徑如下："C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --host-rules="MAP *.wikipedia.org wikidata.org, MAP commons.wikimedia.org wikidata.org" --host-resolver-rules="MAP upload.wikimedia.org 208.80.154.240, MAP wikidata.org 185.15.59.224"--Thyj (คุย) 2024年7月26日 (五) 11:37 (UTC)

Edge 好像最近的版本會在後臺保持運行，即使你把瀏覽器窗口關掉。你可以試試看去 Task Manager 裏面確保 Edge 的進程已經被殺掉了。

另外這一方法穩定實現需要更改 hosts 文件，改完以後 --host-resolver-rules 那段就可以去掉了--Moonshimmer93（留言） 2024年8月6日 (二) 18:42 (UTC)

edge://settings/system，關掉啟動增強和在 Microsoft Edge 關閉後繼續運行後台擴展和應用，另外要注意你的Windows系統有沒有側邊欄的Copilot，如果有，需要手動在任務管理器里殺進程--Bovemdep（留言） 2024年9月1日 (日) 05:22 (UTC)

實際上只需要在右上角三個點的菜單中點關閉 ms edge 而不是直接關閉窗口就可以了完全把 edge 關閉了--Space Timee（留言） 2024年10月14日 (一) 14:33 (UTC)

因為現在的Windows 11已經把側邊欄的Windows Copilot換成了Copilot PWA--Bovemdep（留言） 2024年10月19日 (六) 10:30 (UTC)

《網絡數據安全管理條例（草案）》和Unblock-zh.org

先前討論

Help_talk:如何訪問維基百科/存檔3#互聯網信息服務管理辦法（修訂草案徵求意見稿）、Help_talk:如何訪問維基百科/存檔3#網絡數據安全管理條例（徵求意見稿）

新聞

國務院總理李強8月30日主持召開國務院常務會議，研究推動保險業高質量發展的若干意見，部署落實大食物觀相關工作，審議通過《加快完善海河流域防洪體系實施方案》和《網絡數據安全管理條例（草案）》，討論《中華人民共和國海商法（修訂草案）》。

《網絡數據安全管理條例》之前的徵求意見稿里包含「數據跨境安全網關」相關內容。

第四十一條 國家建立數據跨境安全網關，對來源於中華人民共和國境外、法律和行政法規禁止發布或者傳輸的信息予以阻斷傳播。

任何個人和組織不得提供用於穿透、繞過數據跨境安全網關的程序、工具、線路等，不得為穿透、繞過數據跨境安全網關提供互聯網接入、服務器託管、技術支持、傳播推廣、支付結算、應用下載等服務。

境內用戶訪問境內網絡的，其流量不得被路由至境外。

之前的討論節選

之前的討論節選

賦予IPBE取權限不知道算不算「提供技術支持或者其他幫助」？--百無一用是書生 (☎) 2021年1月11日 (一) 01:32 (UTC) 徵求意見稿不一定過；授予IPBE權限應該不算「提供技術支持或者其他幫助」，畢竟對方連不到站點的話給賬號以權限也沒有用。--安憶Talk 2021年1月11日 (一) 02:21 (UTC) 中文維基應對中國大陸用戶做一個法律風險提示和免責聲明了。桐生君★[討論] 2021年11月14日 (日) 17:30 (UTC) 似乎主要是針對機場，而不是個人？注意關鍵詞「提供」。在這種情況下，個人有技術能力搭建VPN自用且不分享似乎不受限制？--菲菇＠維基食用菌協會 2021年11月14日 (日) 17:54 (UTC) 特別要強調本站不由管理員運營，以免因「境外反動網站和有害信息」拿管理員開刀。桐生君★[討論] 2021年11月16日 (二) 16:36 (UTC) 鏡像站建議都停掉，因為完全符合這個條款，自己翻數據跨境安全網關可能還不符合，但鏡像站是肯定的。桐生君★[討論] 2021年11月16日 (二) 16:38 (UTC) 出於實際考慮，其實本站鏡像站維護者很多是在牆內，或具有牆內身份，或需要進入牆內。桐生君★[討論] 2021年11月17日 (三) 17:37 (UTC) 現在的中國已經陷在全球化之中，一大堆科研（非國家直接管理的）、外貿等需要連接國際互聯網的，搞閉關鎖國這種玩法已經行不通了，最多噁心下普通的蠢貨，而且技術水平的提升也意味着用的人的水平也得跟得上，至少有能力看明白這個糟糕的世界。當然另一個問題是，工具的傻瓜化反而拉低了下限而已。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作，免敬 2021年11月18日 (四) 07:13 (UTC) 「無論你身處何處，你的鏡像站必須維持小眾，否則就無法起到其應有的作用。」--這句話說的很對，就算你身處牆外，你的鏡像站到達一定的規模依舊有被牆掉的風險。不過在可預見的將來，還是應該大力鼓勵我們這些身處牆外的人來多多鏡像維基百科。--不愛思考得豬（留言） 2021年11月18日 (四) 06:46 (UTC) 看到這裡感覺整個網信辦新規的相關的話題變得有些偏了，有必要在這裡重歸正題。一般這樣的徵求意見稿變成正式實施的規定要花上至少幾十天到數個月。雖然在我看來，不管有沒有這樣的規則，官方對於翻牆工具的打壓力度只會越來越大，Shadowsocks最初的作者受到官方威脅已經是好幾年前的事情，GitHub今年年初開始遇上間歇性干擾問題的時候，互聯網信息服務管理辦法修訂還沒見到正式確認下來，足以看出他們對於技術手段的傳播問題之重視。不過中國畢竟還是需要依賴國際互聯網進行科研、外貿、外宣等活動的，這規則似乎並不完美，因為規則當中似乎沒有提到任何關於合資格個人或組織（例如跨國企業、外貿電子商務從事者、外宣官媒等）以合理目的獲取合法途徑訪問被封鎖網站相關的內容（不過近期有消息提到上海面向企業推出專用的國際互聯網通道，廣東和澳門在橫琴島建的合作區可以免翻牆，而北京似乎也開始允許向外資推出VPN服務），我等普通維基百科用戶對於此條規則提意見，網信辦當然不會採納，不過那些跨國企業、外貿電子商務從事者、外宣官媒等等可就不一定了。鑑於目前仍在意見徵集期內，現在我們還是靜觀其變吧。--🔨（留言） 2021年11月21日 (日) 09:09 (UTC) 說個和維基相關的，如果該條例最終通過，要不要禁止大陸管理員授予用戶IPBE權限（某種意義上也算是為翻牆提供技術支持）？--忒有錢🌊塩水あります🐳（留言） 2021年11月30日 (二) 16:34 (UTC) IPBE是用來豁免維基百科為代理IP設置的編輯限制的，如果連WP都訪問不了，給你IPBE也沒用，這個其他用戶先前就回答過了，而且自從基金會行動後，管理員人手現在已經比較吃緊了，當然居住在中國大陸的管理員本身在安全上就要有所顧慮，不管你是否有曾授予他人IPBE權限。一定要限制IPBE權限授予的話，最好視乎此條例具體執行情況再做進一步決定。--🔨（留言） 2021年12月11日 (六) 16:15 (UTC)

新問題

Wikipedia:Unblock-zh.org是不是危了？--Bovemdep（留言） 2024年8月31日 (六) 13:07 (UTC)

審議通過的版本尚未發布？網站的封禁機制不屬於「數據跨境安全網關」，因此與此無關。--YFdyh000（留言） 2024年8月31日 (六) 13:34 (UTC)

有沒有可能整個維基百科都不屬於可以存取的內容⋯⋯ —— Eric Liu _{創造は生命（留言・留名・學生會）} 2024年8月31日 (六) 20:38 (UTC)

同 Ydyh000，授予 IPBE 僅為便利編輯，而非提供繞過「數據跨境安全網關」。如果授予者或管理員對其安全存有疑慮，離任及停止活躍不失是一個好方法來減低風險。--SCP-0000（留言） 2024年9月1日 (日) 04:54 (UTC)

參考資料

SpaceTimee/Sheas-Cealer

這個應該也屬於「SNI偽造」？ ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月11日 (五) 11:47 (UTC)

本項目僅供學習參考，無意繞過任何審查設備的審查

看到這句話，我感到他在不久之後就會刪庫了。--Akishima Yuka（留言） 2024年10月11日 (五) 11:57 (UTC)

我都火到我維基老家來了？--Space Timee（留言） 2024年10月14日 (一) 14:29 (UTC)

Sheas Cealer 是我的項目，有問題可以直接問我，閱讀別人對項目的評價時還請多加獨立思考--Space Timee（留言） 2024年10月14日 (一) 14:37 (UTC)

Sheas Cealer 本身只是一個 sni 偽造工具而已，是不具備讓大陸用戶訪問維基百科的功能的，在添加特定配置文件後可以實現這個功能，如果要把項目的開源地址寫進幫助里的話，最好能體現這一點--Space Timee（留言） 2024年10月14日 (一) 15:04 (UTC)

@Space_Timee：感謝貢獻。您看看要不要寫進去，或者該怎麼寫吧，這是您的自由。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年11月28日 (四) 09:10 (UTC)

《網絡數據安全管理條例》公布

先前討論

• Help_talk:如何訪問維基百科/存檔3#互聯網信息服務管理辦法（修訂草案徵求意見稿）
• Help_talk:如何訪問維基百科/存檔3#網絡數據安全管理條例（徵求意見稿）
• Help_talk:如何訪問維基百科#《網絡數據安全管理條例（草案）》和Unblock-zh.org

新聞

新華社北京9月30日電 國務院總理李強日前簽署國務院令，公布《網絡數據安全管理條例》（以下簡稱《條例》），自2025年1月1日起施行。

條例正文未見「數據跨境安全網關「相關內容。

腳註

簽名

Bovemdep（留言） 2024年9月30日 (一) 11:27 (UTC)

刪掉原先的第四十一條我是沒想到……不過原第四十一條在de facto層面上來說有在執行這一點還是不變的。--💊✖️2️⃣3️⃣（留言） 2024年9月30日 (一) 13:53 (UTC)

幾乎整個條例都回爐重造了……另外現在執行的是《國務院關於修改和廢止部分行政法規的決定 (2024年)》，刪去《中華人民共和國計算機信息網絡國際聯網管理暫行規定》第六條第一款中的「郵電部」--Bovemdep（留言） 2024年9月30日 (一) 15:43 (UTC)

第三十九條　國家採取措施，防範、處置網絡數據跨境安全風險和威脅。任何個人、組織不得提供專門用於破壞、避開技術措施的程序、工具等；明知他人從事破壞、避開技術措施等活動的，不得為其提供技術支持或者幫助。

耐人尋味。--Bovemdep（留言） 2024年10月2日 (三) 14:20 (UTC)

無對應罰則。--Bovemdep（留言） 2024年10月2日 (三) 14:24 (UTC)

這條並沒有明確指「翻牆」或者類似活動。如果是的話，這似乎將本地反代、域前置等規避措施（甚至hosts？）也納入違法範疇了。（本來僅有VPN、代理在利用「違規信道」條款來處罰，理論上這樣的處理也是不合法的。如果說全部統一成「破壞、避開技術措施」……有點難評。不過不清楚為什麼要用「專門」一詞，眾所周知VPN、代理最初、最基本的功能就是保護隱私，難道我上維基百科就不能保護隱私了？）無罰則也有意思，但不排除後來加上不是嗎 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月2日 (三) 15:09 (UTC)

我也注意到這一條可以被解讀為與網絡審查相關，不過當時出于謹慎沒說出來。還是那句話，有沒有明文規定並不重要。--💊✖️2️⃣3️⃣（留言） 2024年10月3日 (四) 02:51 (UTC)

Re@Liu116：在某些情況下很重要，比如要不要在首頁公告欄給大陸用戶加個警告和免責聲明--Bovemdep（留言） 2024年10月3日 (四) 11:07 (UTC)

不需要，有Wikipedia:編輯維基百科危險嗎這個頁面來提示用戶，並且在更多頁面裡面合理添加指向該論述的內鏈足夠。即便沒有明確的條文規定，執法人員還是可以以各種原因給你強加違法依據進行處罰。--💊✖️2️⃣3️⃣（留言） 2024年10月3日 (四) 11:30 (UTC)

請參考前面的已有討論

• Help_talk:如何訪問維基百科/存檔3#互聯網信息服務管理辦法（修訂草案徵求意見稿）
• Help_talk:如何訪問維基百科/存檔3#網絡數據安全管理條例（徵求意見稿）
• Help_talk:如何訪問維基百科#《網絡數據安全管理條例（草案）》和Unblock-zh.org

--Bovemdep（留言） 2024年10月3日 (四) 11:50 (UTC)

註：此留言已被原作者（User:Liu116）移除。2024年10月4日 (五) 11:13 (UTC)

Re@Liu116：：我知道呀，所以這個討論我發的消息區而不是別的什麼區--Bovemdep（留言） 2024年10月4日 (五) 06:30 (UTC)

Re@魔琴：境外的「反動有害信息」應該不算「網絡數據跨境安全風險和威脅「吧，這個」安全風險和威脅」應該只包括「網絡數據跨境「過程中的--Bovemdep（留言） 2024年10月3日 (四) 11:18 (UTC)

我覺得是「網絡數據跨境（導致的）安全風險和威脅」而不是「網絡數據跨境（過程中的）安全風險和威脅」，行政執法單位大概率不會理解此中不同，具體執法中也沒有見到「計算機信息網絡直接進行國際聯網，必須使用郵電部國家公用電信網提供的國際出入口信道。 任何單位和個人不得自行建立或者使用其他信道進行國際聯網。」會按照專業含義進行解讀，翻牆還是要被抓。----Cat on Mars 2024年10月3日 (四) 15:02 (UTC)

你法我笑 是這樣的 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年10月3日 (四) 15:11 (UTC)

Re@CatOnMars、@魔琴：我們一直在談「名義上、理論上」的東西，事實上怎麼樣我們說了也沒用。--Bovemdep（留言） 2024年10月4日 (五) 02:37 (UTC)

還有

第八條　任何個人、組織不得利用網絡數據從事非法活動，不得從事竊取或者以其他非法方式獲取網絡數據、非法出售或者非法向他人提供網絡數據等非法網絡數據處理活動。

任何個人、組織不得提供專門用於從事前款非法活動的程序、工具；明知他人從事前款非法活動的，不得為其提供互聯網接入、服務器託管、網絡存儲、通訊傳輸等技術支持，或者提供廣告推廣、支付結算等幫助。

不知道身在中國大陸的管理員為中國大陸編輯者提供IPBE算不算其中的「明知他人從事前款非法活動的，不得為其提供互聯網接入、服務器託管、網絡存儲、通訊傳輸等技術支持，或者提供廣告推廣、支付結算等幫助。」--忒有錢 🌊塩水あります🐳（留言） 2024年10月11日 (五) 16:45 (UTC)

之前的討論節選

賦予IPBE取權限不知道算不算「提供技術支持或者其他幫助」？--百無一用是書生 (☎) 2021年1月11日 (一) 01:32 (UTC) 徵求意見稿不一定過；授予IPBE權限應該不算「提供技術支持或者其他幫助」，畢竟對方連不到站點的話給賬號以權限也沒有用。--安憶Talk 2021年1月11日 (一) 02:21 (UTC) 中文維基應對中國大陸用戶做一個法律風險提示和免責聲明了。桐生君★[討論] 2021年11月14日 (日) 17:30 (UTC) 似乎主要是針對機場，而不是個人？注意關鍵詞「提供」。在這種情況下，個人有技術能力搭建VPN自用且不分享似乎不受限制？--菲菇＠維基食用菌協會 2021年11月14日 (日) 17:54 (UTC) 特別要強調本站不由管理員運營，以免因「境外反動網站和有害信息」拿管理員開刀。桐生君★[討論] 2021年11月16日 (二) 16:36 (UTC) 鏡像站建議都停掉，因為完全符合這個條款，自己翻數據跨境安全網關可能還不符合，但鏡像站是肯定的。桐生君★[討論] 2021年11月16日 (二) 16:38 (UTC) 出於實際考慮，其實本站鏡像站維護者很多是在牆內，或具有牆內身份，或需要進入牆內。桐生君★[討論] 2021年11月17日 (三) 17:37 (UTC) 現在的中國已經陷在全球化之中，一大堆科研（非國家直接管理的）、外貿等需要連接國際互聯網的，搞閉關鎖國這種玩法已經行不通了，最多噁心下普通的蠢貨，而且技術水平的提升也意味着用的人的水平也得跟得上，至少有能力看明白這個糟糕的世界。當然另一個問題是，工具的傻瓜化反而拉低了下限而已。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作，免敬 2021年11月18日 (四) 07:13 (UTC) 「無論你身處何處，你的鏡像站必須維持小眾，否則就無法起到其應有的作用。」--這句話說的很對，就算你身處牆外，你的鏡像站到達一定的規模依舊有被牆掉的風險。不過在可預見的將來，還是應該大力鼓勵我們這些身處牆外的人來多多鏡像維基百科。--不愛思考得豬（留言） 2021年11月18日 (四) 06:46 (UTC) 看到這裡感覺整個網信辦新規的相關的話題變得有些偏了，有必要在這裡重歸正題。一般這樣的徵求意見稿變成正式實施的規定要花上至少幾十天到數個月。雖然在我看來，不管有沒有這樣的規則，官方對於翻牆工具的打壓力度只會越來越大，Shadowsocks最初的作者受到官方威脅已經是好幾年前的事情，GitHub今年年初開始遇上間歇性干擾問題的時候，互聯網信息服務管理辦法修訂還沒見到正式確認下來，足以看出他們對於技術手段的傳播問題之重視。不過中國畢竟還是需要依賴國際互聯網進行科研、外貿、外宣等活動的，這規則似乎並不完美，因為規則當中似乎沒有提到任何關於合資格個人或組織（例如跨國企業、外貿電子商務從事者、外宣官媒等）以合理目的獲取合法途徑訪問被封鎖網站相關的內容（不過近期有消息提到上海面向企業推出專用的國際互聯網通道，廣東和澳門在橫琴島建的合作區可以免翻牆，而北京似乎也開始允許向外資推出VPN服務），我等普通維基百科用戶對於此條規則提意見，網信辦當然不會採納，不過那些跨國企業、外貿電子商務從事者、外宣官媒等等可就不一定了。鑑於目前仍在意見徵集期內，現在我們還是靜觀其變吧。--🔨（留言） 2021年11月21日 (日) 09:09 (UTC) 說個和維基相關的，如果該條例最終通過，要不要禁止大陸管理員授予用戶IPBE權限（某種意義上也算是為翻牆提供技術支持）？--忒有錢🌊塩水あります🐳（留言） 2021年11月30日 (二) 16:34 (UTC) IPBE是用來豁免維基百科為代理IP設置的編輯限制的，如果連WP都訪問不了，給你IPBE也沒用，這個其他用戶先前就回答過了，而且自從基金會行動後，管理員人手現在已經比較吃緊了，當然居住在中國大陸的管理員本身在安全上就要有所顧慮，不管你是否有曾授予他人IPBE權限。一定要限制IPBE權限授予的話，最好視乎此條例具體執行情況再做進一步決定。--🔨（留言） 2021年12月11日 (六) 16:15 (UTC)

--Bovemdep（留言） 2024年10月3日 (四) 11:51 (UTC)

艾特一下之前討論比較活躍的@Shizhao、AnYiLin、桐生ここ、不爱思考得猪、Cwek、忒有钱，請問你們有什麼看法？--Bovemdep（留言） 2024年10月11日 (五) 11:58 (UTC)

已經解封

現在已經在中國解封，能夠直接訪問了。那麼你們呢？--2408:8239:701:48E2:1C39:5BD3:BF21:B485（留言） 2024年12月18日 (三) 15:35 (UTC)

但是抽風了--2408:8239:701:48E2:1C39:5BD3:BF21:B485（留言） 2024年12月18日 (三) 16:14 (UTC)

沒有啊？用SNI域前置倒是可以直連。--Haohaoh4（留言） 2025年1月2日 (四) 11:55 (UTC)