维基百科讨论:防滥用过滤器

页面内容不支持其他语言。
维基百科，自由的百科全书

防滥用过滤器[编辑]

本主题或以下段落文字，移动自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)[回复]

防滥用过滤器能否再智能些[编辑]

在下最近在撤销条目云国的破坏时被防滥用过滤器警告：“[”或“]”缺少和没有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)[回复]

能不能在预览的时候就触发？[编辑]

及早发现及早治疗—Hkhk59333 (留言) 2009年11月6日 (五) 00:02 (UTC)[回复]

能否在用户触发过滤器时告知不可靠的链接？[编辑]

过滤器有个不好的地方就系没告知哪些链接是触发过滤器的，

只是草草地告知用户哪些是不可靠来源，

看过滤器运作日志也很难发现，

以后能否在用户触发过滤器时告知哪些链接是不可靠的链接？（我指的是细分到哪一个链接） 以及日后过滤器的运作能透明化，好让用户注意这些问题。

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

有关防滥用过滤器[编辑]

目前中文维基百科有大量过滤器，当中约一半为“隐密”。不知从那一个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标签[编辑]

本主题或以下段落文字，移动自Wikipedia:互助客栈/技术。执行者：Jimmy-bot（留言） 2017年2月8日 (三) 16:42 (UTC)。[回复]

如题，刚刚找了两个过滤器测试，发现只需用nowiki便可绕过之，详细如下。

另外，我怀疑html注释语句<!-- -->也有同样的效果。不过懒得测试了，困死了。

以上。没怎么在!(article_namespace == 0)的地方写过这么长的东西呢，如果有什么问题还请见谅。 --砜中嘌呤的白磷萃取 打谱 2017年1月25日 (三) 19:02 (UTC)[回复]

注释[编辑]

  1. ^ 准确地说是“非管理员且非确认用户”，但后者在中维太少见，为保证简洁故略去

有关用户贡献中“滥用日志”一词的修改[编辑]

本主题或以下段落文字，移动自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)[回复]

开启过滤器的自动封禁[编辑]

本主题或以下段落文字，移动自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）权限[编辑]

本主题或以下段落文字，移动自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权限组别[编辑]

本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

进一步讨论“滥用过滤器编辑者”事宜[编辑]

本主题或以下段落文字，移动自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的防滥用过滤器在哪？[编辑]

Wikipedia:防滥用过滤器/过滤器请求/存档/2016年以前#WP:HYIP的防滥用过滤器在哪？可找一找吗？ --Wiki emoji | Emojipedia 来笑一下‘’ 2019年6月13日 (四) 10:43 (UTC)[回复]

通过过滤器取消刷编辑数用户的自动确认权限[编辑]

本主题或以下段落文字，移动自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)[回复]
本讨论已经关闭，请勿修改。如有任何意见，请至合适的讨论页进行，并不要再次编辑本讨论。

一些有关维基百科:防滥用过滤器的讨论[编辑]

本主题或以下段落文字，移动自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。

关于权限的疑问[编辑]

本主题或以下段落文字，移动自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)[回复]

过滤器编辑员[编辑]

本主题或以下段落文字，移动自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)[回复]

提议修改维基百科:防滥用过滤器[编辑]

本主题或以下段落文字，移动自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[编辑]

本主题或以下段落文字，移动自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注释代码在编辑条目的使用[编辑]

本主题或以下段落文字，移动自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)[回复]

再提拆分回退员之私密过滤器源码阅读权至另一用户组[编辑]

本主题或以下段落文字，移动自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:防滥用过滤器[编辑]

本主题或以下段落文字，移动自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[编辑]

本主题或以下段落文字，移动自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)[回复]
本讨论已关闭，请勿修改。如有任何意见，请在合适的讨论页提出，而非再次编辑本讨论。

应标明触发过滤器的问题点[编辑]

可否标明触发过滤器问题点的区块，每次遇到连续触发都要试很久碰运气找问题点。——Cbls1911（留言） 2023年8月13日 (日) 01:55 (UTC)[回复]

取自“https://zh.wikipedia.org/w/index.php?title=Wikipedia_talk:防滥用过滤器&oldid=78489742”