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

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)