維基百科

維基百科討論:防濫用過濾器

由Jimmy-bot在話題過濾器創建方針討論上作出的最新留言：5 個月前
了解關於此頁面的更多內容

防濫用過濾器

最新留言：15 年前8則留言7個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。

防濫用過濾器近日啟用，本意為防止破壞、防止孤立條目和防止小小作品，然而卻給編者帶來極大困擾，昨天本人創立2008年夏季奧林匹克運動會比賽項目列表時，當時一如過往於寫好引言後儲存，但卻彈出「請勿在維基百科創主短小條目」一句，於是只好加上一些不太有用的資料，這時又彈出「條目定要有分類」一句，於是只好把當時只有二句的條目分類至Category:2008年夏季奧林匹克運動會和Category:2008年夏季奧林匹克運動會比賽項目，並因位元組不足而再加上一個Reference，這時又彈出「找到Reference標示但找不到顯示」一句，只好又加上參考一節，結果便浪費了我十五分鐘。由於我家電腦經常於網上連線「跳線」，故要經常儲存，防濫用過濾器令資料失落大增，所以我在此討論廢除部分過濾器。窗簾布(議會廳) 2009年4月11日 (六) 03:34 (UTC)回覆

「沒有分類」這一點在下以為要保留。因為給頁面分類也是指引中說明的；有<ref>而沒有<references />則純粹是閣下的疏忽，至於「過短」，若您執意建立，再點擊「提交」就可以了。當然「過短」這一條可以考慮移除，因為小小條目也是一個條目的開始，它至少有30天的寬限期。—Ben.MQ 2009年4月11日 (六) 05:05 (UTC)回覆

該過濾器可以讓我們更好的編寫條目，我也遇到你說的問題。但我覺得這並非大問題，反而可以讓我更認真地對待。—Dingar (留言) 2009年4月11日 (六) 10:32 (UTC)回覆

的確還有可以改進的餘地，至少讓警告信息一次同時出現，這樣會更友好一些--百無一用是書生 (☎) 2009年4月11日 (六) 18:50 (UTC)回覆
這個可能和語句的順序有關，我調整了一下各個過濾器的語句順序，看看是否好一些了？--百無一用是書生 (☎) 2009年4月11日 (六) 19:04 (UTC)回覆
同意一次顯示所有警告信息，同時能否有忽略警告信息的設置，因為我用的也很不舒服，以往我習慣了先發布最後再修正的方式，而且我這裡網絡有時不暢，如果老因為警告信息發布不出，挺怕編輯失敗的（沒線下保存的好習慣）。-孫學 (留言) 2009年4月11日 (六) 21:52 (UTC)回覆
只針對非autoconfirmed吧。--菲菇＠維基食用菌協會 2009年4月12日 (日) 01:13 (UTC)回覆
根據這幾天我在互助客棧觀察的情況，這個過濾器確實給不少人帶來過困擾。建議以後要引入這種東西的時候要先過一段實驗期，也就是只給管理員彈出相關信息，否則新手遇到類似的困難會很打擊積極性的。—人神之間擺哈龍門陣 2009年4月14日 (二) 14:20 (UTC)回覆

防濫用過濾器能否再智能些

最新留言：15 年前3則留言2個人參與討論

在下最近在撤銷條目雲國的破壞時被防濫用過濾器警告：「[」或「]」缺少和沒有wikify。不知過濾器是否能識別撤銷和回退操作，如果能，建議過濾器不要監視這兩類編輯--Leon3289 (留言) 2009年8月7日 (五) 10:51 (UTC)回覆

目前AF不能檢查rollback操作，我還交了錯誤報告……bugzilla:19835--Liangent (留言) 2009年8月7日 (五) 11:11 (UTC)回覆
哦，是這樣，那就只能等MediaWiki更新了--Leon3289 (留言) 2009年8月7日 (五) 14:14 (UTC)回覆

能不能在預覽的時候就觸發？

最新留言：15 年前1則留言1個人參與討論

及早發現及早治療—Hkhk59333 (留言) 2009年11月6日 (五) 00:02 (UTC)回覆

能否在用戶觸發過濾器時告知不可靠的鏈接？

最新留言：14 年前1則留言1個人參與討論

過濾器有個不好的地方就系沒告知哪些鏈接是觸發過濾器的，

只是草草地告知用戶哪些是不可靠來源，

看過濾器運作日誌也很難發現，

以後能否在用戶觸發過濾器時告知哪些鏈接是不可靠的鏈接？（我指的是細分到哪一個鏈接） 以及日後過濾器的運作能透明化，好讓用戶注意這些問題。

——Porsche 911GT2 (留言) 2010年1月30日 (六) 11:17 (UTC)回覆

有關防濫用過濾器

最新留言：12 年前39則留言10個人參與討論

目前中文維基百科有大量過濾器，當中約一半為「隱密」。不知從那一個MediaWiki版本起，那些「隱密」過濾器的觸發次數及觸發記錄變為僅管理員可見，這樣不是對於其他用戶初步了解做成了困難嗎？－HW論 獻 歡迎參觀新用戶頁 2012年5月13日 (日) 11:48 (UTC)回覆

這過濾規則是隱藏的。為了防止破壞者找到其規律而繞過。烏拉跨氪 2012年5月13日 (日) 11:53 (UTC)回覆
過濾規則隱藏不是大問題，問題是當有關編輯為何被過濾掉的詳細信息連自動確認用戶（即帶有abusefilter-log-detail權限的用戶）都不能查閱的時候，未免對於反破壞少了一個作用。(～)補充：abusefilter-log-detail允許用戶在Special:濫用日誌點選「詳細資訊」或「檢查」並查閱詳情。（或許可以向具有回退權限的用戶下放相關權限？但不知軟件能否做到）－HW論 獻 歡迎參觀新用戶頁 2012年5月13日 (日) 12:59 (UTC)回覆
有個abusefilter-view-private（查看被標記為隱藏的過濾器，能編輯過濾器的用戶已自動擁有）。Liangent (留言) 2012年5月13日 (日) 13:10 (UTC)回覆
詳見bugzilla:33380為何。至於是否開放上述權限予回退員，我覺得有討論空間。就我自己而言，基本上很少碰－Lakokat 2012年5月13日 (日) 13:14 (UTC)回覆
這我知道...但目前問題是，對於自動確認用戶來說，[1][2][3]是無效的，只能看到所有被過濾的編輯，而不是特定過濾器的記錄。我認為這種方式，或會降低自動確認用戶能參與反破壞的功能。P.S. @Lakokat: bug作為開頭會連結至bug語維基百科的...－HW論 獻 歡迎參觀新用戶頁 2012年5月13日 (日) 13:16 (UTC)回覆
手誤，見笑了。－Lakokat 2012年5月13日 (日) 13:23 (UTC)回覆

建議直接向回退員開放abusefilter-view-private，以便他們協助透過有關過濾器得出的結果協助反破壞、查閱詳細過濾日誌；回退員現在的門檻已經足夠，值得信任。不知大家如何看？－HW論 獻 歡迎參觀新用戶頁 2012年5月13日 (日) 14:09 (UTC)回覆

我覺得向回退員開放該權限應該是不會有什麼問題。只是我比較好奇真正的實用性如何？--章·安德魯（留言） 2012年5月16日 (三) 15:32 (UTC)回覆
我覺得有用，值得開放。記得以前非公開的過濾器觸發日誌自動確認用戶能看到的，我有時會去看觸發日誌，尋找破壞用戶未被檢測到的破壞。--YFdyh000 2012年5月16日 (三) 16:15 (UTC)回覆
借檢閱一個「隱密」的過濾日誌，了解特定用戶破壞的特性，從而嘗試根據資料尋找未被回退的破壞。以前「隱密」過濾日誌是向自動確認用戶開放的。－HW論 獻 歡迎參觀新用戶頁 2012年5月17日 (四) 10:06 (UTC)回覆
支持。--馬呵說年誒多嘩鐸★魔力（留言） 2012年5月18日 (五) 00:24 (UTC)回覆
回退權門檻很低，萬一一不小心隨口就把過濾方式寫出來了。Ben.MQ 2012年5月20日 (日) 15:03 (UTC)回覆
現在的軟件能否實現允許查看非公開過濾器的觸發日誌，但不能查看非公開過濾器的過濾條件和日誌詳情的權限設置？就像以前一樣。看看經常觸發過濾器的用戶貢獻也能反破壞，觸發詳情平常沒人會去看吧。--YFdyh000 2012年5月21日 (一) 02:50 (UTC)回覆
我看詳情，只看日誌項對調整過濾器寫法一點用都沒有。Liangent (留言) 2012年5月21日 (一) 04:41 (UTC)回覆
哦，我指的是給非管理員通過濫用日誌尋找破壞者未被發現的破壞的能力的權限。--YFdyh000 2012年5月21日 (一) 06:54 (UTC)回覆
那幾個spam沒用的，都是新用戶名，除了被攔下來的東西一點編輯都沒有的。Liangent (留言) 2012年5月21日 (一) 07:59 (UTC)回覆
我沒說那幾個過濾器。其實我也沒看過幾次，就看過幾次103、104的觸發日誌看看有沒有漏掉/被繞過的，如果不開放也沒什麼。--YFdyh000 2012年5月21日 (一) 08:58 (UTC)回覆
┌───────────────────────┘
現在的軟件能否實現允許查看非公開過濾器的觸發日誌，但不能查看非公開過濾器的過濾條件和日誌詳情的權限設置？(：)回應不能。－HW論 獻 歡迎參觀新用戶頁 2012年5月21日 (一) 13:36 (UTC)回覆

討論數周了，大家有任何結論嗎？－HW論 獻 2012年5月30日 (三) 14:04 (UTC)回覆

還是沒有結論...orz--HW論 獻 2012年6月9日 (六) 08:42 (UTC)回覆

無反對則可視為通過，九號一週之後去申請吧……--J.Wong 2012年6月13日 (三) 17:36 (UTC)回覆

(－)反對公開。烏拉跨氪 2012年6月13日 (三) 17:48 (UTC)回覆

其實再細閱一下討論，就會發現社群共識為可以查紀錄，唯不可展露觸發條件及其他詳情。然而HW君已表明不可。至於社群認為解決辦法是垂詢於管理員，抑或允許其他管理人員擁有此權，則討論未詳，建議各位集中於此。--J.Wong 2012年6月14日 (四) 06:08 (UTC)回覆

要不要我去再拆一個權限出來啊（需要一些時間）？Liangent（留言） 2012年6月14日 (四) 15:48 (UTC)回覆
現在是：幾乎所有人同意可以給予某定用戶（回退員）查閱隱密過濾器的日誌，不過只有約一半的人同意可以給予某定用戶查閱隱密過濾器的詳情，其餘一半則認為只應由管理員查閱。其實如果再拆權限，會否對其他維基甚至非WMF wikis做成影響？這點我沒所謂。－HW論 獻 2012年6月15日 (五) 12:08 (UTC)回覆

gerrit:11744 Liangent（留言） 2012年6月17日 (日) 08:26 (UTC)回覆

bugzilla:37679 Liangent（留言） 2012年6月18日 (一) 11:10 (UTC)回覆

是不是已經加入了（我看不到，因為剛去申請回本地的回退權限）－HW論 獻 2012年6月20日 (三) 10:24 (UTC)回覆
好像還是看不了。--MakecatTalk 2012年6月21日 (四) 00:27 (UTC)回覆
看似要等待到下一個MediaWiki版本（MediaWiki 1.20 wmf6），是不是...－HW論 獻 2012年6月21日 (四) 02:57 (UTC)回覆
不是，等到下一次更新AbuseFilter擴展。Liangent（留言） 2012年6月21日 (四) 06:34 (UTC)回覆
即是何時？－HW論 獻 2012年6月21日 (四) 06:37 (UTC)回覆
不知道……Liangent（留言） 2012年6月21日 (四) 06:41 (UTC)回覆
Wednesday, July 4. Liangent（留言） 2012年6月28日 (四) 03:19 (UTC)回覆
被提前到星期一了。－HW論 獻 2012年6月30日 (六) 07:22 (UTC)回覆
已經有查看鏈接了，但還是看不了，現在查看非公開過濾器的日誌跟查看所有日誌效果一樣。--YFdyh000 2012年7月2日 (一) 22:12 (UTC)回覆
好像我沒動篩選框的代碼，只是Special:濫用日誌/570215能用……Liangent（留言） 2012年7月3日 (二) 02:58 (UTC)回覆
gerrit:14008。Liangent（留言） 2012年7月3日 (二) 03:16 (UTC)回覆

有些防濫用過濾器沒有考慮nowiki標籤

最新留言：7 年前10則留言4個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/技術。執行者：Jimmy-bot（留言） 2017年2月8日 (三) 16:42 (UTC)。回覆

如題，剛剛找了兩個過濾器測試，發現只需用nowiki便可繞過之，詳細如下。

另外，我懷疑html注釋語句<!-- -->也有同樣的效果。不過懶得測試了，困死了。

以上。沒怎麼在!(article_namespace == 0)的地方寫過這麼長的東西呢，如果有什麼問題還請見諒。 --碸中嘌呤的白磷萃取 打譜 2017年1月25日 (三) 19:02 (UTC)回覆

注釋

  1. ^ 準確地說是「非管理員且非確認用戶」，但後者在中維太少見，為保證簡潔故略去

有關用戶貢獻中「濫用日誌」一詞的修改

最新留言：6 年前28則留言16個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行者：Jimmy-bot（留言） 2018年2月27日 (二) 08:42 (UTC)。回覆

近期有幾位用戶（包括在下）反映，用戶貢獻中的「濫用日誌」一詞有些不妥。「濫用日誌」和「防濫用過濾器日誌」有着嚴重的意義分歧；「濫用」一詞帶有貶義，而亦有新用戶表示每次看到「濫用日誌」時會覺得緊張和不適，誤認為自己的編輯有疏漏。現徵求社群意見，希望社群能考慮「濫用日誌」的替代用詞。--Innocentius Aiolos 2018年2月6日 (二) 01:46 (UTC)回覆

個人的建議是「過濾器日誌」。--Innocentius Aiolos 2018年2月6日 (二) 01:46 (UTC)回覆
(＋)支持燃 燈巡查傀儡 2018年2月6日 (二) 01:50 (UTC)回覆
(＋)支持--NHC、才不是NPC呢哼！｡:.ﾟヽ(*´∀`)ﾉﾟ.:｡ 2018年2月6日 (二) 02:00 (UTC)回覆
(＋)支持 過濾器日誌 Bluedeck 2018年2月6日 (二) 06:59 (UTC)回覆
(＋)支持--YFdyh000（留言） 2018年2月6日 (二) 10:25 (UTC)回覆
如果得到共識，應當在此處（簡體翻譯）和此處（繁體翻譯）更改翻譯。——꧁༺星耀晨曦༻꧂（留言） 2018年2月6日 (二) 09:04 (UTC)回覆
謝謝你！--Innocentius Aiolos 2018年2月6日 (二) 14:40 (UTC)回覆
@星耀晨曦：英文為Abuse log而非Filter log，如要修改建議只修改本地，反對至translatewiki修改。--Xiplus#Talk 2018年2月10日 (六) 04:54 (UTC)回覆
emmm。我對修改哪裡沒有偏向。——꧁༺星耀晨曦༻꧂（留言） 2018年2月10日 (六) 09:32 (UTC)回覆
(＋)支持修改。另一個建議是改為「編輯過濾器日誌」。--Tiger（留言） 2018年2月6日 (二) 12:05 (UTC)回覆
易誤解為動詞的「編輯」。--YFdyh000（留言） 2018年2月7日 (三) 09:40 (UTC)回覆
啊，沒錯。--Tiger（留言） 2018年2月10日 (六) 06:54 (UTC)回覆
支持「過濾器日誌」。--J.Wong 2018年2月6日 (二) 14:04 (UTC)回覆
(＋)支持有道理。Abacn（留言） 2018年2月7日 (三) 00:16 (UTC)回覆
(＋)支持「過濾器日誌」，總感覺「濫用日誌」這個詞怪怪的。--暗中觀察的RabbitMeow ∞ 與兔喵對話 風の辿り着く場所 2018年2月7日 (三) 03:01 (UTC)回覆
(＋)支持  新方案過濾器日誌，並且順序為日誌-封禁日誌-過濾器日誌
(＋)支持改為「過濾器日誌」或「編輯過濾器日誌」。--Lanwi1(留言) 2018年2月8日 (四) 01:11 (UTC)回覆
(＋)支持(▲)同上Lanwi1 --雲間守望 2018年2月8日 (四) 05:01 (UTC)回覆
即無反對意見，公示7日之後進行修改...--Innocentius Aiolos 2018年2月9日 (五) 19:13 (UTC)回覆
話說，這個修改應該去translatewiki吧？ --達師 - 370 - 608 2018年2月14日 (三) 10:23 (UTC)回覆
User:hat600英文為Abuse log而非Filter log，建議只修改本地。--Xiplus#Talk 2018年2月14日 (三) 11:46 (UTC)回覆
我不認為一定要逐字對應。 --達師 - 370 - 608 2018年2月15日 (四) 16:15 (UTC)回覆
translatewiki修改不須經過本地討論（translatewiki可能有自己一套翻譯的準則？不是很清楚），但本地既然有共識，同時避免translatewiki修改影響本地，建議在本地建立頁面。--Xiplus#Talk 2018年2月15日 (四) 23:53 (UTC)回覆
公示已達7天，時間到後在本地頁面進行更改至「過濾器日誌」（濫權日誌）。--Innocentius Aiolos 2018年2月16日 (五) 14:53 (UTC)回覆
已改，補一個：Abusefilter-log-search。translatewiki想改個自己去吧。--Xiplus#Talk 2018年2月17日 (六) 00:15 (UTC)回覆
+Abusefilter-log-linkoncontribs-text、Right-abusefilter-log、Right-abusefilter-log-detail、Right-abusefilter-hidden-log、Right-abusefilter-hide-log。--Xiplus#Talk 2018年2月17日 (六) 03:11 (UTC)回覆

開啟過濾器的自動封禁

最新留言：5 年前19則留言8個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行者：Xiplus#Talk 2019年4月10日 (三) 11:12 (UTC)。回覆

目前基金會底下有約二十個維基啟用了濫用過濾器的自動封禁。這樣，管理員在開發過濾器時，可以選擇自動封禁觸發過濾器的用戶，從而使得反破壞更為高效。鑑於中文維基百科破壞者非常多，更不乏各種長期出沒的破壞者，他們常常想方設法繞過過濾器並達到破壞的目的。因此，我提議中文維基也開啟過濾器自動封禁的功能。這樣一旦命中，可以節約掉進行警告（如果沒認出是 LTA 的話）、提報 VIP、提速刪/回退、刪除、封禁等維護工作的時間；也加大了 LTA 們繞過過濾器的成本，因為一旦被封如果不換 IP，就需要等待一段時間才能繼續嘗試繞過過濾器。

目前針對長期破壞者、假陽性率極低的過濾器，例如（回退員和管理員可詳閱源代碼和日誌，下同）176號、177號、194號（這個技術上不一定可行）、217號、224號等，完全可以開啟自動封禁功能。另外，僅在緊急情況時啟用的215號過濾器也可以開啟，以節約反破壞工作的時間。 --碸中嘌呤的白磷萃取 打譜 2018年11月11日 (日) 13:18 (UTC)回覆

不想躺着也中槍二哈 -- 小豬佩奇身上紋， 掌聲送給社會人。 2018年11月12日 (一) 01:46 (UTC)回覆
(…)吐槽：看到176號過濾器第28行時我笑了。--仍然相信友誼就是魔法的CuSO4 2018年11月12日 (一) 03:56 (UTC)回覆
(！)意見：217號容易假陽性，尤其是用了和奮球的鏈接翻譯器時。--仍然相信友誼就是魔法的CuSO4 2018年11月12日 (一) 03:56 (UTC)回覆
User:CopperSulfate能詳細說明使用鏈接翻譯器遇到的問題嗎？另外如果啟用過濾器封禁，會將176217高精準度的部分設為封禁，其餘部分恢復警告（當初是為了對付某LTA才用禁止）。--Xiplus#Talk 2018年11月13日 (二) 05:05 (UTC)回覆
@Xiplus：如special:diff/48912692、special:diff/50482394，鏈接翻譯器觸發了手動轉換「台/臺」的過濾器。--仍然相信友誼就是魔法的CuSO4 2018年11月16日 (五) 13:08 (UTC)回覆
User:CopperSulfate您確實更改了台/臺字，十分符合過濾器的設計，沒有假陽性問題。鏈接翻譯器的設計不佳是另一回事，但使用者仍應對於透過小工具做出的編輯負責。--Xiplus#Talk 2018年11月16日 (五) 13:18 (UTC)回覆
@Xiplus：但在下以為，那不算是破壞吧（WP:PRINCIPLE）。我認為，既然這樣的情況可能出現，根據「奧卡姆剃刀」「WP:沒壞就不要修」及其他類似的方法論，還是不要開啟217號的自動封禁為好。--仍然相信友誼就是魔法的CuSO4 2018年11月16日 (五) 13:23 (UTC)回覆
User:CopperSulfate我不明白您給出的這三個連結想表達的意思？--Xiplus#Talk 2018年11月16日 (五) 13:31 (UTC)回覆
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘@Xiplus：不用鏈接表達的話，在下的意思大致是：根據常識判斷，我那兩筆編輯算不上破壞；既然這樣的情況可能出現，為了省事兒，還是不要開啟217號的自動封禁為好。--仍然相信友誼就是魔法的CuSO4 2018年11月16日 (五) 13:46 (UTC)回覆
User:CopperSulfate無故變更該用字可能會被視為繁簡破壞（WP:異體字）。另外上面已經說過了，217會拆成封禁和警告，而且您從未觸發過217。--Xiplus#Talk 2018年11月16日 (五) 13:51 (UTC)回覆
@Xiplus：嗯。  囧rz...--仍然相信友誼就是魔法的CuSO4 2018年11月16日 (五) 13:59 (UTC)回覆
(？)疑問：215號是怎麼回事？幹什麼用的？--仍然相信友誼就是魔法的CuSO4 2018年11月12日 (一) 03:56 (UTC)回覆
私有過濾器，無法在此解釋。詳細信息和說明回退員也可見，寫得也算詳細了，請自行查看。--Tiger（留言） 2018年11月13日 (二) 00:47 (UTC)回覆
我就簡單說一下215，就是阻止IP用戶編輯特定用戶的任何用戶空間頁面。至於具體誰，能看到的自然知道，不能看到的免得挑着免過。——路過圍觀的Sakamotosan | 避免做作，免敬 2018年11月13日 (二) 00:57 (UTC)回覆
(＋)支持：相信可以阻止一部分顯而易見的破壞性編輯。但不知道技術上能不能實現"加入破壞內容先進行警告，無視警告進行編輯才封禁」的操作，最大程度上減少誤判。 --AlexLeeCN（留言） 2018年11月16日 (五) 15:26 (UTC)回覆
可以先警告一次，現在絕大多數的過濾器都是如此。--Xiplus#Talk 2018年11月16日 (五) 16:06 (UTC)回覆

引入過濾器助理（EFH）權限

最新留言：5 年前30則留言19個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2019年3月19日 (二) 16:14 (UTC)。回覆

未完成：

後續可能需要就此舉行表決。--無聊龍·留言·貢獻歡迎光臨維基餐廳 2019年3月2日 (六) 18:58 (UTC)回覆

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

初步討論

目前的問題：現時只有管理員及回退員有權存取非公開過濾器相關資料，但該等資料對其他可信且經驗豐富的使用者可能有用。

問題背景：在啟用防濫用過濾器後的早期，任何自動確認使用者均有權存取非公開過濾器相關資料。惟基於安全性因素，存取非公開過濾器相關資料的權限及後被收緊至只有管理員及回退員有權存取。由於過濾器規則及記錄有助於防範破壞者（尤其是有規律破壞的LTAs），非公開過濾器應予以保密，其存取權應限於可信且經驗豐富的使用者。

我的觀點：除管理員及回退員外，以下可信使用者應有權存取非公開過濾器相關資料，以協助維基百科的反破壞工作：

  1. 有意利用非公開過濾器的logs及代碼執行反破壞工作，但無意同時持有回退權的可信使用者。
  2. 在其他維基計劃擔任管理人員的使用者，透過借鑒中文維基百科的過濾器，協助處理跨維基破壞行為。

我的解決方案：建議引入英文維基百科的過濾器助理（EFH）使用者組別，以賦予可信之非管理員、非回退員使用者存取非公開過濾器相關資料的權限。Wikipedia:過濾器助理頁面為本權限建議之詳細草案頁面。由於本權限由回退員權限分拆而成，故建議的持權人基本要求原則上與回退員的要求相等。如本草案獲得通過，建議目前管理員及回退員存取非公開過濾器的權限維持不變。歡迎討論。--無聊龍·留言·貢獻歡迎光臨維基餐廳 2019年2月12日 (二) 14:47 (UTC)回覆

  • (＋)傾向支持：回退的按鈕容易誤按，即使可以啟用自定義摘要也常常會帶來不便，同時TW的回退已經很方便，我想因此無意持有回退權的人肯定是有的。從別的計劃過來處理跨維基破壞的用戶一般達不到回退權的賦權門檻，除非修改回退相關方針可以破例給其它計劃的管理用戶回退權，不然我認為這是有必要的。另外個人認為，如果有管理員觀察到有其它計劃的管理人員經常來處理跨維基破壞，管理員可以直接賦權，對他們賦權不需要明確的標準，主要是可信，我相信管理員自己可以自行根據SUL等信息做出正確判斷。唯一的一點疑慮是，這兩種情況都是比較罕見的，可能未來願意申請或持有的人會很少，不過我也認為多一種沒有弊端的權限沒有什麼不好。--及時雨 [ 談笑風生或批判一番 / 微小貢獻 ] 2019年2月13日 (三) 04:35 (UTC)回覆
  • (＋)傾向支持雖然還是建議申請回退權限，但是有些其它計劃的管理員可能可以受惠，建議門檻低一些，如果其它計劃有類似權限或者是GR/GS，全域回退或管理員等。我也認為這個可以是上任回退員的一個方法。有些維基人不是非常理解哪兒有破壞，但是可信。所以申請回退權限往往沒有任何回退編輯可以給於審核，因而失敗。用過濾器後可能可以更加容易發現破壞，撤消多了，即可獲得權限。有些回退員(我在內)，申請理由是要看過濾器來反破壞，所以這個權限可能比較恰當。但是我個人是不願意看到這個權限類似檔案移動員一樣沒有實際用途，建議可以看誰有興趣才設立。同時建議社群考慮en:WP:EFM。有些技術好的維基人，可能其它因素無法選管理員，或者失敗，或者其它維基有管理員可以幫忙修過濾器。這個權限可以非常有效。以上是我的一些看法。歡迎討論。其它意見(▲)同上 。--COHAF ■ 2019年2月13日 (三) 06:20 (UTC)回覆
  • @94rain、Cohaf：修改了草案內文，澄清了身兼其他維基計劃管理人員、全域管理人員或基金會職員的權限申請人，無需在本站同時符合回退員要求，只要可信就可以由管理員直接判斷授權。--無聊龍·留言·貢獻歡迎光臨維基餐廳 2019年2月13日 (三) 10:00 (UTC)回覆
  • (－)反對:完全沒有必要！正如之前的檔案移動員，你覺得有人申請嗎？如果真的有意反破壞，就申請回退員；即使不是回退員，tw反破壞的能力已經很強，不必要增加這樣的用戶組別。--203.145.94.154（留言） 2019年2月13日 (三) 12:31 (UTC)回覆
  • (－)傾向反對：個人認為，在過去一年中參與過濾器相關問題討論的用戶絕大多數都是回退員（見此存檔），至少在zhwiki，目前我看不到有誰需要此權限。至於用logs來反破壞，私以為在濫用日誌中提供的大致的信息已足夠用於一般反破壞操作。除非是建立LTA信息頁或者維護過濾器代碼，詳細日誌才有一定作用。--AlexLeeCN（留言） 2019年2月13日 (三) 12:53 (UTC)回覆
  • (？)疑問，看了一下en的權限配置和持有權限者，大部分持有者都是回退員或者巡查員，這是因為en的巡查員和回退員的權限裁剪得很小了（巡查只能標記他人巡查、而回退只能執行系統級回退），我們區的回退員本身就有非公開濾器查看權，所以或者會如同文件移動員那樣，變成雞肋。而且即使知道非公開過濾器的信息，具體的操作還需要知會管理員去處理，只是一個查看權限有點浪費，如果可以結合EF（Edit filter）的話，可能更有效。——路過圍觀的Sakamotosan | 避免做作，免敬 2019年2月14日 (四) 07:08 (UTC)回覆
  • 如果把過濾器相關權限從回退員權限移除，那麼(＝)中立。如果不移除，(－)傾向反對。無論如何，過濾器是個很奇怪的東西，任何人想要學會建立過濾器都需要一定成本（雖然它不複雜），這個權限的擴散是沒有太大益處的。 --達師 - 370 - 608 2019年2月14日 (四) 07:20 (UTC)回覆
  • (－)傾向反對很雞肋的權限，中文維基的檢視非公開過濾器上次我提案時已經從管理員下放至回退員。比起英文維基的回退員要多權限了，另外英文只有15位有此權且其中11位同為回退員甚至包含前管理員。中文真的有足夠多的用戶需要嗎?如有數名用戶(十名以上) 非回退且能有此權會考慮改票。-Zest 2019年2月15日 (五) 01:15 (UTC)回覆
  • (－)反對:回退員本身是可信用戶的認證，加上我認為回退員已經是過濾器的查閱底線，此方案無必要。EveryDayMood 反對大量創建低質頁面 2019年2月22日 (五) 03:40 (UTC)回覆

民調

由於討論期間意見頗為分歧，亦有其他使用者同時提出引進EFM的建議，因此，敝人建議在此作一民調，為期一週，以收集各使用者對此一議題的意見。--無聊龍·留言·貢獻歡迎光臨維基餐廳 2019年2月21日 (四) 08:00 (UTC)回覆

每位使用者可以對其中一個方案表達(＋)支持，但注意  這不是投票，這是為了收集大致意向，以決定後續討論方向，民調結果沒有約束力。

方案一：權限維持不變

維持由管理員持有過濾器編輯權，由回退員持有不公開過濾器及日誌檢視權。

方案二：僅引入過濾器助理（EFH）權限組別

引入EFH權限組別，持有不公開過濾器及日誌檢視權。回退員及管理員的現有權限不變。

方案三：僅引入過濾器編輯員（EFM）權限組別

引入EFM權限組別，持有過濾器編輯權，及不公開過濾器及日誌檢視權。回退員及管理員的現有權限不變。

  1. 這不是雞肋啦--1233 ( T / C） 2019年2月21日 (四) 13:35 (UTC)回覆

方案四：同時引入EFM及EFH權限組別

本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

進一步討論「濫用過濾器編輯者」事宜

最新留言：5 年前11則留言5個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2019年3月24日 (日) 08:14 (UTC)。回覆

未就權限設立達成共識，抱歉盲目發起討論串，無意之間強推方案--及時雨 留言 2019年3月21日 (四) 07:00 (UTC)回覆

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

新增過濾器相關權限組別經過2周投票後，其中建立過濾器編輯員權限組別的提議，12人投票，100%支持，請討論一下幾點事宜。--及時雨 留言 2019年3月20日 (三) 08:59 (UTC)回覆

  1. 用戶組名稱：濫用過濾器編輯者，是否認為有別的更好的名字或保持不變？（例如濫用過濾器編輯員、濫用過濾器管理員）
  2. 用戶組權限，請討論：
    1. 前四項默認引入，後六項默認不引入，是否有疑議？（又追加啟用雙因素驗證）
    2. 濫用過濾器編輯者是否需要回退員已持有的兩項權限以及是否給予設置封禁、撤銷用戶組的受限權限
    3. 權限由誰賦予：管理員行政員添加和移除「濫用過濾器編輯者」用戶組？（以上這些討論完可先報P站）
權限 備註 是否授予
啟用雙因素驗證 (oathauth-enable)   很可能
修改防濫用過濾器（abusefilter-modify）   很可能
查看濫用日誌中的私有數據（abusefilter-private）   很可能
撤銷指定防濫用過濾器作出的所有更改（abusefilter-revert）   很可能
修改包含受限動作的防濫用過濾器（abusefilter-modify-restricted） 高風險，可封禁、撤銷用戶組 
查看被標記為私有的防濫用過濾器（abusefilter-view-private） 回退員有此權限 
查看防濫用過濾器私有詳情訪問日誌（abusefilter-private-log） 回退員有此權限 
查看濫用過濾器（abusefilter-view）  無限制
查看濫用日誌（abusefilter-log）  無限制
查看詳細濫用日誌（abusefilter-log-detail）  自動確認用戶即有此權限
將條目在濫用日誌中隱藏（abusefilter-hide-log）  應為監督員權限
查看隱藏的濫用日誌條目（abusefilter-hidden-log）  應為監督員權限

3.如何獲得和解除權限？

至少AF是可以達到禁止用戶編輯頁面的目的的，相當於擁有了頁面保護的權限（當然，使用起來更嚴格一些）。而phab:T210364一旦部署，AF編輯員更是相當於變相的擁有了頁面保護和用戶封禁的權利。AF編輯員的設立是否應該考慮的更慎重一點？例如權限由管理員授予是否恰當？--百無一用是書生 (☎) 2019年3月21日 (四) 03:13 (UTC)回覆
考慮這些，應由行政員賦權比較合適（對上文暫先直接進行了修改），同時擴大討論範圍，納入修改受限動作。--及時雨 留言 2019年3月21日 (四) 04:42 (UTC)回覆
並不是有行政員授權的問題，而是這就相當於管理員的能力，那為什麼不參選為管理員？——路過圍觀的Sakamotosan | 避免做作，免敬 2019年3月21日 (四) 06:46 (UTC)回覆
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

Wikipedia:防濫用過濾器/過濾器請求/存檔/2016年以前#WP:HYIP的防濫用過濾器在哪？

最新留言：5 年前1則留言1個人參與討論

Wikipedia:防濫用過濾器/過濾器請求/存檔/2016年以前#WP:HYIP的防濫用過濾器在哪？可找一找嗎？ --Wiki emoji | Emojipedia 來笑一下『』 2019年6月13日 (四) 10:43 (UTC)回覆

透過過濾器取消刷編輯數用戶的自動確認權限

最新留言：4 年前6則留言3個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行者：Jimmy-bot（留言） 2020年6月23日 (二) 08:14 (UTC)。回覆

逾兩周無異議，且提議與現有規則之精神無明顯牴觸，將對不當獲取自動確認權限的用戶以過濾器移除自動確認。若有任何不同意見，可徑自取消存檔而重啟話題。--Tiger（留言） 2020年6月13日 (六) 04:25 (UTC)回覆

下列討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。
目前的問題 用戶因刷編輯數獲取自動確認被封禁，經申訴解封以後處理方式不明確。
問題背景 當用戶通過大量無意義編輯獲取自動確認用戶權限以後，再進行僅限自動確認用戶的操作（包括但不限於編輯半保護頁面）之後，會被以「遊戲維基規則」為由封禁。其中一些用戶在申訴中表明自己誤解規則或認識到錯誤，因而獲得解封。然而按照自動確認權限的本意，這些用戶此時不應具有自動確認權限，但卻無法撤銷其權限。自動確認用戶權限並非只有編輯半保護頁面這一項，在過濾器、小工具中也多有利用此權限進行判斷。因此僅僅通過過濾器禁止編輯半保護頁面是不夠的。
解決方案 現在過濾器有撤銷用戶自動確認權限的功能，將過濾器規則寫為： 
user_name == "xxxx"
& "autoconfirmed" in user_groups
& timestamp < yyyyyy

並將匹配規則時的操作設定為「撤銷用戶的自動確認狀態」，可令該用戶在一定期限內，具有自動確認權限的情況下，進行任意操作時被自動除權。除權期限為5天，在這5天內即使編輯數和註冊時間滿足要求也不會獲得權限。此過濾器應僅限於因刷編輯數不當獲得自動確認的用戶的除權。

此前的類似討論 Wikipedia_talk:用戶權限級別#投票中有一些討論，但並未形成共識。

以上過濾器的規則在外部MediaWiki站點上測試良好。測試中遇到的唯一的問題是，除權操作本身同時會阻止該次編輯，且直接再次點擊保存，會繼續被阻擋，需刷新頁面重新進入編輯界面後才能正常編輯。除權成功後5天內都不會再被過濾器阻擋。希望各位熟知技術的用戶提供更多意見。此議題可分為兩方面討論，一是是否通過過濾器對此類用戶進行除權，二是過濾器的具體寫法。--Tiger（留言） 2020年5月29日 (五) 03:20 (UTC)回覆

  • 我所指的取消自動確認用戶的情況並不是你說的這種，是非LTA的普通用戶在解封以後的處理措施。這可能更接近於編輯禁制，但它影響的範圍會比編輯禁制更廣。這種處理方法從法理上來說，我認為是非常符合直覺的，也就是「不當取得權限則除權」。只是擔心具體實施的時候可能存在我沒有想到的問題，所以放到此處徵求大家的意見。如果沒有問題的話，以後將會以這種方式處理刷編輯被封，而後解封的用戶。--Tiger（留言） 2020年6月1日 (一) 09:25 (UTC)回覆
  • 補充一點，除權期的結束時間是用戶最後一次觸發過濾器的時間+5日，而最後一次觸發過濾器則視乎用戶的實際編輯時間，最晚不會超過上述規則中 timestamp 的設置。我認為 timestamp 的設置是類似於封禁和編輯禁制中的時長設置，管理員可有一定的裁量權，而我初步的設想是 timestamp 設置為執行當日起的7日之後。在這種設置下，該用戶最快可於7日到期後取得權限，最晚則是在12日後。--Tiger（留言） 2020年6月6日 (六) 11:22 (UTC)回覆
本討論已經關閉，請勿修改。如有任何意見，請至合適的討論頁進行，並不要再次編輯本討論。

一些有關維基百科:防濫用過濾器的討論

最新留言：3 年前12則留言9個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/其他。執行者：Jimmy-bot（留言） 2021年6月28日 (一) 16:14 (UTC)。回覆

原來的討論頁太冷清了。試試換個地方。--Temp3600（留言） 2021年6月12日 (六) 18:30 (UTC)回覆

建立IP用戶添加{{Notability}}或{{關注度}}的過濾器

DavidHuai1999、命中注定你我他和Datou_1996因LTA:離心力青蛙喜愛對某些條目標記關注度模板，但不能因此限制IP用戶添加{{Notability}}或{{關注度}}的權利，於是請求建立IP用戶添加{{Notability}}或{{關注度}}的過濾器，方便監控LTA:離心力青蛙。--寒吉 2021年5月24日 (一) 09:33 (UTC)回覆

修改Special:濫用過濾器/39、Special:濫用過濾器/92或設立新過濾器，以阻止論文盜版網站

前文見MediaWiki_talk:Spam-blacklist#www.ixueshu.com。為對抗道客巴巴、豆丁網、百度文庫、www.ixueshu.com等論文盜版網站，有必要阻止它們加入原始碼，並提示編輯者應使用原始論文網站(如CNKI)作為來源，或直接不提供網址。為此可以簡單地將www.ixueshu.com等網站加入通用的不可靠來源濫用器，或設立新濫用器，以提供專用的幫助訊息。如果資源容許，我較希望設立新的AF。

關於權限的疑問

最新留言：3 年前8則留言5個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/求助。執行者：Jimmy-bot（留言） 2021年8月11日 (三) 16:14 (UTC)。回覆

檢視防濫用過濾器非公開詳細資料存取日誌 (abusefilter-privatedetails-log)這個權限具體的作用是什麼？除了詳細資料存取日誌，還有什麼樣的資料存取會被記錄？存取「檢視防濫用過濾器非公開詳細資料存取日誌」是會被記錄的嗎？什麼樣的權限可以看到「存取『檢視防濫用過濾器非公開詳細資料存取日誌』日誌」？--Papayatrash｛留言｝ 2021年8月1日 (日) 13:04 (UTC)回覆

找mw看啊（mw:Extension:AbuseFilter），再不行去en或mw問啊。有可能AF還有一些類似CU的隱藏數據日誌，所以和CU數據一樣對等。——Sakamotosan路過圍觀杯弓蛇影 | 避免做作，免敬 2021年8月1日 (日) 13:24 (UTC)回覆
英文不好啊--Papayatrash｛留言｝ 2021年8月1日 (日) 13:34 (UTC)回覆
沒有隱藏數據日誌，管理員看到的和回退員看到的是一樣，管理員只是可以修改。--蟲蟲飛♡♡→♡℃※留言 2021年8月1日 (日) 13:41 (UTC)回覆
@蟲蟲飛：這權限只有cu有--Papayatrash｛留言｝ 2021年8月1日 (日) 13:46 (UTC)回覆
[4]-- Sunny00217  2021年8月1日 (日) 13:42 (UTC)回覆
有看沒有懂--Papayatrash｛留言｝ 2021年8月1日 (日) 13:50 (UTC)回覆

過濾器編輯員

最新留言：3 年前14則留言9個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2021年12月11日 (六) 16:14 (UTC)。回覆

此前該用戶組未通過的原因是「過濾器編輯相當複雜，容易搞壞；過濾器的影響範圍可達全站，且編輯者變相擁有頁面保護和使用者封鎖的權利」。如果走RFA去選過濾器編輯者，理論上可以提高門檻，降低用戶濫用權限撰寫惡意過濾器阻止合法編輯（但除權過濾器編輯者只需經過RFDR）。--爬行數碼1903 2021年11月14日 (日) 07:58 (UTC)回覆

如此，直接選管理員不就得了，反正兩者都會影響全站。 2021年11月15日 (一) 06:54 (UTC)回覆
有人只是需要編輯過濾器並不需要管理員權限時，這個提案還是有必要的。桐生君★[討論] 2021年11月16日 (二) 02:22 (UTC)回覆
請管理員編輯即可，不必再新增權限，畢竟編輯過濾器也要能反映社群共識。此外，我也沒有看到提案對社群能帶來什麼好處。 2021年11月16日 (二) 10:28 (UTC)回覆
比如有的用戶有回退權可以看到隱藏過濾器，過濾器故障時如有編輯權可以修正，可以分擔管理員負擔，而這位用戶可能不需要管理員權限，或無暇處理其他站務，或社區目前只能給予信任他這一部分權限。提名一位管理員需要完全的信任，而提名一位過濾器編輯員只需要一定的信任，畢竟過濾器編輯員只能間接封禁，管理員擁有直接權限。桐生君★[討論] 2021年11月16日 (二) 12:16 (UTC)回覆
你並沒有針對「請管理員編輯即可」和「提案對社群能帶來什麼好處」做出反駁，我目前只看到好像有使用者很想要這個權限。如果需要修正過濾器，讓原先就有權限的使用者操作會比新任編輯者執行要來得好。 2021年11月18日 (四) 16:37 (UTC)回覆
同意增設過濾器編輯員。（上面提到的那個先前反對意見有點蟲蟲飛style，是他還是其他人的反對意見？）Sanmosa Hrom a peklo, márne vaše proti nám sú vzteky! 2021年11月17日 (三) 11:58 (UTC)回覆
之前本人曾提議設立的維護員曾經設想一個包含受限制 的保護/封禁/解封的權限，但當時討論並未就這個受限制 的部分達成共識。過濾器維護員的權限是完整 的，因此可能需要考慮一下WT:維護員中大家的顧慮。--Yichen Ding（留言|主賬戶） 2021年11月27日 (六) 14:03 (UTC)回覆
西班牙語的「過濾器管理員」好像不能編輯或啟用涉及封禁用戶的過濾器？ ——魔琴 [ 已經告假 留言 貢獻 ] 2021年11月28日 (日) 04:54 (UTC)回覆

提議修改維基百科:防濫用過濾器

最新留言：2 年前72則留言21個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2022年8月26日 (五) 00:14 (UTC)。回覆

問題概述 目前，防濫用過濾器是反破壞的重要工具之一，隱藏過濾器日誌和詳情管理員和回退員都可見。
問題背景 此前曾出現過某些LTA可有效針對性地繞過防濫用過濾器的情況，儘管進行了快速的調整，但仍能多次被某些LTA破壞群在短時間內迅速繞過。
中文維基的回退員眾多，既往任免門檻較低，因此可能會存在一定的破壞者通過GHBH策略或直接與回退員合作獲取隱藏過濾器詳情的情況。


(～)補充在過往的一些案例中，Tigerzeng等管理員觀察到，破壞者未被新增的私有過濾器規則攔截而直接繞過了新增的那條規則。這是明確的監視過濾器更改並泄露過濾器規則，而非泄露日誌詳情的證據

我的解決方案 提議收緊可查看私有防濫用過濾器詳情的人員，將其限制為管理員，隱藏過濾器日誌對於管理員與回退員開放。
現行條文

用戶可以查看所有公開過濾器的詳情及觸發紀錄，而隱藏過濾器則只對於管理員與回退員開放。

提議條文

用戶可以查看所有公開過濾器的詳情及觸發紀錄，隱藏過濾器日誌對於管理員與回退員開放，而隱藏過濾器詳情只對於管理員開放。

此前的類似討論 Wikipedia_talk:防濫用過濾器#引入過濾器助理（EFH）權限
Wikipedia_talk:防濫用過濾器#進一步討論「濫用過濾器編輯者」事宜
Wikipedia_talk:防濫用過濾器#有關防濫用過濾器

--PAVLOV 2022年5月25日 (三) 13:27 (UTC)回覆

(－)強烈反對，隱藏過濾器詳情只對於管理員開放會大幅度降低高程度的反破壞，反破壞行動佔多數的非管理員用戶完全不知道過濾器在幹嘛的會很大程度降低透過過濾器監察破壞或找出錯判情況，也使用戶促使管理員更新過濾器以及監察管理員使用過濾器的情況變得完全不可能。至今仍然不少LTA傀儡被過濾器攔截而封禁，硬撞幾次撞出漏洞並不出為奇，不再開放隱藏過濾器詳情予反破壞的回退員而言弊遠遠大於利。--路西法人 2022年5月26日 (四) 02:39 (UTC)回覆
我不太感覺這種可能性存在。又不是剛執行OA過後，這種情況的出現機會非常小。你如果是7個月前來提案的話，我可能會支持。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年5月26日 (四) 06:14 (UTC)回覆
亡羊補牢為時未晚，現在進行有效的重整也不遲。況乎OA有針對回退員的封鎖或除權嗎？
( π )題外話與主題無關，閣下能否解釋一下曾經在刪除討論中，要對我請求基金會行動是基於什麼？我只是步驟性提刪，我的確不知道我是做了什麼需要基金會來介入一下？--PAVLOV 2022年5月26日 (四) 20:48 (UTC)回覆
其實我認爲解決這一問題，應當對回退員的申請門檻進行改革，過去中維申請回退權限只是申請人提供一些（至少五個）回退實例用於佐證對回退權方針、破壞方針等的熟悉程度。但是回退員也有查看標記為私密的過濾器的過濾日誌、查看被標記為私密的防濫用過濾器兩項權限，在申請時恰恰卻忽略了私密過濾器方面的職業操守。倘若這一提案得到通過，就會出現像路西法人所説之大幅度降低高程度的反破壞等情況，同樣治標不治本。--紹💓煦意見箱 2022年5月26日 (四) 20:00 (UTC)回覆
反對，捨本逐末。如果只是擔心規則暴露且技術上可行，回退員取消查看規則的權限吧，私下請求並由管理員告知（比如經過郵件列表）。--YFdyh000（留言） 2022年5月26日 (四) 20:04 (UTC)回覆
技術非常可行。且這是目前最快的解決涉隱私的濫用過濾器暴露的方法。至於權限改革，或可日後再談，因涉及權限改革之事往往在中維寸步難行。--PAVLOV 2022年5月26日 (四) 20:44 (UTC)回覆
回退員的本職工作是批量運用回退功能，該功能的危害性相對不大（如上方用戶的意見，TW也有回退，只是慢一些/不能繞過黑名單過濾器的限制等），也正是因為如此申請門檻才低，不涉及隱私問題。對於回退員來說，過濾器的日誌記錄了被阻擋的編輯的細節（試圖添加/刪除的內容，時間，用戶名，摘要）等，對反破壞確實有益；但過濾器的代碼本身對反破壞的貢獻不見得非常大。上方有用戶提到回退員查閱過濾器代碼可協助管理員發現錯判漏判的情況，但是：不見得回退員都熟悉正則表達式，以至於需要默認地給回退員這種權限；過濾器的錯判漏判理應從結果（某筆適當/不適當的編輯->有/沒有擋住）就能看出來。發現錯誤後除錯和改錯的任務可以讓管理員一併完成，而無需回退員先除錯，再交給管理員改錯。最後，就算提高回退員門檻也無助於解決既有回退員中可能存在「內鬼」的問題。因此上，我認為「為過濾器查看權限的不當下放去提高回退員的門檻」，才是一種「捨本逐末」而且「治標不治本」的方法。--Antigng（留言） 2022年5月27日 (五) 05:50 (UTC)回覆
技術上說，abusefilter-log-private和abusefilter-view-private是兩個獨立、可單獨配置的權限。另外事實上，依過往討論的存檔，當時社群「幾乎所有人同意可以給予某定用戶（回退員）查閱隱密過濾器的日誌，不過只有約一半的人同意可以給予某定用戶查閱隱密過濾器的詳情，其餘一半則認為只應由管理員查閱」。將非公開過濾器代碼的查看權限和日誌的查看權限一併給回退員，可能本來就是wmf那邊執行社群意見時出錯所致。--Antigng（留言） 2022年5月27日 (五) 05:27 (UTC)回覆
或者重提「過濾器助理」方案？——Sakamotosan路過圍觀 | 避免做作，免敬 2022年5月27日 (五) 06:05 (UTC)回覆
本身我想提出這個，但考慮到引入一新權限的提議往往很容易在中文社群流產，而這類的權限調整則相對容易，故此先提出本提議。但閣下的提議非常有用，如閣下有空或可儘快起草。--PAVLOV 2022年5月27日 (五) 06:25 (UTC)回覆
要是真的搞這個玩意，回退員的核心就只有回退一個功能，而實話和TW回退不是差特別多了。過濾器編輯的積壓已經放了一整年了，也好先搞好過濾器再說？--Ghren🐦🕒 2022年5月27日 (五) 07:10 (UTC)回覆
本來巡查員/回退員/IPBE/巡查豁免/模板編輯/MMS之類的權限都分別只有一個核心功能。另外過濾器編輯請求積壓與否與該提案的關係不大。目前即使回退員能查看非公開過濾器的代碼，他們也沒有修改權限。無論修改前還是修改後，決速步都在管理員這一邊。--Antigng（留言） 2022年5月27日 (五) 07:21 (UTC)回覆
我會認為是反破壞的問題並不是在於什麼人能看到過濾器，而是過濾器的更新是否可以貼近破壞者的行為。你上面不是談到「而無需回退員先除錯，再交給管理員改錯」這事嗎？要是回退員能處理了簡單的前期問題，例如問題成立不成立之類的，我相信幫助還是會有的。如果你們真的打算要修的話，我想隱藏過濾器還是要解除掉一部份，例如Special:濫用過濾器/39之類的玩意，畢竟黑名單是公開的。--Ghren🐦🕒 2022年5月27日 (五) 07:44 (UTC)回覆
我認為去檢查過濾器規則的回退員不太多，拆分權限到單獨的組或者渠道（如私密郵件列表）、工具（如編寫於toolforge）會比較好。--YFdyh000（留言） 2022年5月27日 (五) 18:54 (UTC)回覆
(－)反對：查看過濾器有助於反破壞，意見同路西法人。桐生ここ★[討論] 2022年5月27日 (五) 08:53 (UTC)回覆
查看過濾器「代碼」何以有助於反破壞？--Antigng（留言） 2022年5月27日 (五) 08:55 (UTC)回覆
Antigng如某名用戶的某筆編輯被96號過濾器或134號過濾器所攔截，此時若不知道過濾器實施細節，對於一般用戶來說很難從日誌中得到有意義的結論。--Yining Chen（留言|簽名頁） 2022年5月29日 (日) 07:58 (UTC)回覆
(－)反對：如此前有新手用戶創建條目時被某私有過濾器攔截，經其求助後對照過濾器源碼，最終找到被攔截的詞彙為「垃圾」相關詞語，經修改後得以發布。如果在這種情況下無法得知過濾器實施細節，那麼想要從一篇文章中找到未知的「敏感詞」會變得十分艱難。--Yining Chen（留言|簽名頁） 2022年5月29日 (日) 07:58 (UTC)回覆
(：)回應第一，遇到這種情況，如果條目質量沒問題，幫助新手的普通用戶完全可以在確認的前提下直接代新用戶發布，同時及時報告給管理員修復錯誤；如果條目質量有問題，那麼應向其指出條目質量的問題和改善方式，「不帶金絲雀」並不是解決礦井下有瓦斯問題的方法。無論哪種情況都不需要教導新用戶繞過過濾器；「教導新用戶繞過過濾器」這一行為本身也存在風險。第二，退一步說，即使存在個別場景「非查看過濾器源碼不可」——這裡恐怕也沒有人否認「查看過濾器源碼」的價值。但問題回退員的本職工作是回退、反破壞，其低申請門檻也是圍繞這一工作的特性而設計的。下放重要權限給低申請門檻的用戶組不是沒有利，而是很可能弊大於利，被有心人士利用（本人不止一次從站外渠道獲悉有LTA獲取過濾器規則的狀況）。就好比即使不考慮WMF的限制，我們也不會將「用戶查核日誌」的查看權限下放給管理員或回退員，供社群監督查核權限的使用狀況一樣。--Antigng（留言） 2022年5月29日 (日) 11:10 (UTC)回覆
首先，AF應該是反破壞過程中十分有用的工具。而與CU不同的是，一般用戶接觸AF的概率應該要遠遠高於CU（除某些熱衷於傀儡調查的用戶及傀儡調查助理外），而且CU可能包含用戶隱私信息，因此本人認為將AF與CU混為一談可能並不妥當。第二點，目前是否有證據表明泄露過濾器信息的人是回退員而不是管理員？根據我的了解，在2020年-2021年期間有不只一名管理員被質疑為LTA提供相關信息（站內似乎曾有過相關討論）。回退員數量約為管理員人數的3倍。換句話說，把這些回退員的abusefilter-view-private權限剝奪，未必能避免過濾器源碼泄露。如果僅僅是因為某幾名回退員的一些行為，便要剝奪所有回退員的相關權限，那麼這對反破壞工作造成的困擾與過濾器源碼泄露造成的後果相比，很難判斷孰優孰劣。以目前的情況，提升回退員門檻或設立AFH/AFM貌似是更佳的選擇。( π )題外話：據我所知，代替他人發布文章可能會存在一些版權方面的隱患與問題。--Yining Chen（留言|簽名頁） 2022年5月29日 (日) 12:11 (UTC)回覆
1. 提案人與本人都不否認「AF應該是反破壞過程中十分有用的工具」，但認為這種有用應該且僅應該體現在「通過過濾器日誌查閱疑似濫用者的編輯細節」上。而本提案也無意於剝奪回退員查閱過濾器日誌的權限，而是旨在剝奪回退員查閱過濾器代碼的權限。然而您以及上方提出反對意見的用戶卻始終未闡明「剝奪回退員查看過濾器代碼」的權限會對「反破壞工作」帶來何種「困擾」。也如上方列出的舊討論存檔所示，社群甚至從一開始就沒有共識將過濾器「代碼」的查看權限下放給回退員。2. 本人過去從未看到有用戶發起討論來質疑管理員向LTA提供過濾器代碼（LTA在站外途徑提供的信息除外），如您有請列於此處供評估。此外，單純比較管理員和回退員「人數」的意義並不大，兩者的「遴選標準和門檻」均存在較大程度的差異。3. 最後，「設立AFH/AFM」與本提案不是二選一的關係。正如提案人所述，後續提案中可以考慮設立此類職位。--Antigng（留言） 2022年5月29日 (日) 12:50 (UTC)回覆
(：)回應對這一提議下的諸多疑問做一個總體的回覆。過濾器代碼和過濾器日誌本身是不同的，看過濾器代碼則可導致可看到所有的過濾詞彙，看過濾器日誌相當於你能看到diff，看到他的編輯是如何的。
如果你能看到他的編輯是如何的，僅僅剝奪了看過濾器代碼的權限，這難道也會降低反破壞的效率嗎？
本提議與提升回退員門檻、引入AFH等並不矛盾，只是提升門檻、引入AFH等或許可事後再論。--仁愛親誠的PAVLOV 2022年5月29日 (日) 16:24 (UTC)回覆
提門檻和引入AFH此類提案在可以預見的一段時間內很難達成共識。--Yichen Ding（留言|主賬戶） 2022年5月30日 (一) 14:56 (UTC)----Yichen Ding（留言|主賬戶） 2022年5月30日 (一) 14:56 (UTC)回覆
提供防濫用過濾器規則(ADM2)的第16條（設置過濾器私有的事由）、第18條（私有過濾器的泄密報告）作參考。--Kirk # 2022年5月31日 (二) 11:17 (UTC)回覆
在配套措施完善之情形下，我認為應該考慮將權限交還予管理員。濫用過濾器內容之洩漏，對於本站反破壞工作之威脅明顯較嚴重。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年5月31日 (二) 15:08 (UTC)回覆
首先更正本案的「問題背景」。在過往的一些案例中，我（和其他幾位管理員）觀察到的是，破壞者未被新增的私有過濾器規則攔截而直接繞過了新增的那條規則。這是明確的監視過濾器更改並泄露過濾器規則，而非泄露日誌詳情的證據。其次，回退員的門檻過低確實是一個問題，但是現在來提高門檻一不能解決現任回退員中有不可信任之人的問題，二涉及回退員這個權限本身的定位，又需要更多討論。從回退權限本身反破壞的工作範圍來說，協助新手編輯也不是回退權限的目的。查看過濾器攔截日誌已足以排查有問題的編者並追蹤回退。因此(＋)支持。--Tiger（留言） 2022年5月31日 (二) 21:55 (UTC)回覆
限制AF源碼對反破壞有影響是不錯，但如果LTA能看到源碼，那反破壞簡直就無法工作下去了。--Temp3600（留言） 2022年6月1日 (三) 01:36 (UTC)回覆
前述討論多次提到過濾器助理的問題。但感覺單設過濾器助理似無必要。這裡提供一個思路，考慮到反破壞工作內容的相關性，可以令傀儡調查助理當然成為過濾器助理。--Kirk # 2022年6月2日 (四) 10:56 (UTC)回覆
(－)強烈反對為傀儡調查助理增加特權。從最初的討論中就已經確定「傀儡調查助理無任何別於其他用戶的特權」。如果有AFH，那麼就應該把申請相關權限的權力擴展到所有用戶，而不應該只是限定於只有幾名特定的用戶才能有申請相關權限的權力（畢竟反破壞的範圍十分寬泛，有多項反破壞工作與AF有直接關聯，而不僅僅是SPI）。--Yining Chen（留言|簽名頁） 2022年6月3日 (五) 09:39 (UTC)回覆
我的意見是如果涉及私隱問題，那在這裏討論是沒有任何意思的，應該直接在全域站點反映，然後讓他們立即移除相關權限。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月3日 (五) 13:40 (UTC)回覆
(？)異議，應該直接在全域站點反映，然後讓他們立即移除相關權限？中文社群的事情在全域討論很難成功有結論吧？--仁愛親誠的PAVLOV 2022年6月8日 (三) 07:30 (UTC)回覆
如果是涉及到私隱問題的事情的話，不及時處理會引起基金會的法律責任。我覺得只要有證據證明確實引發私隱問題，他們不能不立即移除相關權限。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月8日 (三) 08:16 (UTC)回覆
過濾器規則基本上不涉及用戶隱私，只是反破壞層面的隱私。如果牽扯到隱私，沒簽署保密協議的管理員都無權接觸了。--YFdyh000（留言） 2022年6月9日 (四) 00:14 (UTC)回覆
(：)回應：
仍然抱持反對意見，我完全不認同撤除了回退員檢視私有過濾器的權限就能完全堵截破壞者獲得過濾器反破壞資訊。與其說回退員泄漏過濾器資訊，還不如說是他們已經清楚瞭解了過濾器的運作，直接各種花樣來擾亂。印象中早期該等破壞者曾聲稱有管理人員提供協助，但自從OA2021之後好像越來越少聽到這樣的聲稱，且有關的破壞者的破壞力度也明顯降低了許多。該等破壞者也曾在偽基聲稱持有某些（非維基媒體）站點的管理權和CU權，可以從此看到該等破壞者已經非常充分地瞭解如何鑽反破壞的漏洞，也非常清楚反破壞工具的限制。該等破壞者懂得迴避查核是否代表他們持有查核的資訊？
再者，本站的過濾器一直以來並未能設計到能阻擋破壞者的擾亂行為，且未登錄的編輯者都能在Special:AbuseFilter看到過濾器是否曾有變更，要知道有更新過濾器有多難？又請問自OA2021後你們觀察到哪些破壞者仍有看似完全瞭解過濾器的資料而「繞過過濾器」的破壞行為？我甚至想說，擋的過濾器都寫得不甚嚴密，何談「繞過」？近期又有多少LTA破壞行徑被寫進過濾器裡了？（心內知曉，不用回答）
PAVLOV又提及ST680的例子，在過往SPI的討論中應該也有說過，不論是兩個號都是他創、還是兩個號都是被盜了，都有被同一人在同一裝置控制過，同樣會顯示為  已確認。早於2021年4月已經聲明過兩個帳號的關係，如果是破壞者盜號同樣的密碼就能都盜了。從ST680出現前的其他查核可見，這兩個帳號從未被監管員查出，代表當時並大概率未被持有其他傀儡帳號的破壞者控制或使用。帳號安全問題則不論是誰都是同樣的問題，這個不會扯上只有回退員才會有這樣的風險。
由於我未看到近期（2022年來）明顯知曉過濾器資訊而繞過的情況，故仍不能支持此提案。此外@Yining Chen，你大概率理解錯了KirkLU的意思，他是說「當然成為」，並非「只有他們才能」，但我也是覺得不需要額外特定SPI/C是當然的AFH啦，如果設AFH，申請時管理員還是會按照其經驗和可信程度來判斷，SPI/C只是協助判斷可信程度的因素而已，不用直接特定當然擔任這些了。--路西法人 2022年6月9日 (四) 07:27 (UTC)回覆
@Temp3600。另外想看看Xiplus有沒有相關數據。另外，我可以給一個大膽的假設，就是回退員的帳號在自己不知情的情況下被入侵，使入侵者得以看到過濾器相關資訊。如果這個情況成立，所有回退員都會因安全性不能獲得保障而被除權；我之前請辭回退員權限也是因為這個緣故。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月10日 (五) 02:11 (UTC)回覆
@Sanmosa：什麼數據？--Xiplus#Talk 2022年6月10日 (五) 02:13 (UTC)回覆
@Xiplus：2021年與2022年潛在因知曉隱藏過濾器內容而繞過隱藏過濾器的操作。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月10日 (五) 02:16 (UTC)回覆
怎麼可能有這種數據，也難以現在回歸去計算。--Xiplus#Talk 2022年6月10日 (五) 02:18 (UTC)回覆
@Sanmosa這個要求不能做，就算有這類的數據，直接公布也是BEAN或是未經許可的信息披露。--仁愛親誠的PAVLOV 2022年6月12日 (日) 01:53 (UTC)回覆
哎，其實我應該ping Tigerzeng的。Sanmosa Χαίρε, ω χαίρε, Ελευθεριά! 2022年6月10日 (五) 02:16 (UTC)回覆
我相信提出這個問題的管理員們（包含我）根據他們使用過濾器的經驗，都覺得將其解釋為「過濾器規則被洩漏」比起「熟悉過濾器設計」、「得知過濾器已變更」更為合理。--Xiplus#Talk 2022年6月10日 (五) 02:31 (UTC)回覆
(－)反對：一般用戶也可以根據日誌確定那些廣告機器人有繞過濫用器的嘗試方式，從而針對性的提議改進，隱藏並不能阻止機器人嘗試其他方法繞過，但卻能阻擋一般用戶的可見性，等於把任務全交給管理員了。--脳補｡◕‿◕｡讨论 2022年6月14日 (二) 08:14 (UTC)回覆
機器人？—— Eric Liu 創造は生命（留言・留名・學生會） 2022年6月14日 (二) 09:36 (UTC)回覆
我支持該權限的調整，並建議引入過濾器助手之類的職務。畢竟回退員沒有看到過濾器詳情的必要。為什麼？因為回退員不一定看得懂RegEx（比如在下，雖然看關鍵字也能猜出一些）。有志於研究過濾器的回退員可以申請高階職務。 ——魔琴 [ 留言 貢獻 ] 2022年6月15日 (三) 05:03 (UTC)回覆
？人都去哪了 ——魔琴 [ 留言 貢獻 ] 2022年6月23日 (四) 07:15 (UTC)回覆
我覺得一個比較可行的辦法是在取消回退員查看防濫用過濾器權限的同時，引入防濫用過濾器助理之類的職務供有需求者申請。Ericliu1912（留言） 2022年6月23日 (四) 12:01 (UTC)回覆

拆分權限

目前討論有一個走向是取消回退員的「查看私有過濾器詳情」權限（abusefilter-view-private）並設置新的用戶組接收。我建議可以從「1.申請資格；2.申請理由」兩方面斟酌，看如何既能滿足需要此權限的用戶，又能一定程度上保護私有過濾器詳情不被泄漏。 ——魔琴 [ 留言 貢獻 ] 2022年7月1日 (五) 14:04 (UTC)回覆

(！)意見 不建議隱藏過濾器詳情。倘若真的隱藏描述詳情，部分回退員甚至可能無從得知這個過濾器是幹什麼用的。支持User:魔琴所總結的提高回退員申請門檻和重啟討論WP:EFH。 如果技術上可行，能不能給部分有實質性貢獻且賬號足夠安全的回退員開放所謂的「防濫用過濾器簡介」？與過濾器源碼查看權限分開，並且簡介可以寫的比較空泛籠統（tips:不太了解具體的權限機制，不清楚回退員看的過濾器詳情具體能精細到什麼程度  囧rz……）——誠摯的 ZhaoFJx論•編 2022年7月3日 (日) 11:17 (UTC)回覆

現有回退員中可能已有「內奸」。提高往後權限申請之門檻無助於解決目前實際存在之問題。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年7月4日 (一) 10:19 (UTC)回覆
但還是存在上面說到過的問題，開放EFH之後，這個權限的實際申請/應用場景是什麼？----Yichen Ding（留言|主賬戶） 2022年7月5日 (二) 14:50 (UTC)回覆
場景是非熟練者（一般回退員）無需持有權限，以減少攻擊面。並或許會促進一些討論和流程。--YFdyh000（留言） 2022年7月5日 (二) 15:23 (UTC)回覆
檢視破壞？維護？捉蟲？ ——魔琴 [ 留言 貢獻 ] 2022年7月13日 (三) 17:22 (UTC)回覆
我認為將權限分拆有助於專業分工。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年7月21日 (四) 13:50 (UTC)回覆
(＋)支持：個人支持劃分相關權限，在綜合考量相關功能實用性、公開程度必要性、用戶站務經驗和專業性、反破壞實務需求和可能的人力養成，以及授權信任機制等因素下，可考慮啟用固有之《維基百科:過濾器助理》權限方案，或是在現有基礎下增列「進階回退員」權限（姑且暫稱，若可能建議有個權限專屬圖示）。為期許具專業技術之可信回退員長期投入貢獻且強化相關授權機制，直接在現有的回退員權限加增類似「進階回退員」或「技術回退員」（暫稱）之類的區隔（比如在《維基百科:回退功能的額外功能》章節附近加增改寫），而具備相關條件的回退員若有實際需求，認為知道過濾器代碼詳情有助於自身的反破壞工作，且可以協助管理員維護甚至討論代碼內容，應可適當獲得授權。
綜觀以上站友討論，個人認為關鍵在於過濾器的代碼設計內容對所有回退員公開是否有益，而非回退員權限之申請和權能本身具備何種弊端，且單純提高該權限申請門檻，似已超過原先核心命題的「過濾器設計代碼公開爭議」，對於反破壞站務長期而言亦未必有益；因此我認為本質上應回歸過濾器代碼公開的對象範圍及是否有益於多數回退員行權和執行反破壞站務，進一步而言可考量是否有益於具經驗的可信用戶進一步探索深耕或發展過濾器設計維護相關領域，而獲權用戶的持權操守仍回歸「授權信任」相關問題。個人考量和理據如下：
  • 首先，就一般的使用者需求而言，我不認為需要了解此種過濾器設計專業，而目前而言了解相關專業亦非獲權之必備條件。一般回退員若僅需「反破壞」，實則看不懂相關程式代碼設計的話（比如敝人完全看不懂），通常能看到「過濾器日誌」便足夠，所以我認為讓真正有需要、了解相關專業、具豐富反破壞經驗且自認能對社群和站務有益的可信任用戶視實際需求申請即可。否則連一般反破壞都未必具足夠經驗，或不具程式代碼相關專業，我認為若說要了解代碼設計細節以有效分擔站務或反破壞，實在難說具足夠說服力。
  • 承上，因此個人建議規劃權限，比如直接採用過濾器助理之規劃；若社群對於新設該權限有所爭議，亦可考慮在現有基礎上直接於回退員權限增列「進階回退員」，申請條件可考慮為：「持續於反破壞站務活躍之回退員依實務需求提出申請，經至少一名進階回退員或具過濾器設計維護站務經驗之管理員支持，由具相關站務經驗之管理員綜合考評後授權；若授權申請由具相關經驗之管理員支持提請，則授權之管理員不得為同一人。當社群對申請人獲權具足堪憂慮之具體事由，或參與討論之進階回退員意見顯明歧異，則管理員不應授權。」（「活躍」標準可參考《維基百科:過濾器助理》另訂之）。
  • 對於「防濫用過濾器管理」頁面中提供的公開訊息（尤其是「所有過濾器」之動態列表），對一般用戶公開之作用以及對於反破壞之利弊，個人認為社群可斟酌衡量（個人傾向該列表不應被所有人看見）。
  • 最後，個人認為將過濾器設計代碼公開範圍略作規劃，並非保證過濾器訊息絕無外洩可能或此後可禁絕防堵相關破壞者，仍需仰賴獲權用戶自持自重。
以上為個人意見，供參。--Kriz Ju（留言） 2022年7月26日 (二) 19:57 (UTC)回覆
意見大致相同。申請條件還得待社群討論。動態列表似乎不能隱藏。 ——魔琴 [ 留言 貢獻 ] 2022年8月1日 (一) 06:36 (UTC)回覆

#提議設立容許查看私密資訊的用戶組／flag。個人覺得既然直接移除權限不可能達成任何形式的共識，倒不如等候下方討論更好。--路西法人 2022年8月5日 (五) 08:50 (UTC)回覆

同意。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年8月13日 (六) 17:06 (UTC)回覆
下方技術問題似乎在短時間內無法得到解決，可能使這兩個討論串維持長時間開放但無法得到有效進展。故暫且移除下方「不存檔」標記，待所有事務處理完畢後再進行討論或許會更好。--Yining Chen（留言|簽名頁） 2022年8月15日 (一) 03:23 (UTC)回覆
(！)意見：若條件許可，個人發想之後或可將此案結合下方「提議設立容許查看私密資訊的使用者群組／flag」做適當規劃。--Kriz Ju（留言） 2022年8月15日 (一) 19:01 (UTC)回覆

提議設立容許查看私密資訊的用戶組／flag

最新留言：2 年前12則留言11個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2022年8月26日 (五) 00:14 (UTC)。回覆

於Phabricator查看
編號T309318的任務

續上#提議修改維基百科:防濫用過濾器的討論，建議將查看私密過濾器資訊的權限連同新IPInfo檢視權限分拆為另一用戶組／flag，及後若推行IP masking此用戶組亦可不需另加討論容許此具有此flag的用戶檢視原始IP。原先僅將私密過濾器的查看權限分拆過於雞肋，上方的討論也似乎不會有共識；忽然想起還有IPInfo和未來IP masking的資訊現在尚未可授予其他用戶，故想到將這些權限一併置入新設用戶flag。固然，這也代表回退員將被移除查看私密資訊的權限，這個權限的申請要求將更加嚴謹。設置此用戶組可在不需要額外調整既有的回退員申請標準之下同時達到改善私密資訊的保密性。提請社群討論是否設立此用戶組、申請資格（個人傾向此部分以站務經驗作為標準，再輔以簡單的信任投票）以及用戶組的名字。--路西法人 2022年7月16日 (六) 15:17 (UTC)回覆

通知參與上方討論的用戶。Sanmosa、​Temp3600、​Cwek、​Nishino_Asuka、​YFdyh000、​Antigng、​桐生ここ、​Tigerzeng、​KirkLU、​Ericliu1912、​脳內補完、​魔琴和ZhaoFJx--路西法人 2022年7月16日 (六) 15:22 (UTC)回覆
感覺是值得考慮的方案，但是我簡單想了一下發現實操會比較困難。既然是以查看隱私為主要目的的用戶組，那麼能否信任基本上是最最重要的考慮。在這個前提下考慮申請流程，我能想到的只會是類似於申請管理員的那種。社群又是否期待再多一個這樣相對繁複的流程呢？--Tiger（留言） 2022年7月16日 (六) 15:36 (UTC)回覆
(＋)支持 這樣可以做到又防內鬼又能了解作用。不過不是特別建議合併，感覺有些冗餘……？話說回來，倘若兩者合併為同一權限組，可以在WP:EFH的基礎上進行修改，不如叫「反破壞助理」（） ——誠摯的 ZhaoFJx（論•編） 2022年7月16日 (六) 15:43 (UTC)回覆
當查看IP Masking權限之要求，基金會會如何設定仍是未知之數時，此案基本上無從說起。--J.Wong 2022年7月16日 (六) 16:17 (UTC)回覆
在T309318被回復之前，本提案無法推進，請等待。 Stang★ 2022年7月16日 (六) 17:17 (UTC)回覆
(＋)支持，很合理--脳補｡◕‿◕｡讨论 2022年7月21日 (四) 08:08 (UTC)回覆
總感覺lta-wiki（或站務維基）也可能可以參考本案。 ——魔琴 [ 留言 貢獻 ] 2022年8月1日 (一) 06:40 (UTC)回覆
值得考慮，但需等待IP Masking權限之全景和頒授範圍。--YFdyh000（留言） 2022年8月4日 (四) 06:37 (UTC)回覆
(－)反對在目前有些地區有不明朗的氛圍和環境下，中維不適合設立任何容許查看私密資訊的用戶組。--Wpcpey（留言） 2022年8月14日 (日) 15:24 (UTC)回覆
(！)意見：若站友所論之基金會政策等相關前提條件許可，個人發想之後或可將此案結合上方「提議修改維基百科:防濫用過濾器」做適當規劃。供參。--Kriz Ju（留言） 2022年8月15日 (一) 19:06 (UTC)回覆

限制HTML註釋代碼在編輯條目的使用

最新留言：2 年前21則留言11個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2022年11月3日 (四) 16:14 (UTC)。回覆


近期發現有匿名及註冊用戶多次在條目加入下列「HTML註釋代碼」阻礙條目內容的顯示：

<!-- 這段文字不會在瀏覽器顯示 -->

這種做法可在不刪減條目位元組的情況下，便可阻止條目內容在讀者的瀏覽器上顯示，只需加入HTML註釋代碼括起不想被看見的條目章節，頁面的讀者就看不見被括起的章節，同時又可避免因為編輯歷史顯示有大量字節被刪減或章節被清空，而被近期巡查發現，加入7個位元組便能夠做到如同大量清空內容的顯示效果，故此HTML註釋代碼長期被用作鬼祟破壞，在下已將部分例證列於10月17日當前的破壞，下面將提供部分實例。

例證1：大口環根德公爵夫人兒童醫院，參考來源及內容被註釋，不能顯示[5]
例證2：福克蘭群島，108.184.199.21，整個「文化」章節被註釋，不能顯示[6]
例證3：兒童節，39.118.20.179先刪除香港及澳門章節[7]，同時在中國大陸及台灣章節重複加入冗餘的朝鮮參考來源，再於下一筆編輯使用HTML註釋代碼，阻礙整個台灣章節的顯示[8]
例證4：法定語文條例，96.60.113.141加入HTML註釋代碼，導致一大段內容不能顯示[9]
例證5：香港聖公會，整段「教育改革爭議」章節改為「教育」後[10]，再加入HTML註釋代碼，導致整個原「教育改革爭議」章節的內容不能顯示[11]

以上實例雖然條目及用戶編輯記錄的刪減字節不多，甚至顯示有條目相當位元組的內容擴充，惟實際上是將大段有來源內容、甚至整個章節以HTML代碼註釋，導致本百科的讀者在瀏覽器看不到相關的內容，破壞效果與大量清空內容無異，但往往因為編輯歷史顯示條目的位元組增加，巡查會以為條目是正常的內容擴充，故此不易及時發現條目實際上遭到破壞。

有鑑於此，建議收緊「HTML註釋代碼」在條目的使用：

1. 禁止匿名用戶及新用戶加入「HTML註釋代碼」或在現有「HTML註釋代碼」的括號範圍內加入內容；實行措施包括設置過濾器進行攔截，告知編者不可使用「HTML註釋代碼」。
2. 自動確認用戶或以上權限的編輯，在條目加入「HTML註釋代碼」或在現有「HTML註釋代碼」的括號範圍內加入新內容時，將會在發布變更時在編輯歷史被標籤，列入過濾器日誌，提示近期巡查者需要加以留意。

因為「HTML註釋代碼」在條目編輯上，並非毫無用處，所以不認為要禁絕，惟要防止及更易發現被不當使用。--Uranus1781（留言） 2022年10月18日 (二) 10:26 (UTC)回覆

已建立監視用的過濾器。--Xiplus#Talk 2022年10月18日 (二) 14:48 (UTC)回覆
你是建立「清空条目」這個標籤過濾器嗎？可是沒辦法使用此標籤當近期變更的篩選啊？---- Matt Zhuang表示有事按「此」留言 2022年10月18日 (二) 17:50 (UTC)回覆
357 HTML註解。Special:標籤中找到，點「x個更改」，可以篩選。--YFdyh000（留言） 2022年10月18日 (二) 18:15 (UTC)回覆
調整了一下規則以提供更高的precision。--Xiplus#Talk 2022年10月19日 (三) 01:17 (UTC)回覆
新建頁面將不會加上標籤。--Xiplus#Talk 2022年10月19日 (三) 10:54 (UTC)回覆
357 HTML註解已足夠。--Gqqnb（留言） 2022年10月23日 (日) 09:23 (UTC)回覆
或者分階段去做，若然IP或新用戶仍持續使用HTML註釋代碼搞破壞，便採取攔截方式。--Uranus1781（留言） 2022年10月24日 (一) 09:45 (UTC)回覆
對打標籤和攔截新用戶無意見。--YFdyh000（留言） 2022年10月18日 (二) 16:09 (UTC)回覆
遇到藏內容的就直接幫忙整段刪除，如果是劇透相關一定幫他裸奔，WP:SW，藏甚麼真是的。過濾器會提醒有人用這個唷也蠻酷的。--Mafalda4144（留言） 2022年10月18日 (二) 18:21 (UTC)回覆
我有時作為無來源或爭議內容的移除意向使用，相當於僅編者（尤其是監視者）可見，取消隱藏的人要拿來源舉證，移除隱藏內容視作二次確認——移除有基本共識。有些用戶是將爭議內容存至討論頁留檔+供討論，我覺得如果沒有討論或無爭議，這樣留存過於持久，且有時注意不到。直接移除有時太唐突或不明確，會引發「破壞」爭議/質疑。主要用於舊有內容，如果是新進加入，則更多運用撤銷和Ping來尋求來源或共識。隱藏有效內容的直接撤銷。--YFdyh000（留言） 2022年10月18日 (二) 19:52 (UTC)回覆
所以在下提案時已表示「HTML註釋代碼」在條目並非毫無用處，例如把英文版條目移植到中文版時，可將未翻譯的段落暫時隱藏，但這只適用於無爭議及明顯不適合顯示的內容，亦即直接移除，也不會被視為破壞。因為內容被加入「HTML註釋代碼」後，顯示出來的效果如同相關的內容被刪除，對於有爭議及有來源內容，也利用「HTML註釋代碼」隱藏，又沒有說明這樣做的原因，這樣確會牽涉破壞的問題。關於「取消隱藏的人要拿來源舉證」的問題，這情況僅適用於缺乏來源的有爭議內容，並需要知會對方這樣做的原因，畢竟「HTML註釋代碼」對於條目的編輯和刪除沒有分別，可視為用戶對條目內容的擴充或刪除的操作。--Uranus1781（留言） 2022年10月19日 (三) 02:23 (UTC)回覆
未翻譯段落不是應該用 TransH + TransF 兩個模板嗎？--Anghualee（留言） 2022年10月20日 (四) 13:54 (UTC)回覆
不是每位編者都知道中文維基有這模板，很多功能模板都不好找，也不知其存在。--Uranus1781（留言） 2022年10月21日 (五) 11:03 (UTC)回覆
大體(＋)支持，細則可以再議。--DvXg 📬 2022年10月18日 (二) 18:19 (UTC)回覆
近一年來有多個浮動IP，濫用註釋代碼隱藏有參考來源的章節及段落，而且有多個條目受到影響。註釋代碼雖有其作用，但甚少須要使用到，IP更不見得在正常編輯使用，註釋代碼的效果如同大量移除條目內容，故此應採取如IP大量移除條目內容的措施，以過濾器攔截，IP如真的認為需要使用註釋代碼，可在討論頁提出並提交其草稿，由確認用戶代為編輯。--Uranus1781（留言） 2022年10月20日 (四) 03:28 (UTC)回覆
一般來說，HTML隱藏功能是可以提示編輯者相關部分的共識是什麼，方便編輯者編輯內容，既然有過濾器提示新增HTML隱藏功能，為何沒有提示移除的通知？--唔好阻住我愛國（留言） 2022年10月20日 (四) 15:25 (UTC)回覆
HTML註釋代碼並非完全無用，有部分模板內都有HTML代碼做提示註解，不一定要移除，現在的問題是因為有用戶濫用作為偷偷破壞條目的工具，所以除模板本身附帶的註釋代碼，IP及新用戶一般編輯不太可能在條目正文用到註釋代碼。--Uranus1781（留言） 2022年10月21日 (五) 11:03 (UTC)回覆
只限制ip倒是可以考慮。--Temp3600（留言） 2022年10月21日 (五) 14:04 (UTC)回覆

再提拆分回退員之私密過濾器源碼閱讀權至另一用戶組

最新留言：1 年前118則留言21個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2023年2月11日 (六) 16:14 (UTC)。回覆

過往多次討論見Wikipedia_talk:防濫用過濾器#提議修改維基百科:防濫用過濾器。簡介:鑑於目前回退員中有內鬼，過往數年洩漏過濾器詳情，導致反破壞工作受到不少影響。此事亦進一步影響到回退員可否兼領其他權限(如LTA private wiki的閱讀權限)的質疑，導致反破壞權限改革無法推進。

為此，再次建議拆分回退員之AF源碼閱讀權(abusefilter-view-private)，以收緊其獲得人數。該新用戶組的成員應高度可信，且在反破壞工作中保持活躍。

請諸君討論。--Temp3600（留言） 2022年10月30日 (日) 12:24 (UTC)回覆

個人傾向(＋)支持，但應該考量到之前提出的問題（如對過濾器並沒有那麼了解的回退員間接造成接觸到的資訊差異）。我是有想過一折衷方案（前提是技術上可行）：過濾器觸發時只截取出觸發的部分，而非顯示過濾器完整結構。這樣也能幫助看不懂AF是做什麼的回退員比較能夠理解觸發原因。-- （☎）dt 2022年10月31日 (一) 01:50 (UTC)回覆
哇你這想法有點天方夜譚誒，過濾器做不到這一點，或者說我就沒見過哪兒有能展示這種信息的東西。GDB和LLDB我都沒印象有這種工具誒（--MilkyDefer 2022年10月31日 (一) 02:09 (UTC)回覆
如果連回退員都看不懂觸發器語法的話，要這個權限有什麼意義，還不如支持AF助理方法，讓懂得人自己去檢查或者協助修改AF。而且展示出觸發的語法部分估計現在AF的實現根本沒有這樣的功能，還要mw開發組來實現（或者自己推修改補丁）。只能說有點異想天開。——Sakamotosan路過圍觀 | 避免做作，免敬 2022年10月31日 (一) 02:19 (UTC)回覆
程序上極難實現，只能人工處理，那似乎等同條文上允許某種「查閱請求」。--YFdyh000（留言） 2022年10月31日 (一) 02:28 (UTC)回覆
那算了（看到時全域有沒有這個需求、mw開發出來再說，原本只是想有沒有人寫個小工具就可以解決），就把abusefilter-view-private去掉就好。「另一使用者群組」可以考慮由回退員之間選出，之後由管理授權吧。-- （☎）dt 2022年10月31日 (一) 03:49 (UTC)回覆
(＋)強烈支持。--路西法人 2022年10月31日 (一) 03:31 (UTC)回覆
(！)意見：上一次討論進行了近四個月，最終也沒能達成共識。「共識是可以改變的，但如果你要提出類似的提案，應該解決過去的反駁意見」（WP:常年提案）。個人想知道此次討論較上次討論有何變化？另外，似乎最近由過濾器詳情泄露引起的破壞有所減少？--Yining Chen（留言|簽名頁） 2022年10月31日 (一) 05:53 (UTC)回覆
上一次的討論一開始沒有考慮分拆，而直接將權限收回管理員，引起不滿；後來又因為ip masking導致困難重重。這次只處理核心部分，即AF分家。其他問題容日後再處理。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)回覆
更改一下說法，IP masking方面問題不大。 Stang★ 2022年11月11日 (五) 19:10 (UTC)回覆
感謝補充，但仍建議下一步再處理此問題。--Temp3600（留言） 2022年11月17日 (四) 04:35 (UTC)回覆
我記得上次諸位就是同意居多，問題似乎在技術阻礙？個人對此提議自然是(＋)支持。—— Eric Liu 創造は生命（留言・留名・學生會） 2022年10月31日 (一) 07:27 (UTC)回覆
上次是提到了phab:T309318。如果不考慮IP masking的話就應該沒事。 ——魔琴 [ 留言 貢獻 ] 2022年10月31日 (一) 08:01 (UTC)回覆
對建立反LTA類型的用戶組無異議，但希望同期建立有效、便捷渠道或規則為可信用戶處理相關諮詢，如回退員的合理詢問和建議，以解決部分用戶的偶發需求。--YFdyh000（留言） 2022年10月31日 (一) 07:37 (UTC)回覆
這方面我有一計，但暫時想不出要怎樣配合中維的情況來實施：強化維基百科:反破壞工作小組的職能，將建立為「反破壞專家」的公會。--Temp3600（留言） 2022年10月31日 (一) 14:42 (UTC)回覆
能不能提出什麼具體議案或者說服力的理據，「彷彿劇團每隔一段時間重複演出同樣的戲碼」，我是比較無奈的。上次不是說要將IPInfo和IP masking合併到這個新的用戶組，然後就沒下文了。--Ghren🐦🕓 2022年10月31日 (一) 09:09 (UTC)回覆
這次希望先解決目前的問題，IP masking目前還沒有起色，合併進來的話就搞不下去了。--Temp3600（留言） 2022年10月31日 (一) 10:03 (UTC)回覆
之前的討論參考了YF君提供的意見，我提出的意見的確有捨本逐末之嫌。既然回退員主要工作是快速回退破壞，那麽側重點應當是對回退相關方針的理解程度至少可以讓社群信服做與反破壞相關的工作。而不是技術（例如私密濫用過濾器）能力，因爲其側重點無法保證回退員具備此種能力或與其相對應的操守。所以(＋)支持拆分權限。--紹💓煦集思廣益 2022年11月5日 (六) 07:44 (UTC)回覆
(＋)支持拆出Wikipedia:過濾器助理。--冥王歐西里斯（留言） 2022年11月5日 (六) 12:37 (UTC)回覆
感謝X43現身說法證明拆分的需要。--Ghren🐦🕙 2022年11月26日 (六) 14:48 (UTC)回覆

名字與細則

過往的方案見Wikipedia:過濾器助理。歡迎各位討論。--Temp3600（留言） 2022年11月5日 (六) 17:25 (UTC)回覆

(＋)支持以上提案。--冥王歐西里斯（留言） 2022年11月7日 (一) 03:05 (UTC)回覆

題外話

( π )題外話 如果有查看已刪除頁面的權限（browsearchive、deletedtext，deletedhistory不確定）或用戶組，可能更方便某些任務（侵權、G5、破壞等歷史頁面的核查）。--YFdyh000（留言） 2022年11月8日 (二) 13:38 (UTC)回覆
您是不是要找：WP:刪除員，WP:維護員。[開玩笑的]--Yining Chen（留言|簽名頁） 2022年11月8日 (二) 14:11 (UTC)回覆
準確說，去掉刪除/恢復權限的「刪除員」。不知道社群是否有興趣加在新用戶組上。目前是通過WP:AR，但時效性不好。--YFdyh000（留言） 2022年11月8日 (二) 14:59 (UTC)回覆
？？去掉刪除/恢復權限還算是什麼刪除員。--Ghren🐦🕓 2022年11月11日 (五) 08:45 (UTC)回覆
你的邏輯是不是有點混亂？這也沒說這是要啟用刪除員，這只是探討一個與刪除員類似，在具體權限上有所限制的<未知>而已。--MilkyDefer 2022年11月11日 (五) 12:42 (UTC)回覆
所以我說的不是刪除員，而是能查閱私有（非公開）記錄的另一組權限，是否能合進去，參考藍桌圖書館、已刪百科等需求。已知新權限開放給高度可信用戶，唯低於管理員。大多數已刪除頁面，只是出於維護，可能沒有保密需求，需要保密的要監督。權限組可以命名如「非公開記錄查看員」（Non-public record viewer）。--YFdyh000（留言） 2022年11月11日 (五) 13:31 (UTC)回覆
你這個「非公開記錄」很容易讓人聯想到真的要簽字且具有法律效力而且大陸人不能簽的NDA欸，你要不改個名字吧。--MilkyDefer 2022年11月11日 (五) 15:35 (UTC)回覆
這是考慮到私有對應的private與「隱私」相同，擔心誤解。要不然，「私有記錄查看者（Non-public record viewer）」，中英非一致譯法。或者，進階記錄查看者，但表意很模糊。--YFdyh000（留言） 2022年11月11日 (五) 16:12 (UTC)回覆
查閱員這個名字如何？可以查看AR，也可以查看過濾器。桐生ここ★[討論] 2022年11月12日 (六) 04:19 (UTC)回覆
很難，或者你需要讓這個組擁有類RfA的授予標準（社群頁面公布請求、不少於7天的投票云云）。 Stang★ 2022年11月11日 (五) 19:10 (UTC)回覆
建議先完成分柝，再進一步調整，避免再次流產。--Temp3600（留言） 2022年11月14日 (一) 02:37 (UTC)回覆
最近不授予回退權是不是和這有關？Evesiesta 2022年11月27日 (日) 17:07 (UTC)回覆
不清楚，但應該沒有關係。--Temp3600（留言） 2022年11月27日 (日) 18:53 (UTC)回覆

初步方案

按舊稿修改了一份草稿:過濾器助理，請諸君討論。--Temp3600（留言） 2022年11月15日 (二) 16:35 (UTC)回覆

題外話#2：全域的m:Abuse filter helpers就是「過濾器助理」，不知道為什麼要翻譯成「防濫用編輯器幫助者」，是時候正名一下了（叫全域過濾器助理？會不會誤以為是「全域過濾器」的助理？） ——魔琴 [ 留言 貢獻 ] 2022年11月15日 (二) 16:46 (UTC)回覆
@Liuxinyu970226：還在嗎--Temp3600（留言） 2022年11月15日 (二) 17:14 (UTC)回覆
贊成更名，「全域過濾器助理」挺好的。「幫助者」應只是粗譯遺留。--YFdyh000（留言） 2022年11月16日 (三) 11:03 (UTC)回覆
問題一：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-view-private權限，那在中維，abusefilter-view-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？
問題二：查看垃圾鏈接阻止列表日誌這個權限在英維得是過濾器助理以上的用戶才有，但是中維只要是個User就有了，要不要調整之類的。一直不理解為什麼為什麼過濾器39、92是不公開的，但是黑名單的閱讀權限就放得這樣低。（這算是個無關問題，只是剛好看到而已）
問題三：啟用雙重身份驗證有這個需要嘛？在我的眼中這不是一個很重要的權限，不一定要雙因素驗證。--Ghren🐦🕘 2022年11月16日 (三) 01:53 (UTC)回覆
1. 英維的管理員數量多很多。討論的不就是該權限從回退員移到低於管理員的新用戶組嗎。2. 不了解這個權限。3. 有一定必要，已知需求源自「潛伏」風險，而查看過濾器不留日誌，可能難以感知賬號被盜用？--YFdyh000（留言） 2022年11月16日 (三) 11:07 (UTC)回覆
啊，抱歉，我看錯了。問題一應該是這樣：對比中維和英維的兩個過濾器助理頁面，英維是只有admin以上的用戶有abusefilter-log-private權限（查看標記為私密的過濾器的過濾日誌），那在中維，abusefilter-log-private的權限應該是像現在一樣，回退員也有，還是管理員以上的才有這個權限？我複製的時候沒看清楚。不好意思。我想知道「查看標記為私密的過濾器的過濾日誌」這個權限是也是收回，還是繼續保留在回退員上比較好。--Ghren🐦🕘 2022年11月16日 (三) 13:04 (UTC)回覆
一起移入新用戶組。--YFdyh000（留言） 2022年11月16日 (三) 22:05 (UTC)回覆
現在完全沒有討論要取消回退員abusefilter-log-private權限。也看出不出這個方案打算這樣辦。過去共識看來也不打算這樣辦。那是否要重複給這新用戶組這個權限就是個問題。要從回退員手中收回這個權限，要更深的討論。--Ghren🐦🕚 2022年11月17日 (四) 03:36 (UTC)回覆
本提案討論的是解除回退員的abusefilter-view-private權限；英維也是User持有，為什麼放的這麼低請參閱gerrit:405670；「須有良好賬戶保安操守，例如開啟雙重認證（2FA）、設立高強度密碼、電腦不受惡意程序感染等」。 Stang★ 2022年11月16日 (三) 12:37 (UTC)回覆
  • 感謝各位的回應。「拆分回退員之私密過濾器源碼閱讀權至另一用戶組」指的是移除回退員的abusefilter-view-private權限，並邀請社群中仍希望保留該權限的用戶申請加入新用戶組。回退員的abusefilter-log-private權限不在本討論範圍，但由於新用戶組的成員可獲得log-private權限，該權限獲得人數將可能上升。--Temp3600（留言） 2022年11月17日 (四) 04:45 (UTC)回覆
    方案草稿中「資格要求」的第六點，在實際實行中似乎很難做到。缺乏有效的方式證明某用戶是否可信。--Yining Chen（留言|簽名頁） 2022年11月17日 (四) 11:12 (UTC)回覆
    我看英維這一條也是自由心證而已，總之沒有人對這一點提出質疑就算是過關。--Temp3600（留言） 2022年11月17日 (四) 14:54 (UTC)回覆
    顯然是基於共識，消除合理質疑。可能需要如一周或兩周的公示期。--YFdyh000（留言） 2022年11月17日 (四) 15:25 (UTC)回覆
    確實缺乏有效的方式，共識制要求社群成員的絕大多數對於何為可信任有良好的認知，並有良好的說理能力。但我不認為我們的社群能達到這個要求。英文維基百科以我有限的觀察也只能說是勉強達到。實際做起來，做還是能做的，但多少會把問題積累起來到以後產生比較大的麻煩。--Tiger（留言） 2022年11月22日 (二) 17:03 (UTC)回覆
    坦率說，在中維上高度可信要求可能無法嚴格地執行。但考慮到目前回退員持有view權是"沒有要求"，本項至少能收緊一些限制，並為解除不適合者的權限提供法規上的支持。--Temp3600（留言） 2022年11月27日 (日) 16:55 (UTC)回覆
    尚且不談中維潛在的地區（組織）割裂（不信任）問題，假若將標準放得如此低，那麼是否反面說明不可信用戶（潛在的破壞者）也可順利擔任回退員？換言之，假若該方案能夠實施，那麼就根本沒有必要另設權限，只要找到「社群成員」對當前回退員列表逐一審查，把所有「不可信用戶」都移權+封禁，即可解決問題。又若模擬權限設立後的「公示」，那麼只要現在開放一個討論，所有用戶都可在其中指認自己認為「不可信」的回退員，最後統一公示一段時間以後直接移權即可，完全沒必要設立新權限嘛。如果在措施不完善的情況下貿然設立一個新權限，恐怕無益於反破壞問題的解決，反而不如不設立AFH權限，而由管理員代為處理源碼閱讀請求。--Yining Chen（留言|簽名頁） 2022年11月28日 (一) 11:12 (UTC)回覆
    首先，目前已經有破壞者現正擔任回退員，這在上次的討論已經有不少用戶和管理員表達過。您所指的「排查回退員」方案，上次也有人提議過，但執行十分困難——部份回退員並不活躍，或已經退出一線反破壞工作多年，現行方針並無任何規則可用於解任他們，而且單憑猜疑，解任用權恰當但沒有參與反破壞工作的回退員在實務上也不可行。現行機制的弱點，正是破壞者可以先混到回退員，然後保持低活躍狀態，以此逃避反破壞小組的監視，而使用abusefilter-view-private權限亦無任何紀錄可查，導致無任何方法可以找出此等內奸。其次，直接由管理員查閱的方案上一次也有討論過（應該先上一次最先就是討論此方案），並已經被社群駁回。--Temp3600（留言） 2022年11月29日 (二) 14:39 (UTC)回覆
    您所說的「單憑猜疑」解任回退員，與「單憑猜疑」拒絕AFH申請有什麼區別呢？--Yining Chen（留言|簽名頁） 2022年11月30日 (三) 01:55 (UTC)回覆
    拒絕AFH申請的主要原因應是「用戶不符合資格要求」，即身為回退員但未有在反破壞工作中活躍；自稱將維護AF但沒有兌現承諾等。這些都是客觀的理由。至於分別，則在於AFH與回退員所需的信用等級不同。回退員如無法取閱敏感資料，則其權限可造成的破壞十分有限，要求先有違規行為後再解任依然合適；但AFH可以取得敏感資料，且缺乏監察途徑，即使沒有過違規行為，仍有可能不適合獲權。--Temp3600（留言） 2022年11月30日 (三) 03:25 (UTC)回覆
    那麼該如何處理地域問題呢？作為例子，2022年9月管理員選舉中有兩名候選人被質疑「與WMC關係千絲萬縷」「前與WMC的關係緊密」「WMC仍潛伏於社羣中」，可見某些人至今仍不能做到對WMC成員在處理隱私信息（廣義）方面的基本信任。該如何才能確保此類偏見在AFH的申請過程中不會出現，並且不會對申請過程造成干擾呢？或是說AFH權限不接受WMC成員（即大陸用戶）的申請？--Yining Chen（留言|簽名頁） 2022年11月30日 (三) 05:22 (UTC)回覆
    另設用戶組僅是遵循最小權限原則。對於雙面人問題，目前權限機制（無日誌）不能解決，要依靠其他方法。--YFdyh000（留言） 2022年11月30日 (三) 07:05 (UTC)回覆
    我承認這個問題很難回答。維基百科的底層邏輯是信任社群共識，而您的說法意指社群共識本身就存在偏見，要求以另一種權力來源來平衡共識，這涉及複雜的權力平衡設計，恐怕不是我幾天內就能想像出來的。但或許我以下的觀點可稍為安慰：大體而言，社群的權限投票還是講證據的，在RFA的明票年代更是如此。計劃中AFH的申請不是投票，也不會使用securepoll，申請人無須擔心被流言暗箭攻擊而無從反駁。--Temp3600（留言） 2022年12月3日 (六) 15:23 (UTC)回覆

Kriz Ju的建議：提高對AFH的技術要求

  • (！)意見：個人支持方案草稿，綜觀上方站友討論，個人對相關條文微調意見如下：
  • 「申請程序」：「如果您有意申請過濾器助理的權限，請親自到Wikipedia:權限申請/申請過濾器助理權限申請。申請時，經由至少一名已擁有此項權限的回退員，或者具備過濾器相關站務經驗的管理員具名支持後，由具備過濾器相關站務經驗的管理員綜合評估授權；進行授權的管理員不可和前述的具名支持者為同一人。申請者若由於合理因素而無法完成申請條件，可考慮提出具體事由，在客棧尋求協助或發起討論，而擁有相關站務經驗的管理員應對於獲得客棧討論認可的申請者直接完成授權。」
  • 「資格要求」：
  • 6.「經社群討論，認可為高度可信之使用者」
  • 7.「申請者應對正則表達式有基本認識，並且須由擁有相關站務經驗的管理員授權。」個人意見，供參。--Kriz Ju（留言） 2022年12月9日 (五) 19:33 (UTC) --Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)回覆
( π )題外話 &   吐槽：您所編寫的草案條文似乎使用了太多文言表述，導致其理解時有一定難度  囧rz……--Yining Chen（留言|簽名頁） 2022年12月11日 (日) 01:53 (UTC)回覆
(！)意見：OK，已嘗試直接依站友意見對上方條文進行異動。--Kriz Ju（留言） 2022年12月13日 (二) 11:12 (UTC)回覆
(！)意見：個人的想法是，無論是否考評，只有同時具備專業能力和社群信任度的用戶能獲權，因此亦僅能由具備該領域能力的管理員授權，才具備某種程度之公信力，否則管理員自己本身一無所知又何以評估是否授權呢？至於具體考評，是比照其他權限可能出現的審核考評，其實也是考給社群看，以獲公信，個人無甚意見，已依站友意見對上方條文意見調整文字，供參。--Kriz Ju（留言） 2022年12月19日 (一) 17:38 (UTC)回覆
個人感覺這一要求略顯嚴格，唯亦不失為確立其地位的策略。看看社群諸君還有沒有什麼意見了。--Temp3600（留言） 2022年12月27日 (二) 16:27 (UTC)回覆
  • (！)意見：1.整個授權過程中涉及到兩名以上管理員的參與，在實際實行過程中可能存在相當大的困難；2.「具備過濾器相關站務經驗」在判斷標準上可能存在問題。僅對過濾器進行小範圍的修改並不能證明這名管理員就具備操作過濾器的能力。3.假若該提案通過，想要判斷某名管理員是否進行過與過濾器相關的站務處理將變得比較困難。某些管理員可能主要編輯private過濾器，這樣普通用戶就無法對相關問題進行查證。另一方面來說，想要找到某名用戶編輯過濾器的所有記錄也相當困難，除非由社群仿照Wikipedia:監督/統計維護一個「管理員參與過濾器編輯的記錄列表」。--Yining Chen（留言|簽名頁） 2022年12月31日 (六) 04:00 (UTC)回覆
  • 既然社群沒有進一步意見，暫時不提高要求。--Temp3600（留言） 2023年1月8日 (日) 14:27 (UTC)回覆

第一階段公示：確認分拆

現按上方的共識，進行第一階段公示，確認將AF源碼閱讀權(abusefilter-view-private)從回退員權限中移除。本項的實施則預計在整套方案通過後一次過執行。現就此  公示7日。

新用戶組的細則則仍屬討論階段，誠邀各位就獲權細則，除權條件等細節作深入討論。--Temp3600（留言） 2022年11月27日 (日) 17:01 (UTC)回覆

看來公示期結束了。那就等上邊了。--Ghren🐦🕕 2022年12月6日 (二) 10:29 (UTC)回覆
卡。--Temp3600（留言） 2022年12月19日 (一) 03:01 (UTC)回覆

第二階段公示：成立過濾器助理用戶組

現按上方的共識，進行第二階段公示，將草稿:過濾器助理確立為方針。通過後將成立相關的用戶組。現就此  公示7日。先再討論一下。--Temp3600（留言） 2023年1月9日 (一) 14:20 (UTC)回覆

回退員的除權安排將在新用戶組開放申請後再決定細節。--Temp3600（留言） 2023年1月8日 (日) 14:57 (UTC)回覆

(－)反對：上方討論顯然不夠充分，未能達到形成共識的程度。僅有三人參與的討論，且其中還有未能解決的反對性意見，是否能稱作「形成共識」？沒人參與是否等於全部支持？如果反覆在未能形成充分共識的情況下強行推進討論，雖有WP:AGF，但恐怕仍有遊戲共識形成程序的嫌疑。--Yining Chen（留言|簽名頁） 2023年1月9日 (一) 01:34 (UTC)回覆
繼續討論當然很好，但得有人前來。看看下星期如何了。--Temp3600（留言） 2023年1月9日 (一) 14:34 (UTC)回覆
(－)反對：根本就沒明白過濾器助理究竟只是用來查看不公開過濾器的，還是用來修改過濾器的。申請所需要求遠高於該組所具備的權限。--廣雅 范★ 2023年1月9日 (一) 09:04 (UTC)回覆
很明顯沒有修改過濾器的能力啊？--Ghren🐦🕓 2023年1月9日 (一) 09:06 (UTC)回覆
補充了一下我的回覆。想表明的是只是查看過濾器日誌根本就沒必要對正則表達式有基本認識、計劃協助維護中文維基百科的過濾器等。--廣雅 范★ 2023年1月9日 (一) 09:10 (UTC)回覆
如希望查看日誌（即abusefilter-log-private），按現行程式申請回退員權限即可。申請abusefilter-view-private才需要申請這一新權限。此外，回退員如果積極參與反破壞工作，及符合其他基本要求，即可獲批。--Temp3600（留言） 2023年1月9日 (一) 14:34 (UTC)回覆
還是那個問題吧，單純的查看是否需要這麼高的要求。--廣雅 范★ 2023年1月10日 (二) 02:34 (UTC)回覆
至少必須高於回退員，以排除目前向破壞者提供資料的回退員內鬼。--Temp3600（留言） 2023年1月11日 (三) 14:52 (UTC)回覆
但是只是單純查看沒必要硬性要求會正則吧，以及不能編輯的話對過濾器有認識計劃維護過濾器是有什麼意義？--廣雅 范★ 2023年1月12日 (四) 02:53 (UTC)回覆
呃，要看的權限但看不懂正則，那怎麽看懂過濾器的條件？要來幹嘛？--路西法人 2023年1月12日 (四) 03:36 (UTC)回覆
能改過濾器的管理員都沒這個要求，只能看的助理卻有這個要求嗎？--廣雅 范★ 2023年1月13日 (五) 06:45 (UTC)回覆
管理員未必會去看和接觸過濾器，但助理則一定要能理解過濾器。如果助理需要其他人幫助來解讀，不還是「泄密」了。「基本認識」要求似乎不高。--YFdyh000（留言） 2023年1月13日 (五) 06:50 (UTC)回覆
問題在於，「基本認識AF」的要求比「基本認識Regex」要高。比如第51號過濾器，第27號過濾器等，即使某名用戶「基本認識」regex，如果沒有相應基礎，也很難理解其工作原理。--Yining Chen（留言|簽名頁） 2023年1月13日 (五) 11:21 (UTC)回覆
我說的「基本認識」指過濾器功能方面，能判讀多數過濾器就符合查看過濾器的基礎條件（之一），不考慮複雜語法或編輯特徵等檢測。不太明白廣雅範的「單純查看沒必要硬性要求會正則」，是適用哪些人群。--YFdyh000（留言） 2023年1月13日 (五) 12:21 (UTC)回覆
建議對正則表達式有基本認識。如果沒有認識但有必要看到源碼（例如是其他維基的管理員希望抄一份中維過濾器的源碼），自然符合申請原因。--Temp3600（留言） 2023年1月12日 (四) 09:56 (UTC)回覆
這是在基本資格下列出來的欸，而且是要怎樣維護過濾器呢？--廣雅 范★ 2023年1月13日 (五) 06:45 (UTC)回覆
按我所知，目前部分回退員會在站外聯絡管理員，向對方提出修改建議。基本資格方面，的確是希望申請者先了解regex，確認權限對自己有幫助才來申請。然而，如果是抄對碼到其他維基等作業，未必需要懂得regex也可進行，故這不是強制要求。沒有寫成「基本認識AF」應是希望將條件寫得具體些，畢竟有些人看得懂AF的介面也會說自己「基本」懂得AF。--Temp3600（留言） 2023年1月14日 (六) 14:21 (UTC)回覆
@Temp3600、Yining Chen：我覺得倒不如直接問現任的回退員他們之中哪些人是真的用得上AF源碼閱讀權的（至少我在卸任之前完全用不上），然後我們對所有自稱用得上AF源碼閱讀權的回退員逐一詳細審查，確定哪些用戶是可以獲得AF源碼閱讀權的，最後直接分拆權限，把所有獲確認可獲授權的用戶全部批量授權就可以了。我之所以這樣説，不只是因為自己在卸任之前完全用不上AF源碼閱讀權，也是因為在使用「如果不通過就不給人吃飯」的方式後也沒啥回退員前來討論的緣故，這個情況讓我懷疑是不是真的有那麽多人需要AF源碼閱讀權。Sanmosa Συ γάρ μοι και μοίρα εί και τύχη 2023年1月12日 (四) 14:16 (UTC)回覆
我個人預期只有幾十位回退員最終需要這個權限。待過濾器用戶組建立後，我支持在除權先發出通知，讓回退員前來報名，批准後再對回退員組除權。--Temp3600（留言） 2023年1月14日 (六) 14:21 (UTC)回覆
假若討論能夠通過，或許可以提前開放申請，仿照IA和查核助理的方式，列出一個「由社群共識委任的第一批AFH」名單。----Yining Chen（留言|簽名頁） 2023年1月14日 (六) 14:42 (UTC)回覆
我也支持這樣做。--Temp3600（留言） 2023年1月15日 (日) 03:22 (UTC)回覆
在權限設立後初期，恐怕很少有兩名以上管理員能站出來為一名申請人「擔保」。即使到了後期，AFH人數逐漸增加，恐怕也很難找到願意為自己投票支持的用戶。畢竟這種「擔保制」申請權限的方式應該是第一次在中文維基百科應用，誰也不知道會變成怎樣。--Yining Chen（留言|簽名頁） 2023年1月14日 (六) 14:46 (UTC)回覆
未見「擔保」條文，也未理解為何不會有擔保。--YFdyh000（留言） 2023年1月14日 (六) 17:28 (UTC)回覆
草案要求「一名管理員具名支持，一名管理員授權」，這不是在變相要求申請該權限要一名管理員「擔保」？--Yining Chen（留言|簽名頁） 2023年1月15日 (日) 00:14 (UTC)回覆
Draft:過濾器助理和Wikipedia:過濾器助理草案頁面中，我沒看到這種要求，煩請指明原文？--YFdyh000（留言） 2023年1月15日 (日) 03:00 (UTC)回覆
Yining Chen所指的任命條件經討論後，最終沒有納入方針中。--Temp3600（留言） 2023年1月15日 (日) 03:20 (UTC)回覆
敝人在此對個人構想稍作澄清。首先，請站友切勿曲解並詮釋為「擔保」，敢問怎麼擔？怎麼保？要拿什麼擔保呢？若這樣講，所有的「提名」或「推薦」、「支持」通通都算是擔保了嗎？其次，最初的設想，之所以會存在可先由一名管理員提名或支持，是為了解決若將該權限直接拆分，第一位獲權者如何產生的問題；換言之，往後的申請者不須非得由管理員支持或提名才可申請，因此自不存在所謂一定要「兩位管理員」才能申請一說。再次，即便真需要兩位管理員，也不過是執行層面的問題而已，如果社群中不存在足夠的具備相關經驗和技術之管理員（真沒有嗎？）或門檻過高，自可再議，否則動輒以不具實質證明之「恐怕如何如何」之預想或預設立場（邏輯上和「恐怕不會如何如何」是差不多的意義，眾人都用「恐怕這樣那樣」，其他人也可以說「其實不會」，各說各話），個人認為於討論上難有裨益。最後，若社群認為此類門檻過高，自可調整降低，個人無甚意見。真正重要的地方在於，獲權者彼此間若都會協同經手維護過濾器的話，能看到內部設計的人就是那一群而已，理想上多少自當相互信任，而不是互相懷疑，這樣的門檻就是為了確保能獲權的用戶是具備相當信任度和技術能力的，而且人數是否真的需要那麼多，仍部分取決於實務需求和社群之信任，講白了以後若有其他問題導致相互懷疑，也是持權用戶間的爭議了。--Kriz Ju（留言） 2023年1月15日 (日) 14:10 (UTC)回覆
還希望您能保持冷靜。首先，本人只是將個人經過思考，預想可能會發生的事情用某種方式寫出來，供大家來參考，並沒有以此為理由故意阻礙社群通過討論。如果有人認為我在胡言亂語，杞人憂天，可以選擇忽視。畢竟前人說「實踐是檢驗真理的唯一標準」，如果大家都同意，完全可以現在就把這個方針草案立刻付諸實踐。這樣就徹底消除了別人說「恐怕」的所有機會（但這樣是否是WP:POINT還有待商榷）。其次，有了第一名AFH，那選第二名時會不會變成「與第一名AFH關係好壞的評選」？如果第一名AFH直接站出反對候選人該怎麼辦？如果您的提案被社群初步認可，這些問題或許都要更深入的思考和討論。( π )題外話：本人在語句中摻入大量的「恐怕」「或許」等詞彙這種行為，是早期在某種特定環境下寫作的產物，希望您能諒解。--Yining Chen（留言|簽名頁） 2023年1月15日 (日) 14:53 (UTC)回覆
(！)意見：無妨的，您不用擔憂，我相當冷靜，亦無任何強求。個人只是期待，眾人對他人未指明之概念，或未明言之事，請盡可能避免替他人註記或視為他人所言，甚而持續延伸，何況所謂「擔保」與這裡的實務實在相差甚遠，試問這裡的誰願意為誰拿出什麼條件真正擔保過什麼呢？至於個人對任何提案或構想，一向抱持可參考、可討論之態度，若（已）無興致或共識，隨意看看即可，有興趣參考、沒興趣拉倒，無傷大雅的。敝人並非認為是所謂杞人憂天之類，只是不喜歡太多所謂訴諸恐懼的訴求（當然您也有合理的考量），此類訴求和手法顯然氾濫使用於社會中，任何構想適合或適當與否，討論即可，當然這種說法也只是我個人偏好罷了（笑）。
至於您提到「與第一名AFH關係好壞的評選」之擔憂，確實有道理，不過第二名申請者（或之後的任何用戶）仍可透過兩位管理員（或之後的其他獲權回退員）支持，或是如敝人提及的，自認能力和信任度皆具備的用戶，若認為受到不公待遇，導致無法獲得任何適當支持，亦可考慮於客棧請社群品評，做為可能的救濟途徑；而這也是為何個人認為理想上應該直接於申請時進行公開考評之故，當然必然也會存在有人作弊或找代打之類的疑慮，然而哪項申請又可以完全杜絕所有疑慮呢？回過頭來，若要僅僅提及「關係好壞」，個人傾向以兩個層面觀之，表面而言，與任何特定用戶之關係深淺，的確影響是否具備信任度，然而這部分還是得回歸管理員之專業判斷和操守，若管理員不吃這套，試問關係好又如何呢（自然這點除了挑戰人性，也必然永遠有爭議）？另一方面，信任度的基礎其實有相當部分來自於社群對特定用戶的「熟悉度」，而熟悉度又來自於用戶平日於平台的公共領域（如社群活動、競賽、站務、榮譽表揚，或公開討論等領域）之實質貢獻、投入和活躍與否（自然包含曝光度之類），換個角度看，或許較有機會獲得社群信任的用戶，在公領域常具備至少部分用戶對其擁有之熟悉度，這是可以透過人為努力達成的。無論如何，正因總有爭議，個人才傾向或許可以考慮設定申請考評，如此而已。其實說實話，不論是這裡，抑或現實社會，所謂「靠關係」，實為常態，即便這裡的管理人員選舉和信任度亦無法避免此種爭議（講白了就是只要我看你不順眼你再厲害我也不會投給你或支持你什麼的），但吾人是否應該放棄其他可能性呢？
退一步而言，不論制度如何設定或規劃，皆難以排除各種或所有疑慮，又或是總有各種「不公」（不論是否真實存在或真是如此），於社群中始終存在難以有效消除、緩解之隔閡或爭議，那麼個人認為此即可視為當下社群風貌和需求的「現實表現」了（現實世界中此類情事亦然）。--Kriz Ju（留言） 2023年1月15日 (日) 19:59 (UTC)回覆
AFH需由管理員授權，這與目前其他權限的授權方式相同。這只代表管理員確認了社群達成的共識，難言是管理員對此的擔保。「管理員具名支持」方面，考慮到目前管理員團隊有不少活躍成員，幾可肯定會有管理員維基人參與AFH申請的討論，如擔心AFH討論過於寛鬆，可先實行一兩個月後再檢討。--Temp3600（留言） 2023年1月24日 (二) 17:26 (UTC)回覆

User:防濫用過濾器

最新留言：1 年前10則留言6個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/技術。執行者：Jimmy-bot（留言） 2023年3月26日 (日) 08:14 (UTC)。回覆

各位好，我最近留意到User:防濫用過濾器取代了User:濫用過濾器（見日誌），但是User:防濫用過濾器的用戶頁被掛了{{indef}}。另外也留意到User:Xiplus在m:SRP提出移除User:防濫用過濾器的管理員的權限。請問是否有系統錯誤？Xiplus--132.234.228.26（留言） 2023年3月15日 (三) 03:21 (UTC)回覆

User:防濫用過濾器建號時間也很長，不過最近才動作，可能是最近有人改了translatewiki上的名字導致用戶名配置變了，好像這個是可以通過這種方式控制的。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月15日 (三) 03:31 (UTC)回覆
translatewiki:MediaWiki:Abusefilter-blocker/zh-hans，看上去是改過。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月15日 (三) 03:34 (UTC)回覆
@Shizhao：，真的要改？——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月15日 (三) 03:46 (UTC)回覆
我就是照着繁體翻譯改的。。。沒想到會這樣--百無一用是書生 (☎) 2023年3月15日 (三) 06:41 (UTC)回覆
本地真正生效的應該是MediaWiki:Abusefilter-blocker，沒有的話按照語言fallback應該是hans，我們項目的名字運用獨特，所以才搞出這樣的差異化名稱。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月15日 (三) 07:00 (UTC)回覆
不太明白實際機制。因為還存在translatewiki:MediaWiki:Abusefilter-blocker/zh-hant，名字也不一樣，但好像沒找到這個賬號的使用。translatewiki:MediaWiki:Abusefilter-blocker/zh-yue在zh-yue-wiki是有正確使用的。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月15日 (三) 03:45 (UTC)回覆
挺有意思的一件事，可考慮將討論串存檔到WP:管理員或WP:管理員名單。--東風（留言） 2023年3月15日 (三) 15:20 (UTC)回覆
感覺不要「防」字比較好。 ——魔琴 [ 萬戶涕淚 ] 2023年3月16日 (四) 06:58 (UTC)回覆

Global RfC filled to enable global abuse filters on large Wikimedia projects by default

最新留言：1 年前18則留言7個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/技術。執行者：Jimmy-bot（留言） 2023年6月16日 (五) 16:14 (UTC)。回覆

多週無新留言，關閉之。如有新進展請另開新討論。--SCP-0000（留言） 2023年6月6日 (二) 12:35 (UTC)回覆
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
您好!

Apologies for writing in English. 請幫助翻譯至您的語言.

On Meta-Wiki, a set of global abuse filters is maintained by Meta-Wiki's administrators and the stewards. Global abuse filters are a powerful tool designed to fight against long-term abusers that operate cross-wiki. It is especially useful (and often irreplaceable by other means) when a cross-wiki LTA starts to rapidly change IP addresses (when that happens, regular blocks are significantly limited due to the IP hopping).

As of today, all small/medium Wikimedia projects (as-determined by number of articles) are automatically subscribed to global abuse filters. They are not, however, enabled on several Wikimedia projects classified as large (except several large Wikimedia projects who opted-in, such as Wikidata). This makes it possible for global long-term abusers to vandalize a project with no global filters enabled, which makes it significantly more difficult for the Stewards to fight against the abuse.

By this message, I'd like to let you know I submitted a global RfC (request for comments), where I propose enabling global abuse filters on large Wikimedia projects as an opt-out feature. This change will make global abuse filters an even more effective tool for combating long-term abuse at the global level. Please feel free to participate in the discussion, which happens at Meta-Wiki.

Thank you for your time.

Sincerely,
--Martin Urbanec (討論) 2023年3月12日 (日) 17:15 (UTC)回覆

不詳盡的翻譯：元維基啟用了全域濫用過濾器，所有中小型維基項目（根據條目數）默認自動訂閱這個過濾器組，大型維基項目除非申請了的（例如維基數據）外都未啟用，認為這不利於打擊全域破壞者，所以申請了一個全域RFC，提議將在大型維基項目啟用這個功能作為選擇排除選項，歡迎到元維基參與討論。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月13日 (一) 00:34 (UTC)回覆
二次省流：有人提出將全域過濾器從自願加入制，改為默認啟用、自願退出制。--MilkyDefer 2023年3月13日 (一) 06:19 (UTC)回覆
需要召喚一些管理員看一下？我看有些本地過濾器實際是引進en版本的，或者少部分可以通用的通過這個機制沿用？但也說了，這會強化全域對本地社群的控制。（It will greatly improve the response to cross-wiki vandalism and spam, while also increasing community control over these global actions.）——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月13日 (一) 06:22 (UTC)回覆
@KOKUYO、淺藍雪、Mys_721tx、Kolyma：，很抱歉打擾，因為你們是我用在線管理人員檢查看到的。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月13日 (一) 06:31 (UTC)回覆
@Shizhao、Xiplus、Jimmy Xu、Ericliu1912：，很抱歉打擾，因為你們是我想到管理員就會想到能找到的人。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月13日 (一) 06:31 (UTC)回覆
以上有興趣的去元維基看一下，看是否加入或者退出。如果覺得無關的話，那再次說聲打擾了。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月13日 (一) 06:31 (UTC)回覆
我意見是，有多少全域LTA類能打到zh區這邊而需要這些過濾器，或者有多少通用的好的過濾器需要通過這種方式引入。從其中一個日誌追去當地項目來看，似乎一旦啟用，本地無法單獨拒絕這些全域過濾器的個別。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月13日 (一) 06:39 (UTC)回覆
我覺得從zhwiki管理現狀上來說，能甩出去給別人打理真是減少積壓工作的好辦法--百無一用是書生 (☎) 2023年3月13日 (一) 07:29 (UTC)回覆
@Shizhao：，但我認為現在這樣全局加入再單獨剔出的做法可能不夠靈活，這個全局過濾器「要麼全部不要，要麼全部接受」，沒法控制特定過濾器在本地的啟用禁用。而且我留意到少部分針對特定內容主題的隱藏過濾器存在，一來可能不知道裡面的規則怎樣寫，會不會變成一種另類的使用；二來可能存在語言不適配的問題（可能只針對英文等拉丁語境，而不是針對我們本地的中文等）。一些中小型站點參與人少，為了節省管理人力，可以考慮全部接收（見過de-source是沒有本地過濾器了，全盤用全域過濾器），但對於我們大型站點，人手尚足，如果跨站點破壞很少影響到我們（而用不着針對跨站點的過濾器），可以通過單獨啟用個別全域過濾器來引進一些通用性較強的優質過濾器，可能更好。或者維持現狀，大型站點默認不加入，可以單獨加入。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月15日 (三) 01:32 (UTC)回覆
我個人覺得能增進反破壞效能是好事。不過對於影響本地的全域隱藏過濾器，是不是考慮推舉幾位本地維基人做濫用過濾器助理之類的，以便查閱？或要求全域社群直接允許本地管理員或特定人士查閱？—— Eric Liu 創造は生命（留言・留名・學生會） 2023年3月21日 (二) 05:42 (UTC)回覆
可以，所以我認為至少全域過濾器能允許有本地私有過濾器查看權限的用戶查看（或者對應的功能權限）（這個看了過濾器的權限表，看不出有類似的權限或者功能），和本地控制是否啟用的權限，才考慮大型組全入再選擇退出，類似的問題很早提出了，但基金會的開發不以為然，至少對於這種問題不能盲目點頭。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月21日 (二) 06:34 (UTC)回覆
如果管理員有需要查看全域過濾器，可以申請成為全域的 Abuse filter helpers 或是元維基的受限管理員。另外，目前本站有權限查看全域過濾器的管理員為：Jimmy Xu、Jusjih、Shizhao和WhitePhosphorus，供參考。--SCP-0000（留言） 2023年3月21日 (二) 06:43 (UTC)回覆
@Ericliu1912、Mys_721tx：，en宣告退出了（en:Wikipedia:Edit_filter_noticeboard#Global_abuse_filters_applying_here）。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月21日 (二) 06:38 (UTC)回覆
我認為基金會又犯了大石壓死蟹的壞習慣（當年的媒體查看器和超級保護機制），而且某些人也有盲目跟隨基金會的習慣。大項目en率先表率，而且相關項目的人對於一些意見似乎有點不以為然的樣子。（根據討論的一些內容，關於全域私密過濾器的內容，給出的方案是自己發郵件問元維基的人拿代碼內容；對於是否本地啟用，給出的方案是發信息讓元維基的人在過濾代碼中加入站點剔除），或者我們社群有沒必要也考慮「退出先」的意見？——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月21日 (二) 06:44 (UTC)回覆
好像還有一個新的相關提案：Meta:Requests_for_comment/Create_local_meta_abuse_filter_helper_and_abuse_filter_manager_role（給本地項目的meta的AFH和AFM（？）），討論度還行，好像反對和支持相當，但更多不支持AFM。Commons也在討論中，討論度不算高，建議退出（認為這個RFC能通過）和建議保持入（認為需要分擔本地管理壓力）的大致持平。——Sakamotosan路過圍觀 | 避免做作，免敬 2023年3月29日 (三) 06:34 (UTC)回覆
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。

應標明觸發過濾器的問題點

最新留言：1 年前1則留言1個人參與討論

可否標明觸發過濾器問題點的區塊，每次遇到連續觸發都要試很久碰運氣找問題點。——Cbls1911（留言） 2023年8月13日 (日) 01:55 (UTC)回覆

必須防止濫用「防濫用過濾器」

最新留言：6 個月前23則留言17個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2024年6月12日 (三) 00:14 (UTC)。回覆

我現在按捺住怒氣好好的請問各位有權在防濫用過濾器加東西的各位。請問有什麼方針可以防止濫用這個過濾器？要加東西前有商議過嗎？有測試過嗎？有累積被誤判的文字作為測試資料嗎？有定時巡察修正嗎？加錯了東西有人給予提醒嗎？封鎖範圍太大有檢討過嗎？修正之後有公佈被修掉的敏感詞以防後來又被不明事理的ＸＸＸ加回去嗎？啊？

還是正如我所想，愛加就加，加了不管。有人反應就來來回回你一言我一語表示自己沒錯，單純你唔註冊你唔好彩？把人的熱情磨掉再來慨嘆人手不夠嗎？把人磨出怒氣講話不客氣再來封殺嗎？有權力加東西的人就這樣把成本轉嫁給別人嗎？啊？

上次在反應的過程中，道理講不過就偷加CAPTCHA玩人。這次就看又要講出什麼道理，又要中途加什麼東西玩人。--2603:8000:500:FB00:19E0:922D:68FA:F58（留言） 2024年5月16日 (四) 01:52 (UTC)回覆

從日誌來看，你觸發的是Special:濫用過濾器/229，應該是你加入「頂尖」這兩個字觸發了。--世界解放者（留言） 2024年5月16日 (四) 02:12 (UTC)回覆
如有任何對防濫用過濾器的任何問題，請至維基百科:防濫用過濾器/錯誤報告反應。--唔好阻住我愛國（留言） 2024年5月16日 (四) 02:13 (UTC)回覆
他已經去反映了。--世界解放者（留言） 2024年5月16日 (四) 02:17 (UTC)回覆
這個過濾器229真是令人好氣又好笑，果然是被濫用了。說濫加的人是不明事理的ＸＸＸ果然沒說錯。不但不明事理，而且是頂尖的不明事理。硬要限制？那我說你是一流的無敵的沒人比得上的不明事理，是不明事理中的首選、頭號、頭牌、王牌、天王、教主。是天字第一號的不明事理，是天下無雙地上獨有的不明事理。我就是要告訴濫加的人，這種限制除了逼人發脾氣外，有多麼無意義。
所以之前的問題仍然成立：
＊加敏感詞之前有沒有經過商議？有沒有經過測試？還是愛加就加？行使這種濫殺無辜的權力後再來扮可憐說其實沒什麼權力？
＊加了之後是否定期審議？還是就長長久久的放在那裡等人一頭撞上去？
＊終於良心發現拿掉不合理的限制後，是否保留被誤殺的篇章作為以後的測試資料？還是就算了，反正下次再濫加？
究竟標準在哪裡？你要嘛把我上面的形容詞，以及我漏掉的，全加進去。要嘛拿掉這莫明其妙不明事理的濫用。因為現在很明白了，是「防濫用過濾器」被濫用了。而且看來打算要用到濫。
不過，比較可能的是，要嘛，講出個歪理來看看；要嘛，裝死。反正愛加就加，其奈我何。生氣你自生氣，好官我自為之。--2603:8000:500:FB00:19E0:922D:68FA:F58（留言） 2024年5月16日 (四) 05:40 (UTC)回覆
然後CAPTCHA並不是什麼偷加的，本來就是自動確認使用者才不會出現。--冥王歐西里斯（留言） 2024年5月16日 (四) 08:14 (UTC)回覆
過濾器229並非阻止原因，該過濾器只有標記的動作。阻止2603編輯的是一個私有過濾器。 ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月16日 (四) 12:12 (UTC)回覆
見[12] ——魔琴［身份聲明 留言 貢獻 新手2023］ 2024年5月16日 (四) 12:13 (UTC)回覆
在條目中加入的詞被有權的人不喜歡，叫濫用。那在「防濫用過濾器」中濫權濫加，是不是濫用？是不是也要防濫用？
要說不是濫用，那在「防濫用過濾器」中增減敏感詞，有沒有方針？有的話，合不合理？有沒有遵守？沒有的話，要不要立方針或指引？憑個人喜好濫加，是不是濫權？過濾器居然還有私有的。說偷加，就本來沒有。還硬要說本來怎樣怎樣，當別人今天才來受氣的嗎？
有這種愛加就加的大權，就再也不要裝可憐說沒有什麼權力，太令人反感了。人被機械式過濾玩弄的耐性是有限的。做人差不多一點，好好檢討一下現有的敏感詞，不要沒事把平常人逼成破壞者再來抱怨。--2603:8000:500:FB00:DC0B:D5AF:D934:304B（留言） 2024年5月16日 (四) 23:21 (UTC)回覆
不是229，是隱藏過濾器201導致的編輯不成功。這個過濾器的增添刪簡確實沒有任何公開正式討論的過程，因為本質上是隱藏的。而且確實是一個規則內容很長很長的過濾器，至少有幾百到一千條規則，一眼看不出來具體觸犯了哪個部分。總的而言他過濾的是加入「畜生、吊你老母」這樣的詞彙，其近期的記錄表明這個過濾器還是相當有價值並且誤報率並不高（我翻查了15個最近過濾結果，基本全都是簡單的純破壞行為，比如將張某人改為吊某人）。ps 我看到最近有一名管理員Xiplus去除了一條規則，這個規則寫的太不嚴謹導致誤判了「黑人警察」這個詞，我確定就是這個規則導致的編輯失敗。現在這個問題已經獲得改正了。我將您之前未能加入的文字暫存在這裡，以利您繼續編輯，我通過測試功能確認這些文字現在可以直接加入。Bluedeck 2024年5月17日 (五) 08:32 (UTC)回覆
這種隱藏過濾器之所以隱藏，其理論是，如果公開，那麼在大家都知道具體規則了，就可以更有效的繞過去。感覺有點黑箱政治的意思，但是同時也有實用上的理由。Bluedeck 2024年5月17日 (五) 08:52 (UTC)回覆
黑箱政治是問題，但黑箱到連內部的人都沒弄清楚是黑箱中的哪一條出問題，那這問題可真大了。你看前面有多少人指出了錯的過濾器？意思是任由少數知情人藏下去的話，大部分人都會搞不清楚情況，然後這個問題會一直持續下去（因為修錯地方了嘛），你覺得這可以繼續下去？都不用有個方針？
加東西前要求測試這不過份吧？加這條不嚴謹導致誤判的規則時有沒有測試？用什麼測試？自己滾出來講！
測試材料也是現成的，就典範條目。摘幾條典範條目濾一濾，如果撞上了，要麼典範條目有問題，要麼這勞什子過濾器新加進去的東西有問題，看要怎麼修。如果說得出測試了幾十條典範條目都沒出問題，那我服氣。不去計較是否有人刻意鑽漏洞，「黑人警察」這種詞不拿劇情或時事相關條目測試，專拿不可能碰撞的條目測試之類的。但現在拿得出來嗎？還是那句話，濫權濫加濫殺無辜！
所以說，要測試！不但要有現成的測試資料庫（典範條目），像這樣新撞上的文字也要留著當測試資料，防止以後又來一次！
而這勞什子過濾器的真正目的也要討論一下，是拿來擋人，還是拿來擋文字？拿來擋人顯然用錯工具，雖然我瞭解是為什麼會這樣用，但我很不高興在回應的訊息中暗示我可能是破壞者。每多暗示一次，就多增我一分成為真正破壞者的意圖。如果是用來擋字詞，那不是該列出來讓大家別去碰嗎？上面示範過怎麼繞過去了。把擋文字的工具拿來擋人，然後為了不讓想擋的人繞過去所以要神秘兮兮，荒謬嘛這是。因為現有的鐵鎚不好用，你拿螺絲起子的柄當榔頭敲釘子，為了好敲而禁止在柄上纏膠帶防止手滑，這說得過去嗎這？
我建議在下次有人撞上這種詭雷前，拿這勞什子過濾器把典範條目濾一濾，看看上面說的設測試資料庫是否合理，也測測看過濾器的勞什子規則中藏了多少污納了多少垢！有人喜歡自設詭雷炸掉別人編寫條目的熱情，讓被炸到發脾氣的人在此和一堆人內耗，我可一點都不喜歡。更好笑的是，這麼多人誠心誠意的想解決問題，卻都不得其法，就只因設詭雷的人的自以為是！
方針！測試！--2603:8000:500:FB00:44A6:A5DD:7D90:E64F（留言） 2024年5月17日 (五) 22:31 (UTC)回覆
暫存的東西可以拿掉了。本人天縱英明文采斐然，重頭再來有何難，又何需那種東西。重點不是幫人暫存東西，是要掃除障礙。有功夫測這個，不如拿去測典範條目，看看過濾器裡所設的限制合不合理。--2603:8000:500:FB00:A0C9:E784:E1E2:73B8（留言） 2024年5月27日 (一) 05:54 (UTC)回覆
Calm down, we are fixing these filters by writing better regex. If you wanna help, why don't you register an account to give us some advice?
GT:冷靜下來，我們正在通過編寫更好的正則表達式來修復這些過濾器。 如果您想提供幫助，為什麼不註冊一個帳戶來給我們一些建議呢？ -Lemonaka 2024年5月17日 (五) 11:59 (UTC)回覆
You want to encourage people to register? make the Wikipedia so attractive to editors that outsider doesn't want to miss it, not to make it so inconvenience to force others join in, OK?
想鼓勵大家註冊？那就讓維基百科對編輯者具吸引力，令人不想錯過。不是刻意造成不便來逼人加入，好嗎？--2603:8000:500:FB00:44A6:A5DD:7D90:E64F（留言） 2024年5月17日 (五) 21:51 (UTC)回覆
如果討論發起者的目的是想要中文維基百科完全廢除過濾器的話，那中文維基百科是不可能做到這樣的要求的。Sanmosa 人人皆王 2024年5月19日 (日) 01:38 (UTC)回覆
不是廢除過濾器，是在過濾器中增減敏感詞時要有方針。方針中最重要的是制定測試方式，以期完善。否則任由有權者愛加就加，不是辦法。--2603:8000:500:FB00:384E:8A02:8171:3A9（留言） 2024年5月19日 (日) 02:53 (UTC)回覆
主要是你維總有那麼幾個長期破壞者一直搞鬼祟破壞，必須要用過濾器來防止這幫傢伙胡鬧（不然總不可能對着新IP的所有編輯一筆筆看過去來查是不是這幾個貨搞的鬼吧？）。過濾器雖然確實噁心人，但只能兩害相權取其輕了。事實上註冊賬號並提到自動確認以上就不用理會驗證碼和絕大多數過濾器了。——Aggie Dewadipper 2024年5月20日 (一) 21:42 (UTC)回覆
你這說的雖然對，但是沒有抓住重點。我都想好怎麼反駁了：「破壞者也能註冊賬號提升到自動確認繞過Captcha和大多數過濾器，讓這些東西形同虛設，只剩下噁心IP使用者的用途。」--MilkyDefer 2024年5月21日 (二) 04:11 (UTC)回覆
提升到自動確認還是有成本的，並且自動確認之後搞破壞會被查封，那麼這個自動確認就白費了。絕大多數人破壞維基百科並不是當作事業，要是難度門檻稍微高一點，就會罷手，所以目前的這個設計是經過一定程度博弈的結果。這次的事情確實我感覺說明了隱藏式AF一旦出問題會造成巨大的困惑，添刪前需要小心。Bluedeck 2024年6月1日 (六) 10:07 (UTC)回覆
@Bluedeck：或是考慮給管理員寫一個「過濾器撰寫指導」之類的手冊？—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月1日 (六) 17:04 (UTC)回覆

過濾器創建方針討論

最新留言：5 個月前15則留言10個人參與討論

本主題或以下段落文字，移動自Wikipedia:互助客棧/方針。執行者：Jimmy-bot（留言） 2024年6月28日 (五) 08:14 (UTC)。回覆

不通過
提案人誤解模板編輯員職能，此話題沒有實際意義。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:55 (UTC)回覆
下列討論已經關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
現行條文

防濫用過濾器是一個可以針對所有最近編輯動作進行自動化判斷的軟件系統。管理員可以針對特定的用戶行為設定過濾器，過濾器被觸發時可進行特定的操作。

提議條文

防濫用過濾器是一個可以針對所有最近編輯動作進行自動化判斷的軟件系統。管理員及模板編輯員可以針對特定的用戶行為設定過濾器，過濾器被觸發時可進行特定的操作。

這種改善制度不僅能夠加快編寫過濾器的效率，而且有更多人可以修正維基百科:互助客棧/方針#必須防止濫用「防濫用過濾器」的問題。--WiiUf ——青龍出世，傲視蒼穹 2024年6月7日 (五) 04:14 (UTC)回覆

你對過濾器的能力認知不足啊。過濾器有能力阻止某一特定使用者的一切編輯，形同封鎖。--MilkyDefer 2024年6月7日 (五) 04:26 (UTC)回覆
不是有過濾器助理嗎，怎麼扯到模板編輯員。而且增人會增加問題和編輯戰，沒解決問題。--YFdyh000（留言） 2024年6月7日 (五) 04:34 (UTC)回覆
要不就單獨設一個過濾器創建員?--WiiUf ——青龍出世，傲視蒼穹 2024年6月7日 (五) 04:47 (UTC)回覆
不需要，是需要比較明確的流程、參與者和至少兩名活躍的管理員。--YFdyh000（留言） 2024年6月7日 (五) 05:23 (UTC)回覆
好像過濾器不支持根據用戶組來控制可以配置的過濾器選項。而且Wikipedia:模板編輯員主要是用來處理高風險模板的編輯，根本不適合用來處理過濾器編輯工作。提案者有沒仔細研究這些規則和配套的技術說明？例如前面的Wikipedia:修訂巡查，那東西基金會嫌太笨重了不好用，已經不允許再新開了，相關的權限問題討論根本沒必要。——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月7日 (五) 05:46 (UTC)回覆
看了下提案者的註冊時間……嗯~——Sakamotosan路過圍觀 | 避免做作，免敬 2024年6月7日 (五) 06:01 (UTC)回覆
不妥，模板編輯員目前和過濾器助理的條件並非完全重疊（當前的條件限制可以讓一個人是模板編輯員但不能申請成為過濾器助理），而且不認為模板編輯員就一定有辦法改防濫用過濾器。--SunAfterRain 2024年6月16日 (日) 13:40 (UTC)回覆
跟模板編輯員有什麼關係？……--冥王歐西里斯（留言） 2024年6月17日 (一) 03:16 (UTC)回覆

附加條文

當過濾器被觸發時，模板編輯員可以設定如下操作（大致根據行為的嚴重程度從輕到重排序）：

  • 所有觸發過濾器的行為均會被記錄在特殊頁面的日誌中。（強制，無法取消）
  • 給用戶的操作加上標籤，以便進一步的核查。
  • 用戶收到警告訊息。
  • 用戶的操作被阻止。
  • 用戶的自動確認狀態被隨機取消5天。
  • 封鎖使用者帳號或IP位址（可分別指定期限）。
  • 用戶的所有用戶群組被移除（例如機械人、管理員、回退員等）。（本地未啟用）

—-WiiUf ——青龍出世，傲視蒼穹 2024年6月7日 (五) 04:38 (UTC)回覆

技術上不能阻止有編輯過濾器權限者設定封禁、取消自動確認等過濾器。而且我也不確定新設立一個權限組是否能有效提升過濾器請求受理活躍度。此外，模板編輯和過濾器無關，過濾器編輯者應該精通正則表達式，而不是模板。--桐生ここ★[討論] 2024年6月17日 (一) 07:01 (UTC)回覆
僅僅因為觸發過濾器而被處罰，這和文字獄有什麼區別呢？（特別是現在的中文維基百科存在一些不合理的過濾器）--Leiem（留言·簽名·維基調查） 2024年6月25日 (二) 02:17 (UTC)回覆
模板編輯員權限與濫用過濾器毫無關聯，此顯係提案人誤解。—— Eric Liu 創造は生命（留言・留名・學生會） 2024年6月25日 (二) 02:55 (UTC)回覆
本討論已關閉，請勿修改。如有任何意見，請在合適的討論頁提出，而非再次編輯本討論。
新增話題
取自「https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:防滥用过滤器&oldid=83199487」
返回專案頁面「防滥用过滤器」。