維基百科討論:通過電子郵件申請IP封禁豁免指南

頁面內容不支援其他語言。
維基百科,自由的百科全書


配置表單來方便用戶發郵件申請帳戶或申請IPBE權限

目前一個用戶如果在自己的IP被封禁的情況下希望註冊帳戶,或是第一次申請IPBE權限,其需依照本指引中的要求需要發送郵件至unblock-zh@lists.wikimedia.org來申請。目前可以想像的已知問題包括:申請人遺漏了部分信息、申請人發的郵件未遵照模板難以閱讀、管管無法驗證用戶對應的IP位址是否真的被封禁了。為解決這些問題,在此提議在本站安裝ContactPage這一擴展,並書寫對應的配置文件來定義表單。

這一擴展可以根據配置文件生成表單,其中包括若干必填或選填項,且註冊用戶和匿名用戶均可使用。當提交表單時,擴展會將表單中填寫的信息(甚至可以附帶上填寫人當時的IP位址)以一定的格式發送給某個用戶(在本站就可以發給User:Unblock-zh)。比較不好的地方是表單的欄目需要手寫配置文件(參考元維基的配置),但也算是一勞永逸。樣例可以看這個位於元維基的表單。本擴展已於元維基、Governance Wiki和荷蘭語維基百科安裝,因此個人認為安裝應該不成問題。希望獲得社群共識。 -- Stang 2022年7月16日 (六) 17:15 (UTC)[回覆]

沒有意見。未見說明,但該表單似乎不受IPBE影響。關於填入IP位址,建議為可選而非隱含,以利隱私選擇權。--YFdyh000留言2022年7月16日 (六) 18:25 (UTC)[回覆]
那啥,兩個問題:
  1. IP被封禁能提交得了這個表單麼?
  2. 這個擴展有啥防濫用機制麼?會不會被利用來大量發送spam?--百無一用是書生 () 2022年7月18日 (一) 02:22 (UTC)[回覆]
這個擴展本質是Special:EmailUser套皮。如果使用者被禁止發送郵件,那麼他們就用不了這個頁面;頁面的使用也受到郵件相關的速率控制。--MilkyDefer 2022年7月18日 (一) 14:29 (UTC)[回覆]
尷尬,如果被封了是不能發郵件的;有一個可選的captcha。鑑於本提案無法實現,撤回。 Stang 2022年7月18日 (一) 14:55 (UTC)[回覆]
@Stang:奇怪的是,我在meta上用被封禁的IP(編輯頁面,提示已封禁),可以用這個表單啊。之前嘗試好像沒見到驗證碼,這次嘗試見到驗證碼。"Your account or IP address has been blocked."、"Email sent"。--YFdyh000留言2022年7月19日 (二) 03:48 (UTC)[回覆]
我強調一遍,是被撤除了郵件權力的人不能用。Stang作為前行政員在封人的時候不可能沒見過「不能發送電子郵件」的選項吧?除非封鎖一個IP用戶,會導致受其影響的無帳號人員不能發出請求代為創建帳號的表單。--MilkyDefer 2022年7月19日 (二) 06:44 (UTC)[回覆]
很奇怪的是我昨天用了某個不能編輯頁面的IP在匿名情況下發現是無法使用這一功能的,但是剛剛我嘗試復現的時候似乎又沒法重新復現…?話說回來,這個擴展是用$user->isBlockedFromEmailuser()來判斷的,那如果封一個匿名用戶會幹掉sendemail這個權限麼,如果沒有的話那還有繼續討論的餘地。 Stang 2022年7月19日 (二) 11:28 (UTC)[回覆]
MilkyDefer已經完整說明了,我很意外前管理員怎麼會不熟悉封鎖的相關設定。--Xiplus#Talk 2022年7月22日 (五) 06:12 (UTC)[回覆]
介面可以參考mw:Help:Blocking users/zh的附圖。--Xiplus#Talk 2022年7月22日 (五) 12:36 (UTC)[回覆]
從未對匿名用戶執行過禁止發送電子郵件的設置,因此完全不了解這一點。 Stang 2022年7月24日 (日) 13:06 (UTC)[回覆]
似乎沒有明確的反對意見,故公示7天。 Stang 2022年7月31日 (日) 17:46 (UTC)[回覆]
表單的欄位是通過後再討論嗎?--Xiplus#Talk 2022年8月1日 (一) 01:00 (UTC)[回覆]
可以同時或者之後討論,我認為把要不要做和怎麼做分開是合理的。 Stang 2022年8月1日 (一) 08:11 (UTC)[回覆]
公示完之後要做什麼?—— Eric Liu 創造は生命(留言留名學生會 2022年8月10日 (三) 08:00 (UTC)[回覆]
@Stang:可以開始討論表單的欄位了?--Xiplus#Talk 2022年8月18日 (四) 08:30 (UTC)[回覆]
@Stang。—— Eric Liu 創造は生命(留言留名學生會 2022年8月27日 (六) 09:51 (UTC)[回覆]
非常不好意思摸了這麼久。對於表單內容,咱個人的意見是這樣的:如果可能,應設計兩個表單,分別針對未註冊用戶(用於申請帳戶)和註冊用戶申請IPBE權限;對於未註冊用戶,其應包括「當前使用的IP位址」、「封禁ID」(可選)、「申請註冊的理由」、「意向用戶名」;面向註冊用戶的表單基本類似,只是沒有「用戶名」這一個欄目;表單不記錄用戶的IP位址。這個想法可能不是很完善,自動封禁就不是很適用於這種情況,暫時沒想好怎麼做。(或者一個下拉選框讓申請人選自己是原電子郵件發送指引中5種情況的哪一種? Stang 2022年9月5日 (一) 05:29 (UTC)[回覆]
就如同您說的一樣,情況也不只2種而已,而且實務上仍然有人會填錯封鎖ID等欄位,設固定欄位感覺沒比較好,我建議只配置純文字的表單即可,也另外可以做個小工具來輔助產生郵件內容(我已經著手進行一點點,但平時繁忙可能沒這麼快弄出來)。--Xiplus#Talk 2022年9月6日 (二) 12:39 (UTC)[回覆]
咱希望了解目前收到的郵件之中可以按照指引給出的模板正確填寫的比例,這樣判斷一下「填錯ID等欄目」等等情況屬於少數還是占了不小的比例。感謝您可以投入去開發郵件輔助生成小工具(就跟 relgen.js 差不多的那種麼)。 Stang 2022年9月12日 (一) 04:16 (UTC)[回覆]
統計了一下剛剛處理的38件申請。38件申請中有16件沒有依照WP:IPBEMAIL的格式,22件有依照格式;
  1. 沒有依照格式的16件申請中,
    1. 有9件因此缺乏必要資料需要補件。
    2. 其餘7封雖然沒有按照格式,但有提供必要資訊,仍申請通過。
  2. 有依照格式的22件申請中,
    1. 有2件提供的IP並沒有被封鎖,但提供的封鎖ID有被封鎖,仍申請通過。
    2. 有2件提供的封鎖ID錯誤(提供了不是封鎖ID的無用資料),
      1. 其中1件因為IP及封鎖ID皆錯誤而申請失敗。
    3. 有3件即使依照格式申請,但不知為何仍缺乏必要資訊,因此申請失敗。
我正在做的就類似relgen.js。--Xiplus#Talk 2022年9月12日 (一) 07:32 (UTC)[回覆]
感謝提供以上信息,我支持使用純文本的表單,此表單允許匿名用戶進行填寫,不在發送的郵件中包括填寫者的IP位址。 Stang 2022年9月13日 (二) 20:46 (UTC)[回覆]
「不在發送的郵件中包括填寫者的IP位址」的意思是?使用表單自帶的IP嗎?--Xiplus#Talk 2022年9月14日 (三) 02:29 (UTC)[回覆]
實裝了一下,我所說的「填寫者的IP」是指'IncludeIP' => true,這一特性可以把使用者的IP位址包含在主題中。如果啟用了的話,對於匿名用戶而言,郵件主題將形如「聯繫信息 (由[表單內填寫的名稱]在[IP位址])」;如果沒有啟用,主題將形如「聯繫信息(自[表單內填寫的名稱])」。已登錄的用戶會有一個多選框決定是否「在此郵件中包含我的IP位置資料。」,如果勾選了,IP位址也將類似於匿名用戶一樣,顯示在主題一欄中。 Stang 2022年9月18日 (日) 22:34 (UTC)[回覆]

暫擬的配置,非常簡單:

// IS.php
'wmgUseContactPage' => [
	'zhwiki' => true,
],
// CS.php
if ( $wgDBname === 'zhwiki' ) {
	$wgContactConfig['acc'] = [
		'RecipientUser' => 'Unblock-zh',
		'SenderName' => '中文维基百科账户请求表单',
		'RequireDetails' => true,
		'IncludeIP' => true,
	];
}

acc代指帳戶請求,不過可以後期再議;默認主題應在MediaWiki:Contactpage-subject-acc這個頁面自定義;「SenderName」暫時這麼想,待議。 Stang 2022年9月18日 (日) 22:34 (UTC)[回覆]

不是要加 'IncludeIP' => true 嗎?--Xiplus#Talk 2022年9月21日 (三) 01:27 (UTC)[回覆]
上面咱的提議是*不要*加 IncludeIP 啊。個人覺得這個可能會與privacy policy相牴觸,以及IP數據這種東西可能會涉及到NDA的問題。 Stang 2022年9月21日 (三) 06:16 (UTC)[回覆]
您原先推薦ContactPage的理由之一為「管管無法驗證使用者對應的IP位址是否真的被封鎖了」,若不使用這個功能,那麼ContactPage就跟目前的方式相比就沒有額外優點了。--Xiplus#Talk 2022年9月21日 (三) 06:19 (UTC)[回覆]
感謝快速的回應。blame了一下存在一個站點啟用了包含IP位址這一功能,猜測要求這麼做應當不會被拒絕。加了。 Stang 2022年9月21日 (三) 06:24 (UTC)[回覆]
簡單 公示7日,2022年10月4日 (二) 22:06 (UTC) 結束。配置改完之後建議修改目前的操作手冊,並建議申請者通過表單提交請求。 Stang 2022年9月27日 (二) 22:06 (UTC)[回覆]
「'IncludeIP' => true」 此舉將使未有簽署 NDA 的管理員可獲取屬非公開個人資訊的 IP 地址。
雖然現時也要求用戶提供 IP 地址,然而現時的為自願提供及可能有誤,而本提案為系統自動提供用戶的 IP 地址,與 CU 無疑。個人認為從法律屬面上基本上不可行。謝謝。--SCP-0000留言2022年9月29日 (四) 03:57 (UTC)[回覆]
IncludeIP也是可選的,請自己試試看就知道了。--Xiplus#Talk 2022年10月1日 (六) 03:06 (UTC)[回覆]
考慮到「未有簽署 NDA 的管理員可獲取屬非公開個人資訊的 IP 地址」隱私及法律上的隱憂,個人認為應先聯絡基金會法律部門,以確認此提案確實可行。當然,就個人的認知,基金會法律部門原則上並不會允許未有簽署 NDA 者獲取非公開個人資訊。謝謝。--SCP-0000留言2022年10月1日 (六) 03:21 (UTC)[回覆]
為什麼不可以使用Commons上這種的方法呢?--0xDeadbeef留言2022年10月1日 (六) 07:04 (UTC)[回覆]
Xiplus上面說了在開發一個(類似於這樣)的的。 Stang 2022年10月9日 (日) 22:09 (UTC)[回覆]

歪個樓問一下,目前申請IPBE是否需要提供IP位址?至少在Wikipedia:權限申請/申請IP封禁例外權/存檔/2021年中有大量用戶未提供IP位址。--Steven Sun留言2022年10月1日 (六) 13:18 (UTC)[回覆]

似乎是逐漸有了這樣的趨勢?之前給IPBE相對於現在寬鬆很多,當然也有了一些沒有妥善備案的例子,目前給一下感覺可以理解。 Stang 2022年10月9日 (日) 22:09 (UTC)[回覆]

感覺社群方面似乎沒有太大的問題,為了以防萬一咱會給legal發郵件詢問一下可不可以這麼做。這個串應該可以存檔了。 Stang 2022年10月9日 (日) 22:09 (UTC)[回覆]

這個功能應該不容許申請者使用圖像證明自己確實受到IP段封禁的影響,或有需要使用代理伺服器等科學上網手段(是這樣的,OA2021之後我曾經想過一個收緊IPBE的方案,其中一個環節就有這個要求,當然那個方案可以和表單的部署並行就是了)。然後同SCP-2000的疑慮。順便吐槽一下,你維的captcha太渣了,幹不過melon的買榜機器人還不止,聽說就甚至有盲人能輕鬆破解的。--春卷柯南-發前人所未知 ( ) 2022年10月9日 (日) 22:36 (UTC)[回覆]
Stang(話說要存檔到哪裡來著)—— Eric Liu 創造は生命(留言留名學生會 2022年10月23日 (日) 14:44 (UTC)[回覆]

所以現在是公示完畢了麼?之後還需要做些什麼?—— Eric Liu 創造は生命(留言留名學生會 2022年10月16日 (日) 08:56 (UTC)[回覆]

依上方的討論,現已公示完畢。惟仍須等待法律部門的回覆,以確認此方案切實可行。--SCP-0000留言2022年10月16日 (日) 09:35 (UTC)[回覆]
@SCP-2000:所以大約還要多久?—— Eric Liu 創造は生命(留言留名學生會 2022年11月7日 (一) 15:18 (UTC)[回覆]
Ericliu1912 不清楚,個人預計至少一個月以上。另外,其實是 Stang 君詢問法律部門,往後如有關於法律部門回覆的疑問,詢問他為宜。謝謝。--SCP-0000留言2022年11月7日 (一) 16:41 (UTC)[回覆]
@stang:--Ghren🐦🕛 2022年12月5日 (一) 04:34 (UTC)[回覆]
了解。—— Eric Liu 創造は生命(留言留名學生會 2022年12月13日 (二) 07:49 (UTC)[回覆]
@Stang:情況如何?—— Eric Liu 創造は生命(留言留名學生會 2023年1月3日 (二) 16:07 (UTC)[回覆]
Stang如果沒有進展,就暫時先將此話題存檔了。—— Eric Liu 創造は生命(留言留名學生會 2023年2月2日 (四) 02:25 (UTC)[回覆]