「Wikipedia:編集フィルター/提案」の版間の差分
削除された内容 追加された内容
→安倍晋三銃撃事件における被疑者名記載の繰り返し緊急対策: リバートしました。偽陽性を増やすようなキーワードを追加するのはやめてください |
→安倍晋三銃撃事件における被疑者名記載の繰り返し緊急対策: 返信コメント |
||
| 516行目: | 516行目: | ||
* {{報告}} 既に対応済みであった平仮名・カタカナ・氏名入れ替え・組み合わせ等の対応を強化しました。上記情報のケースにも対応しております。また、他フィルター(160)で抑止していたsummary, page_prefixedtitle, user_nameへの対処を本フィルターに集約しました。--[[利用者:えのきだたもつ|えのきだたもつ]]（[[利用者‐会話:えのきだたもつ|会話]]） 2022年7月19日 (火) 16:14 (UTC) |
* {{報告}} 既に対応済みであった平仮名・カタカナ・氏名入れ替え・組み合わせ等の対応を強化しました。上記情報のケースにも対応しております。また、他フィルター(160)で抑止していたsummary, page_prefixedtitle, user_nameへの対処を本フィルターに集約しました。--[[利用者:えのきだたもつ|えのきだたもつ]]（[[利用者‐会話:えのきだたもつ|会話]]） 2022年7月19日 (火) 16:14 (UTC) |
||
*:まず、えのきだたもつさんの変更をリバートしました（バグ埋め込んでいるので）。詳細は管理者MLに投げましたので以降はそちらで。それはそれとして、[[Wikipedia:削除依頼/安倍晋三銃撃事件 20220719]]については、ミスではなく、悪意とまではいきませんがそういう編集を意図的にしないと発生せず、その投稿者に問題があって普通はそういう加筆はありえないと考えるのが自然です。また、そのキーワード自体に偽陽性が十分にありえるので、追加すべきではありません。偽陰性がある程度あって多少は手動が入るのは仕方ないので、偽陰性をゼロにしようとして偽陽性を増やさないようにしてください（それは編集フィルターの趣旨に反します）。--[[利用者:青子守歌|青子守歌]]<small>（[[利用者‐会話:青子守歌|会話]]/[[特別:投稿記録/青子守歌|履歴]]）</small> 2022年7月20日 (水) 10:51 (UTC) |
*:まず、えのきだたもつさんの変更をリバートしました（バグ埋め込んでいるので）。詳細は管理者MLに投げましたので以降はそちらで。それはそれとして、[[Wikipedia:削除依頼/安倍晋三銃撃事件 20220719]]については、ミスではなく、悪意とまではいきませんがそういう編集を意図的にしないと発生せず、その投稿者に問題があって普通はそういう加筆はありえないと考えるのが自然です。また、そのキーワード自体に偽陽性が十分にありえるので、追加すべきではありません。偽陰性がある程度あって多少は手動が入るのは仕方ないので、偽陰性をゼロにしようとして偽陽性を増やさないようにしてください（それは編集フィルターの趣旨に反します）。--[[利用者:青子守歌|青子守歌]]<small>（[[利用者‐会話:青子守歌|会話]]/[[特別:投稿記録/青子守歌|履歴]]）</small> 2022年7月20日 (水) 10:51 (UTC) |
||
::* {{返信|[[利用者:青子守歌|青子守歌]]さん}} まずは、バグを埋め込んでしまい申し訳ありませんでした。偽陽性どころではなく全くの陰性に対しての誤動作でした。修正後はいつもの様に誤動作を監視していましたので、ご指摘のバグについては発生後まもなく修正しており、リバート前の版では修正済みでした。それについてはご確認の上でのリバートだったのでしょうか？バグの原因は、追加したキーワードには全くなく、正規表現の判定文の組み合わせの不具合によるものでした。引き継ぎ宣言もなく修正したのは申し訳なく思います。しかし、私が修正前の版においても、平仮名・カタカナや組み合わせ表現についても判定されており、もはや悪意のない単純な書き込み除去の域は超えていると思います。それらが悪意のないものか否かの判定も難しくなってきています。また、悪意があるか否かに関わらず、版指定削除は発生しコストが掛かることには変わりありません。フィルター160で同様の判定も行なわれていましたので、同じ様な判定を方々のフィルターで行っていては管理・監視上の負担も増えます。よって、一元管理・対処した方が良いと考え、前記通り本フィルターへの集約を行いました。本フィルターでは当初の目的のみを対処すべきとの事でしたらこのままでも良いと思いますが、一元管理・対処しても良いとの事でしたら、遅ればせながら保守の引き継ぎ宣言を致しますので、お任せいただければと思います。以前も申し上げましたが、編集フィルター記録の日に数回～10回程度の監視は今でも行っており、誤動作修正も行っています（それ故今回のバグも早期対処出来ています）。--[[利用者:えのきだたもつ|えのきだたもつ]]（[[利用者‐会話:えのきだたもつ|会話]]） 2022年7月20日 (水) 12:53 (UTC) |
|||
== 仕様変更提案 == |
== 仕様変更提案 == |
||
2022年7月20日 (水) 12:53時点における版
 | Wikipedia‐ノート:編集フィルター#フィルターによるブロック機能についてに、このページに関する相談があります。（2021年3月） 相談の要約：ブロック機能を有効化することの是非 |
 |
ここは、新しい編集フィルターの作成や、既存のフィルターの（大幅な）仕様変更について、議論したり提案したりするページです。
原則として、新しいフィルターはここで提案し合意形成の後に作成するようにしてください。 やむを得ず合意形成をすることが出来ないまま作成されたフィルターについても、その狙いなどを報告をするように努めてください。
提案と作成
フィルターを提案する前に
Wikipedia:編集フィルター/一覧を参照し、同じ機能のものが既にないか確認してください。
また、フィルターの機能について以下の点に留意してください。
- フィルターはすべての編集を対象とします。それゆえに、例えば、単一ページに加えられた問題のある編集への対処には、編集フィルターの利用は向かないでしょう。
- フィルターはどれも作動に時間をとるので、編集が（およびその他も多少）若干ながら遅くなります。一つのフィルターにつき数ミリ秒程度遅くなるだけですが、フィルターが増えれば合算でそこそこになりえます。
- フィルターがチェックできることには限界があります。もっと複雑で必要不可欠ではない機能（たとえば、ページ内容を掘り下げたチェックが必要な場合や、フィルターシステムでは取得できない情報を必要とする場合など）は、個人のコンピュータやツールサーバ上で別のソフトウェアを用いて行う方がよいでしょう。
新しく提案するには
新しい提案は「提案中のフィルター」の一番上に次の形式で追加してください。
=== フィルターの名前 ===
{{編集フィルター提案|提案中
|目的 = <!-- どんなページ、もしくはどんな利用者に、どんな働きをするフィルターか -->
|理由 = <!-- このフィルターが必要な理由 -->
}}
--~~~~ <!-- 署名を忘れずに！ -->
目的にはそのフィルターの動作仕様、理由にはその動作が必要な理由を書いてください。
具体的なフィルターの発動条件などの提案は歓迎されますが、フィルターの提案するにあたって絶対に必要ではありません。 特に、明確な悪意を持った荒らしに対処するようなフィルターなど、フィルターの詳細を非公開にすべきようなものの場合は、発動条件を詳細に明記し議論しない方が良い場合があるので、注意してください。
新しく提案したものは、テンプレート:編集フィルターの一覧へ載せることができます。
提案から正式稼動までの流れ
以下の手順は草案です。以下の手順に支障や問題、コメントがあればWikipedia‐ノート:編集フィルターで提起してください。
- 新しく提案するにはの手順に従って、新しいフィルターがどんなものか提案してください。
- その作成提案に対して、{{賛成}}や{{反対}}、{{コメント}}、{{問}}などを使って議論し、作成することに対する合意形成をしてください。
- もし、提案後1週間が経過し、2人以上の賛成（提案者の提案者票を含めても良い）があり、かつ反対する人がいない場合は、合意がなされたとみなされます。
- 合意形成がなされたフィルターは、編集フィルター編集者によって新しく作成され、1週間の発動条件の試験と、1週間の対処操作の試験の、合計2週間の試験運用を行ないます。
- 前半の1週間は、発動条件の確認をするための試験が行なわれます。この期間中は、対処操作（ただし、速度制限は発動条件とみなされます）を設定できません。
- 前半の試験期間が問題なく経過すれば、対処操作が付与され、後半の1週間は、対処操作の試験となります。
- 各期間中に問題が発生したあるいは報告された場合は、修正を行ない、期間は修正からさらに1週間延長されます（つまり、修正が加えられると期間はリセットされます）。ただし、反応速度の向上などの微修正の場合は延長する必要はありません。
- 対処操作の試験期間が問題なく経過すれば、試験運用は終了し、フィルターは正式稼働となり、情報はWikipedia:編集フィルター/一覧に過去ログ化されます。
- 正式稼動後に問題が発生した場合は、Wikipedia:編集フィルター/誤作動で報告してください。
非公開フィルターに関する注意
非公開フィルターの作成を提案し議論する場合は、そのフィルターが非公開になる理由によく注意して、慎重に議論あるいは情報提供を行なってください。
特に、明確な悪意を持った荒らしに対処するようなフィルターなどの場合、詳細な発動条件などに関して公開の場で議論を行なうと、そのフィルターの有用性が低下するばかりか、かえって悪用される可能性もあります。
そのフィルターが、本当に非公開にしなければならないような深刻な問題に対するものなのであれば、あなたが詳細を述べなくとも編集フィルター編集者はその意図を十分に汲みとってフィルターを作成してくれるでしょう。
既存フィルターの仕様変更
新しく作成するのではなく、既存のフィルターの動作を大きく変えるような変更、つまり、
- 対処操作の付与と除去
- 通知文の（大幅な）内容の変更
- フィルターの発動対象の操作（発動条件のねらい）の変更
といった、誤作動や誤りなどの訂正でない変更の提案は、仕様変更提案で扱われます。
ログ化
正式稼動もしくはフィルターの作成が合意できなかった提案は、1週間ののち過去ログ化されます。
仕様変更提案は、各フィルターのページに過去ログ化されます。
Wikipedia:編集フィルター/提案/ログをご覧ください。
提案中のフィルター
{{subst:Blocked}}などの荒らし対策
提案中
| 目的 | 管理者以外が{{subst:Blocked}} などの警告テンプレート貼り付けの防止 |
|---|---|
| 理由 | 今後の荒らし対策に繋がる可能性があるため |
| 発動条件 | 管理者以外が{{subst:Blocked}}や{{subst:Infiniteblocked}}を貼り付けたとき |
| 対処操作 | 不許可（出来るなら『自動承認の取り消し』も） |
--さろ（会話） 2022年2月24日 (木) 07:53 (UTC)
コメント LTA:GORDON対策であれば効果がなくはないとは思いますが（だとしても発動条件は自動承認か拡張承認で十分だが）、仮に編集フィルターがsubst展開後のテキストで読み取るのであれば、ブロック歴がありブロック通知がなされた会話ページの除去荒らしへの差し戻しや、過去ログ化もできなくなるので、その点が不安です。--郊外生活（会話） 2022年4月3日 (日) 17:50 (UTC)
条件付反対 他の方が指摘されているように、善意で行われる有用な操作も妨げてしまう可能性があるので反対。フラグを立てるかタグを付与する程度、もしくは警告に対処を留めておき、最終的な対処に人の目を入れるのであれば賛成。--カチューシャ・ベズイミアニ（会話） 2022年5月4日 (水) 06:03 (UTC)
フィルターの名前
提案中
| 目的 | {{即時削除|記事1|定義なし}} など不適切な即時削除テンプレートの貼り付けの防止 |
|---|---|
| 理由 | {{即時削除|記事1|定義なし}} など不適切な即時削除テンプレートの貼り付けの防止 |
| 発動条件 | {{即時削除|記事1|定義なし}}および{{即時削除|記事1|解説に足る分量なし}}が貼り付けられたとき |
| 対処操作 | 不許可 |
--106.129.111.193 2021年10月4日 (月) 02:18 (UTC)
反対 不適切な記事1即時削除タグ付与はこれだけではありませんし、発動条件を根本的に練り直す必要があるため。なお提案者を含むIPレンジに対して、LTA:SLIME案件を理由としたWikipedia:投稿ブロック依頼/神戸市交通局6000形6144編成および関連するIP群が出されています。--郊外生活（会話） 2021年12月1日 (水) 16:18 (UTC)
スパム目的でのYahoo!検索結果の追加荒らし対策
提案中
| 目的 | 標準名前空間のページにおいて、スパム目的でのYahoo!検索結果を追加する荒らし対策 |
|---|---|
| 理由 | LTA:GRIMM対策。LTA:GRIMMの個人ブログへ誘導するような主題と関係ないYahoo!検索結果のリンク追加を防ぐため。詳細は後述。 |
先ほども特別:差分/81181376のようにLTA:GRIMMの個人ブログへ誘導するような主題と関係のないYahoo!検索結果へのリンクが追加されていました。このような編集は以前からも標準名前空間の多くのページで行われているものであり、問題編集と考えます。そもそも、検索エンジンの検索結果へのリンクは、Wikipedia:外部リンク#掲載すべきでない外部リンクの7.の観点から外部リンクとして不適切であり、基本的には検索エンジンの検索結果へのリンクを載せるべきではありません。
MediaWiki‐ノート:Spam-blacklist/2020年#LTA:GRIMM案件 20190513で、MediaWiki:Spam-blacklistに載せるべきかという議論がありましたが、Spam-blacklistは名前空間での限定ができないため、削除依頼サブページでも使用できなくなる点で不都合であり、見送られています。編集フィルターであればその問題は解消できるかと思います。
おそらく「/search.yahoo.co.jp/search?」を含む文字列の追加を行ったときに引っかかる形にすれば差し支えないように考えます。対象ユーザーはLTA:GRIMM対策ですからIP利用者・新規利用者（自動承認されていない利用者）にすればかなり荒らしは防げるかと思いますが、拡張承認利用者だからといって標準名前空間でYahoo!検索結果へのリンクを追加することが妥当な場面は多分ないと思いますので（例外を挙げるなら、Yahoo!検索を直接主題とした記事あたりでしょうか。「3.11、検索は応援になる」などは発動対象外にするとして）管理者以外でも差し支えないようには思います（編集フィルターの運用上都合のよい条件で問題ないのではないかと思います）。もしLTA:GRIMMが半保護突破荒らしを行うようでしたら、LTA:GRIMMが突破できないような数値（これは荒らし対策上編集フィルター編集者以外が知らない方が良いと思います）のほうがよさそうには思います。
ただ、これはLTA:GRIMM以外のIP利用者・新規利用者が誤って追加して検出してしまう場合も考えられるかと思いますので、引っかかったときの画面でWikipedia:外部リンク#掲載すべきでない外部リンクの説明なども含めて別途案内文を作った方が良いのかもしれない、とは思っています。
まずは作成の是非に関してご意見をお願いいたします。--郊外生活（会話） 2021年1月4日 (月) 12:48 (UTC)
- GRIMMフィルターを運用した結果、フィルター避けとしてYahoo!検索へのリンクを使い出したようです。既存のフィルターに条件を追加する形で対応しても良いかもしれません。--Marine-Bluetalk✿contribs❀mail 2021年1月4日 (月) 14:05 (UTC)
返信 返信が遅くなりすみません。この類の編集を行う利用者がLTA:GRIMMだけであれば既存フィルターの条件変更でも良いと思いますが、「LTA:GRIMM以外のIP利用者・新規利用者が誤って追加して検出してしまう場合」が全くないとも思えず、その際にLTA疑いのようなメッセージを与えてしまうのはWP:BITEの観点から好ましくないのではないか、という懸念をもっています。--郊外生活（会話） 2021年7月23日 (金) 08:22 (UTC)
賛成 少し調べたのですが、LTA:GRIMMによるこの手の編集は遅くとも2019年から存在しているようです。3.11、検索は応援になるの除外を条件として作成に賛成します。標準名前空間内でのYahoo検索のリンクを禁止するというのも有効かと思いますが、それはまたの機会に。--Semi-Brace (会話 / 投稿) 2021年4月23日 (金) 01:54 (UTC)
連投対策
提案中
| 目的 | 過度の連続投稿対策 |
|---|---|
| 理由 | 利用者:母語（会話 / 投稿記録 / 記録）のようなタイプの荒らしを防ぐため |
| 発動条件 | 拡張承認された利用者、Bot以外による、1分間に６を超える投稿。 |
| 対処操作 | 不許可 |
詳しくは利用者‐会話:Infinite0694の履歴、Wikipedia‐ノート:井戸端の履歴をご確認ください。今回は今のところあまり大規模なことにはなっていませんが、発生すると対応されるまでの害が甚大なので対応が必要と考えます。action=editに限定されないとしたのは同じことは移動などでも可能だからです。--Q8j（会話） 2020年11月2日 (月) 18:49 (UTC)
- コメント 何らかのツールを使っている人は別かもしれませんが、活動開始から3年以上、編集回数2万回を超えている利用者でも9編集/分が限界（Wikipedia:井戸端/subj/複数の記事に投稿するときの間隔について参照）なので、手作業で投稿する限りは不運にもフィルターに引っかかりそうな新規利用者さんはあまりいなさそうには感じます。ただ、いまの条件だと、巻き戻し権限保持者（巻き戻し者・管理者・グローバル巻き戻し者・グローバル管理者・スチュワード）が巻き戻し権限を適切に使用できなくなるリスクがあると思うのですが、どうなのでしょうか（これらの権限保持者が拡張承認された利用者であるとは限りません）。あと、場合によってはLTA:203やLTA:SASHO対策、
action=create も入るかと思いますのでLTA:YAYURE対策にもなるかと思います。--郊外生活（会話） 2020年11月2日 (月) 19:07 (UTC)- 返信 あ・・・グローバルの存在をすっかり忘れていました。
- mw:Extension:AbuseFilter/Rules_format/ja#組み込みの変数をみて気付いたんですが、編集フィルターってdelete＝削除を検出するんですね。なのでactionをなんでもありにすると今後拡張承認されていない利用者が削除者になった際、一括削除（Nuke）の使用に支障をきたす可能性があるようです（削除操作によるフィルター発動記録）。迂闊でした。
- なので、その対策も兼ねて、actionを限定した方がいいと思います。ところで、action=create、というのはページ作成のことでしょうか？であればaction=edit扱いなので、edit、moveで対応可能です。巻き戻しはおそらくどのactionにも属さないので（私は巻き戻し操作でサイズの大幅な増減などのフィルターに引っかかったことはないです）、この２つに限定すれば巻き戻し対策にもなると思います。--Q8j（会話） 2020年11月2日 (月) 19:34 (UTC)
- コメント 確認してみましたが、巻き戻しはaction=editになります。なので、巻き戻しでの大幅増減は個別試験ではフィルター20などに引っ掛かりますが、理由は知りませんが編集フィルター記録には残らない様です（理由知っている方教えて下さい）。--えのきだたもつ（会話） 2020年11月3日 (火) 04:56 (UTC)
- コメント 巻き戻し (rollback) は "action=edit" にはなるのですが、編集フィルターを通過しないため、編集フィルター記録を含めた全ての対処操作は実行されません (フィルターを通過しないのか、それとも巻き戻しは無条件でフィルターをパスできるのか、正確にはどちらなのかはわかりません)。そういう仕様です。phab:T24713 および phab:T262157 で意見が交わされています。--Yuukin0248[会話/投稿記録] 2020年11月3日 (火) 06:26 (UTC)
- コメント mw:extension:AbuseFilter/Rules_format#Exclusionsに解説がありました。「Although the AbuseFilter examine function will identify "rollback" actions as edits, the AbuseFilter will not evaluate rollback actions for matching.」。巻き戻しのリンクがaction=rollbackなのでてっきり別のアクション扱いされるのかと思ったんですが、そもそも検査されないみたいですね・・・MediaWikiのコードを編集している方にも確認しましたが、巻き戻しは編集フィルターによって処理されないようです。--Q8j（会話） 2020年11月4日 (水) 04:16 (UTC)
- コメント action=createはページ作成のつもりで発言していたのですが新規作成もaction=editでした（保護記録で[edit=autoconfirmed]とか[create=autoconfirmed]とかあったり、特別:ログ/createがあったりするので別なのだろうと誤認していました）--郊外生活（会話） 2020年11月3日 (火) 07:19 (UTC)
- コメント 一点思いついたのですが、その利用者が「noratelimit」権限を持っている場合は除外、というのはどうでしょうか。その場合削除者含む権限持ちはほとんど除外できるので、権限操作をこのフィルターが阻害することはないでしょう（削除だけならaction≠deleteで対応できますが、他の権限操作を阻害する可能性が否めません。今思いついたのが、管理者のmassprotect発動に伴う{{Pp}}（旧:{{半保護}}等）貼り付け。拡張承認されていない人が管理者なったらどうするの・・・？とか。）。もちろん、そうなるとそれら権限持ちは一利用者としての編集などでもこのフィルターを免れることになりますが、このフィルターの目的は単なる連続投稿防止ではなく、連続投稿による（Botのような）荒らし阻止なので、権限持ちはその観点からは省いていいように思います。なお、jawpローカル巻き戻し者はnoratelimitを持っていないので、jawp巻き戻し者であるというだけでは除外されません（拡張承認者であれば除外ですし、巻き戻し権限の行使は前述の通り除外ですが）
- noratelimit権限保有者は以下の通りです。
- この方法であればbotの除外も必要ない（botはnoratelimit持ち）ですし、actionを限定する必要もなくなります。１点問題があるとすれば拡張承認されていないインターフェース管理者が誕生した時ですが、まぁその時は手動で拡張承認つければ済みます（そんな滅多に起こらないであろう事態のために条件増やしてフィルター重くするのも良くないですし）。--Q8j（会話） 2020年11月4日 (水) 23:22 (UTC)
- コメント 改めて（止まったので）
- 発動条件・・・「拡張承認された利用者」でなく（user_groups）、noratelimit権限（user_rights）を持たない利用者が1分間に6を超える（7以上の）投稿をした時
- 対処・・・不許可
- で提案します。--Q8j（会話） 2020年11月10日 (火) 08:15 (UTC)
- 賛成 依頼者票--Q8j（会話） 2020年11月10日 (火) 08:15 (UTC)
- コメントフィルタの必要牲には基本的に同意します。また、ご提案の仕様であれば重大な副作用の恐れもなさそうなので、この仕様なら安心して賛成できます。ただ、先の議論でいろいろとフィルタの仕様について聞いたのでわかったのですが、Q8jさん御提案の仕様ですと、発動条件を満して投稿不許可になっても、１分待てばまた最大６回の連続投稿が可能になってしまいます。対象としている荒らしはおそらくスクリプトなどを使って投稿していると思われるので「６回の連続投稿⇒１分待ち」のルーチンで簡単に対処されてしまいそうです。
- そこで、仕様としては、発動条件を満した場合、投稿不許可ではなく、実質的な２４時間程度の投稿ブロック、とすることを提案します。もちろんフィルタでは特定のアカウントに対するブロックはできません。そこで、最初に発動条件を満した時は、不許可にすると同時にフィルタが発動した、というフラグ（タグ）を付けておく。１分以上経過してから次の投稿があったときは、直前の投稿にフラグが付いていて、かつその投稿から２４時間以内である場合に不許可とする、という方法で実質的に２４時間の投稿ブロックができると思います。--Loasa（会話） 2020年12月31日 (木) 08:12 (UTC)
- （追記）フィルタでは基本的にブロックはできないと思っていたのですが、仕様書を見たらできるようですね。ならば、上で提案したようなややこしい方法ではなく、発動したら２４時間かそれ以上のブロックということでよいでしょう。まともな利用者が引っかかることはまずありえない発動条件なので、通常のブロックと違って、利用者ページの編集も不許可でよいと思います。--Loasa（会話） 2021年1月4日 (月) 05:05 (UTC)
- 返信 ありがとうございます。
- まず仕様の問題で、Wikipedia日本語版ではフィルターによる投稿ブロックはできません（確か）。サイトMediawikiで公開されている拡張機能・AbuseFilterは投稿ブロックを設定次第で行えるようになっていますが、日本語版ウィキペディアでは無効化されていたと思います。
- 例えば、Special:AbuseFilter/1（カテゴリを含まない記事の作成・公開フィルター）の編集画面をご覧ください。編集はできませんが、画面下にスクロールすると「発動したときに取る対処操作」の選択肢（チェックボックス）に「ブロックする」というのがないのがおわかりいただけると思います。
- その前に提示された「実質的な２４時間程度の投稿ブロック」について、mw:Extension:AbuseFilter/Rules_format/jaにフィルターで使える変数が載っていますが、私の知る限り「当該利用者の直前の編集に〇〇というタグがついているか否か」という判定はできません・・・Loasaさんは何か方法をご存知でしょうか？
- 『「６回の連続投稿⇒１分待ち」のルーチンで簡単に対処されてしまいそう』。はい、おっしゃる通りです。そうでなくとも10秒間隔でやり続ければこのフィルターには引っかかりません。
- 連続投稿の害は大きく２つです。
- 最近の更新監視に差し障る
- 曜日、時間帯によって大きく違いますが、例えば今（1/4（月） 23:08JST）に見てみると500件表示で22:33:14JSTが最古、23:08:04JSTが最新です。つまりこの時間帯、34分50秒の間に500回の編集等が行われたことになり、1分につき15回ほど、監視すべき編集が流れています。
- ここで先日のような、1分に30もの編集をされると、流れてくる量が３倍に跳ね上がります。もちろん利用者名などを見てスルーすれば良いのですが、場合によっては他の荒らしを見逃す結果になりかねません。
- しかし、1分に６であれば、一時的に少し増える程度です。もちろんいいとは言いませんが、機械的フィルターで誤作動を少なく防ごうと思えばこれくらいが御の字と私は思います。
- 履歴が汚れる
- 先日はたまたま早く対処されましたが、例えば深夜、3時などにこれをされるとどうなるか。偶然管理者が起きてるか、スチュワードが事態に気付いて対応するまで、30/分ペースで履歴を埋められてしまい、例えば1時間放置されると1800版が流されてしまうことになります（デフォルトの50件表示だと36ページ分）。3時間対処されなければもう履歴分離ラインです。しかし、1分に6回ペースであれば、3時間放置されても1080版。最悪特定版削除で消すことができます。
- 最近の更新監視に差し障る
- 投稿ブロックについて、仕様上おそらく無理だと思う、と言いましたが、本件に関してはできたとしてもやるべきではない、と思います。不許可については（荒らしが）発生したときの害が大きいこと、スクリプトを使わない人はおそらく引っかからず、スクリプトを使うような人はある程度jawpに慣れていることが想定されること、メッセージで1分6回を超えたから不許可になった旨を出せば事情を理解するのは容易であることから（サーバー負荷の観点から、と言ったメッセージでもいいでしょう）提案しましたが、このリミットに引っかかる善良な利用者が皆無とは断言できないからです。
- 長くなりましたが、以上です。--Q8j（会話） 2021年1月4日 (月) 14:46 (UTC)
- コメント (まず技術的な話題から) Q8jさんの仰るとおり、不正利用フィルター拡張機能には「フィルターに引っかかった利用者を投稿ブロックする」対処操作がありますが、ウィキメディアプロジェクト全体で無効化[1]されています。ウィキペディア日本語版の独自設定[2]でも有効化されていないため、現時点で利用することはできません。この設定はメタウィキ[3]やウィキデータ[4]では有効化されており、合意形成を経てシステム管理者に設定の変更を依頼することは可能ですが、この設定の変更すると「編集フィルター編集者が間接的に投稿ブロック権限を行使できる」「誤作動によって非常に重い副作用が発生する」といった問題が起こるとして提案が否決される可能性もあります。ちなみに、直前の編集のタグから連続投稿を判断し実質的な投稿ブロックを行うという実装は、Q8jさんが説明されているような点で実現可能性が低いです。
- (ここからが本題) 過度の連続投稿を抑制するためのフィルターを作成するという趣旨には賛成ですが、6回/分 を超えるスピードでの編集を行った拡張承認されていない利用者を24時間投稿ブロックするという提案には反対します (投稿ブロック対処自体に対する反対ではなく、その条件に対する反対です。後述)。善良な利用者が駅ナンバリングや高速道路ナンバリングなどのテンプレートやカテゴリを追加するような簡単な編集であれば 6回/分 を超えて編集する可能性があります (もちろん継続的には無理、一時的にそういうタイミングがあるという話)。無論、6回/分 を超えていると言っても大きく超えているわけではないですし、善良な利用者であれば警告を見て内容を理解し速度を抑制するでしょう。むしろ、6回/分 を1度でも超えてしまっただけで24時間の投稿ブロックとなるというのは、善良な利用者にとっては厳しすぎる措置です (というか、最大 12回/分 で短時間だけ走る仮運用Botまでも投稿ブロックされます)。問題となっているのは荒らし目的の連続投稿で、これらは「より速い速度・より長い時間」連続投稿を行います。
- (結局の所…) 荒らし目的の過度の連投を正確に判断して投稿ブロックしながら、善良な利用者に対する影響を限りなく低減することは不可能だと思います。その2点を両立させるためには、6回/分 を超えたら不許可で、投稿ブロックは行わない、という当初の提案は理に適っています。6回/分 では荒らし対応が遅れた際の被害が大きいという意見があるので、4回/分 や 3回/分 まで厳しくするのもありだと思います。どうしても投稿ブロックするならば、善良な利用者が普通に編集してて99%出せない速度 (8回/分 だとギリギリ出せるかも？10回/分 は無理だと思う) のみに絞るべきです。あるいは、同一ページに対する 4回/分 や 6回/分 の連続投稿に絞って投稿ブロックを行うのも有効かもしれません。--Yuukin0248[会話/投稿記録] 2021年1月5日 (火) 08:05 (UTC)
- コメント Yuukin0248さん、技術的情報の補足、ありがとうございます。ウィキメディアプロジェクト全体の設定だったんですね・・・
- さて、ブロック/実質的なブロックという案は技術的に不可能なようです。これは見送りとさせてください。
- 今朝（深夜）、LTA:SYUNである利用者:勤怠卿（会話 / 投稿記録 / 記録）が懸念していたような編集を行いました。幸いスチュワードがすぐにロックしてくださったので大事には至りませんでしたが・・・特定のLTAに限らず、こういうのはJavaScriptやbotの知識があれば誰でも可能なものです（Special:Diff/78148270によると、自動承認だけで前述のような速度の編集は可能）。できれば可能な限り早く対策を行いたいです。
- Loasaさん、Yuukin0248さんは前向きな意思を示していただいていますが、Wikipedia:編集フィルター/提案#提案から正式稼動までの流れにある「賛成」とみなして差し支えないでしょうか。もちろん条件で他に検討することがあれば議論すべきですが、Loasaさんに上記のコメントをいただくまで2ヶ月停滞してしまっており、またいつの間に流れる、というような事態は避けたいところです。
- 仮運用などフラグなしbotがこのフィルターに引っ掛かった際はWikipedia:管理者伝言板/拡張承認の申請#拡張承認の申請にあるとおり拡張承認された利用者権限をつけることで対応することになるかと思います（ただ方針上OKとはいえ、フラグなしでそんな早くbotを動かす人もいないと思うのですが、ログ取得期間中に引っ掛かったフラグなしbotの数によっては何か対策が必要かもしれません）。--Q8j（会話） 2021年1月7日 (木) 12:49 (UTC)
- 賛成 ブロックも実質的なブロックも技術的に不可ということなら、別にブロックすることに拘っているわけでもないので、Q8jさんご提案の仕様に同意いたします。なお、運用上は、効果を見ながら、発動条件を1分あたり6回から1分あたり3-4回などと変更してみるのも良いかもしれません。ただし、数値を固定で運用するのならこのままで良いのですが、もし数値を変えるならば絶対に守っていただきたい条件があります。それは、頻度計測の分母の数値、すなわち1分という時間は変えないでいただきたいということです。あるいは、1分では短か過ぎるのでもう少し長い時間で計測したい、ということであれば、計測時間の最大値を定めてその値は公開し、その最大値以下の時間で変動させていただきたい、ということです。その理由については、すでに半保護突破のための編集数稼ぎ防止でさんざん述べた通りです。似たような目的・仕様のフィルタであるにもかかわらず、「半保護突破のための編集数稼ぎ防止」の場合と違って、こちらの提案にはあっさり賛成し、それどころか「24時間ブロックしても良いのでは」などと過激なことさえ述べたのも、こちらのフィルタは数値が最初から公開されている上に、ご提案の1分あたり6回という発動条件であればまともな利用者が引っ掛る可能牲はまずほとんどない、と考えられるためです。--Loasa（会話） 2021年1月10日 (日) 15:44 (UTC)
- コメント Loasaさん、ありがとうございます。二人の賛成票がついたので、合意とみなせると思います。
- 個人的に、数値は固定でいいと思います。理由は上で述べた通り、1分間に6以下であればそこまで緊急な問題にはなりづらいからです。「1分あたり6回から1分あたり3-4回などと変更してみるのも良いかもしれません」というご意見について、もちろんできるならそれがベストですが、巻き添えを少なくしようと思えば６くらいが限度なのだろうなぁと予想しています。
- よろしければフィルター編集者さん、対応（試験フィルター）していただけると助かります。
- ちなみに条件は上で言った通り『「拡張承認された利用者」でなく（user_groups）、noratelimit権限（user_rights）を持たない利用者が』ですが、『「制限されたページを編集」(extendedconfirmed) ,「速度制限を受けない」(noratelimit)権限を持たない』でもいいかもしれません（速度的にどっちがいいんだろう？）。そのように変更した場合、新たにローカルインターフェイス管理者、Global interface editorsが影響を受けなくなりますが、彼らが連投荒らしをすることはないでしょうし。--Q8j（会話） 2021年1月15日 (金) 10:15 (UTC)
- 賛成 高速での投稿を不許可することによって大きな問題になることはほぼないと考えられるため、Q8jさんご提案の仕様でいいと思います。条件式はどっちでも良いと思います。仮運用Botについては、速度コントロールができているかを確認する目的で方針上200回までは高速運転可能となっているため、引っかかってしまうと仮運用できなくなります。--Yuukin0248[会話/投稿記録] 2021年1月23日 (土) 07:58 (UTC)
- 賛成 荒らし対策の観点から賛成します。ここ最近もAWBを使用したテンプレート荒らしなどもあり、一定の効果が見込めると考えます。--郊外生活（会話） 2021年12月1日 (水) 16:31 (UTC)
- コメント ただし、2020年11月2日 (月) 19:07 (UTC)コメントで指摘できておらず申し訳ないのですが、他プロジェクト・他言語版で荒らし対策で一定の活動実績をもちながら、global rollbackerなどの権限をもっていない人がcross-wiki abuseの差し戻しを行おうとして引っかかる可能性などのリスクもあります。なので、不許可時の説明で連投荒らし対策である、荒らし報告場所としてWP:AN/Iを提示することなども含めて日本語・英語で少し丁寧に説明したほうが良いかもしれないようにも思います。このままでは荒らしを差し戻す側が荒らし扱いされると誤認されるリスクもないとはいえないので。--郊外生活（会話） 2021年12月1日 (水) 16:31 (UTC)
YouTubeのチャンネルを直接貼った編集のトラック
提案中
| 目的 | {{SD|G4}} が付けられるような記事の作成防止
|
|---|---|
| 理由 | P丸様。（ノート / 履歴 / ログ / リンク元） チャンネルがーどまん（ノート / 履歴 / ログ / リンク元）など、明らかに宣伝が主目的のページを作成される確率を減らす |
| 発動条件 | 新規作成されたページ、標準名前空間、バイト数が1000未満、任意の行に https://www.youtube.com/channel を含むという条件を全て満たす編集 |
| 対処操作 | 警告 |
最近作成されるYouTube(r) 関連の記事で、特筆性のないページのほうが多くなってきたと思われるため上記の通り提案します。--Semi-Brace (会話 / 投稿) 2020年10月31日 (土) 06:39 (UTC)
- コメント 不許可ではないとはいえ、逆に警告のせいでYouTuberのリンクを除去されるほうが困るときもあるように考えています。記事主題が実在するかどうかの確認で有用に考えますし、一般にYouTubeのリンクはWP:ELの観点から問題ありません。バイト数が1000を超えていたからといって宣伝的な記事はあるでしょうし（サブスタブ作成対策を意図しているなら別ですが）、個人的にはrefタグの有無あたりも判断根拠に入れても良いようにも思えます。--郊外生活（会話） 2021年1月4日 (月) 13:01 (UTC)
- （対処予告）提案から11か月経過し、他利用者から懸念を提示された上、賛成者がいなかったため、これ以上コメントがなければ一旦却下としてクローズしたいと思います。--ネイ（会話） 2021年10月4日 (月) 04:25 (UTC)
俺の嫁コピペ対策
提案中
| 目的 | LTA:SASHO対策 |
|---|---|
| 理由 | 最近この履歴などに出現している俺の嫁からのコピペを行う利用者が散見されるため |
| 発動条件 | プラス1000バイト以上、編集回数が50回未満、同記事からのコピペを行った時 |
| コード | action = "edit" & edit_delta >= 1000 & user_editcount < 50 & page_title != "俺の嫁" & "俺の嫁（おれのよめ）とは、" in added_lines & "『知ってるだけで恥ずかしい 現代オタク用語の基礎知識』" in added_lines |
| 対処操作 | 不許可 |
繰り返される荒らしに対する即時版指定削除＋リバートを減らすのが目的です。5つめ、6つめの条件は暫定です。--Semi-Brace (会話 / 投稿) 2020年9月21日 (月) 05:24 (UTC)
- 賛成 どのくらいの頻度で出てるのか私はよく知らないんですが、そう言う方がいるなら作成に同意（沈静化したらその時は解除すればいいでしょう）。特定のワードを公表しちゃうと回避がされる可能性があるので、例えばいくつかの普通では考えにくいワード・文を設定して、何個以上含まれたら不許可とか言うのもありだと思います。--Q8j（会話） 2020年9月22日 (火) 20:32 (UTC)typo--Q8j（会話） 2020年9月22日 (火) 20:33 (UTC)
- コメント 最近は俺の嫁からのコピペは見られなくはなっているかと思いますが、特定の記事・外部サイトからのコピペ荒らしが見られる場合であればLTA:SASHOに限らず有効性は高いと考えます（もちろん非公開フィルタでかつ検出ワードは変えるものとして）。ただし、この条件では正当な手続きを踏んだ分割や、転記（利用者サブページでの下書きを含む）も妨げかねないので、適切な履歴継承を行った場合（要約欄で記事名へのリンクがある等）を除外する必要はあるかと思います。また、LTA:SASHO対策を意図するなら編集回数50回未満は緩すぎだと思います。--郊外生活（会話） 2021年12月1日 (水) 16:35 (UTC)
基本多言語面外の文字を含むページ名
提案中
| 目的 | ページ名にUnicodeの基本多言語面(BMP)にない文字を含む場合は常に他のページへのリダイレクトとし、ページ内で追跡用テンプレートを使用するよう利用者に強制する |
|---|---|
| 理由 | Wikipedia:井戸端/subj/Unicodeの基本多言語面にない文字をタイトルに含むページの作成解禁に向けてでの事前提案によるものです。フィルターの作成を提案したのは私ですが、以下の発動条件はネイさんの2020年5月9日 (土) 05:19 (UTC)の発言から引用しています。追跡用テンプレートというのはTemplate:Title with non-BMPを指しています。 |
| 発動条件 | 「ページ編集（作成を含む）の場合」かつ「ページ名にBMP範囲外の文字を含む場合」かつ（「リダイレクトでない場合」または「リダイレクトであり、追跡用テンプレートがない場合」または「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」） |
| 対処操作 | 警告・不許可 |
-- 本日晴天（会話） 2020年5月29日 (金) 11:23 (UTC)
- コメント 発動条件のうち、「ページ名にBMP範囲外の文字を含む場合」と「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」のところは正規表現を使わないと実現不可能と思われます。個人的には「リダイレクトで、ページ名が2文字以上、かつ絵文字入りの場合」については作品名や組織名などでわずかながらリダイレクトとしての需要があるのではないかと考えており、この部分の判定が特に複雑かつ高コストとであるから、条件から外した方がいいのではないかという気がします。あと利用者名前空間および利用者‐会話名前空間のページと、リダイレクトページの冒頭に即時削除タグを貼るといった編集については発動から除外する必要がありそうです。--本日晴天（会話） 2020年5月29日 (金) 11:23 (UTC)
- コメント 特別:不正利用フィルター/14やUnicodeのEmojiの一覧を参考にして発動条件のコードを作ってみたので、以下に提示します。長いので折りたたんでいます。間違いがあったらご指摘ください。--本日晴天（会話） 2020年6月7日 (日) 08:49 (UTC) コードを1か所修正。--本日晴天（会話） 2020年6月8日 (月) 11:24 (UTC)
発動条件のコード
/* 編集操作 */
( action === "edit" )
/* 利用者名前空間でも利用者‐会話名前空間でもない */
& ( ( page_namespace !== 2 ) & ( page_namespace !== 3 ) )
/* ページ名に基本多言語面にない文字を含む */
& ( page_title rlike "[\u10000-\u10ffff]" )
/* ページの冒頭に即時削除タグがない */
& !( rmwhitespace( lcase( new_wikitext ) ) rlike "^{{(template:)?(sd2?|即時削除2?(/[]+)?|delete)(}}|\|)" )
& (
/* リダイレクトでない */
( isRedirect := ( rmwhitespace( lcase( new_wikitext ) ) rlike "^\#(redirect|転送|リダイレクト):?\[\[.+?\]\]" );
!isRedirect )
/* リダイレクトであるが追跡用テンプレートがない */
| (
( isRedirect )
& !( rmwhitespace( lcase( new_wikitext ) ) rlike "{{(template:)?title_?with_?non-bmp}}" )
)
/* リダイレクトで、ページ名が2文字以上、かつemoji入り */
| (
( isRedirect )
& ( length(page_title) >= 2 )
& ( page_title rlike "[\u1f004" +
"\u1f0cf" +
"\u1f170" +
"\u1f171" +
"\u1f17e" +
"\u1f17f" +
"\u1f18e" +
"\u1f191-\u1f19a" +
"\u1f1e6-\u1f1ff" +
"\u1f201" +
"\u1f202" +
"\u1f21a" +
"\u1f22f" +
"\u1f232-\u1f23a" +
"\u1f250" +
"\u1f251" +
"\u1f300-\u1f321" +
"\u1f324-\u1f393" +
"\u1f396" +
"\u1f397" +
"\u1f399-\u1f39b" +
"\u1f39e-\u1f3f0" +
"\u1f3f3-\u1f3f5" +
"\u1f3f7-\u1f4fd" +
"\u1f4ff-\u1f53d" +
"\u1f549-\u1f54e" +
"\u1f550-\u1f567" +
"\u1f56f" +
"\u1f570" +
"\u1f573-\u1f57a" +
"\u1f587" +
"\u1f58a-\u1f58d" +
"\u1f590" +
"\u1f595" +
"\u1f596" +
"\u1f5a4" +
"\u1f5a5" +
"\u1f5a8" +
"\u1f5b1" +
"\u1f5b2" +
"\u1f5bc" +
"\u1f5c2-\u1f5c4" +
"\u1f5d1-\u1f5d3" +
"\u1f5dc-\u1f5de" +
"\u1f5e1" +
"\u1f5e3" +
"\u1f5e8" +
"\u1f5ef" +
"\u1f5f3" +
"\u1f5fa-\u1f64f" +
"\u1f680-\u1f6c5" +
"\u1f6cb-\u1f6d2" +
"\u1f6d5" +
"\u1f6e0-\u1f6e5" +
"\u1f6e9" +
"\u1f6eb" +
"\u1f6ec" +
"\u1f6f0" +
"\u1f6f3-\u1f6fa" +
"\u1f7e0-\u1f7eb" +
"\u1f90d-\u1f91e" +
"\u1f920-\u1f927" +
"\u1f930" +
"\u1f933-\u1f93a" +
"\u1f93c-\u1f945" +
"\u1f947-\u1f94b" +
"\u1f950-\u1f971" +
"\u1f973-\u1f976" +
"\u1f97a-\u1f9a2" +
"\u1f9a5-\u1f9aa" +
"\u1f9c0" +
"\u1f9ae-\u1f9ca" +
"\u1f9cd-\u1f9fe" +
"\u1fa70-\u1fa73" +
"\u1fa78-\u1fa7a" +
"\u1fa80-\u1fa82" +
"\u1fa90-\u1fa95]" )
)
)
別案1
上で示した発動条件は複雑なので、別の案として「ページの編集操作である（作成を含む）」かつ「利用者名前空間でも利用者‐会話名前空間でもない」かつ「ページ名にBMP範囲外の文字を含む」かつ「{{Title with non-BMP}}を使用していない」という発動条件を提案します。要はページ名にBMP範囲外の文字を含む場合に追跡用テンプレートの使用のみを強制するということです。コードは以下のようになり、当初の案と比べてかなり簡単になります。
/* 編集操作 */
( action === "edit" )
/* 利用者名前空間でも利用者‐会話名前空間でもない */
& ( ( page_namespace !== 2 ) & ( page_namespace !== 3 ) )
/* ページ名に基本多言語面にない文字を含む */
& ( page_title rlike "[\u10000-\u10ffff]" )
/* 追跡用テンプレートがない */
& ( rmwhitespace( lcase( new_wikitext ) ) rlike "{{(template:)?title_?with_?non-bmp}}" )
この案ですとリダイレクトでない状態で作成したり、リダイレクトを解除するような編集は許可するということになります。そのような編集を行うと{{Title with non-BMP}}が（Category:Unicode基本多言語面外の文字を含むリダイレクトではなく）Category:Unicode基本多言語面外の文字を含むページ名を付与する仕組みになっているため、ウォッチリストを活用すれば追跡は容易です。--本日晴天（会話） 2020年6月7日 (日) 08:49 (UTC) 下線部を追記。--本日晴天（会話） 2020年6月7日 (日) 09:14 (UTC) コードを1か所修正。--本日晴天（会話） 2020年6月8日 (月) 11:24 (UTC)
- 賛成 別案は最初の案と比べて穴がある代わりに、コードがかなりシンプルになっています。追跡カテゴリがあるので、コードのシンプルさを重視して別案に賛成します。最初の案にも反対はしません。--ネイ（会話） 2021年4月4日 (日) 12:26 (UTC)
移動荒らし防止フィルター
LTA:SZMYがおとなしくなったと思ったら次はLTA:3SBか、まったく・・・
下記２つ提案します。
フィルターA
提案中
| 目的 | 省略（下記記載） |
|---|---|
| 理由 | 省略（下記記載） |
| 発動条件 | 投稿回数100回未満の利用者が、1時間以内に5回以上ページ移動を行った時（20200806修正） |
| コード | action == 'move' & user_editcount < 100 （と60分以内に5回以上） |
| 対処操作 | 不許可 |
フィルターB
提案中
| 目的 | 省略（下記記載） |
|---|---|
| 理由 | 省略（下記記載） |
| 発動条件 | 投稿回数100回未満の利用者が、
|
| コード | user_editcount < 100 & ( ( action=='edit' & page_age < 600 & old_size < 309 & contains_any ( old_wikitext , '#転送' ) ) | ( action == 'move' & moved_from_age < 300 ) ) |
| 対処操作 | 不許可 |
この提案は複数回変更されています。履歴を表示するには「表示」を押してください
- この提案フィルターの前身
- 2020/02/01 Wikipedia名前空間での移動を防止するフィルター提案→取り下げ（→フィルターA）
- 2020/03/06 他者会話ページの移動を防止するフィルター提案→取り下げ（→フィルターA）
- 2020/03/16 リダイレクトページの編集を防ぐフィルター提案→取り下げ（→フィルターB）
- このフィルターの履歴
- 1.2020/05/28 初提案。
- 投稿回数100回未満の利用者が、1時間以内に3回以上ページ移動を行った時（フィルターA）
- 投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集・移動しようとした時（フィルターB）
- 2.2020/08/06 条件変更、コード草案作成
- フィルターAの発動条件の回数を1時間に3回から5回に変更
- フィルターBの「移動」についてリダイレクトページのみ、の判定ができないことが分かったため、ページ作成後10分から5分に短縮した上で、作成後5分以内のページ移動はリダイレクトかそうでないかを問わず発動するように変更
- 3.2020/08/08 コード微修正
- 反応速度の向上のためにcontains_any ( old_wikitext , '#転送' )の発動前にページのバイト数を確認、308バイト以下の時はcontains_any ( old_wikitext , '#転送' )の検査を避ける（old_wikitextは重い場合があるそうなので）
この２つで移動荒らしを対処可能にすることを目的とします。
１つ目のフィルターにより、1時間以内に行える移動荒らしは3回が限度となり、差し戻しもしやすくなります。２つ目のフィルターは,Wikipedia:編集フィルター/提案/ログ/2020年#移動荒らし対策同様、リダイレクトページをいじられることで差し戻しが一般利用者にできなくなることを防ぐことを目的としています。
いずれも編集回数100回以上の利用者は対象外としています。これは複数のソックパペットが同時に移動荒らしを行った場合、アカウントの数が荒らし＞差し戻し者であった場合、差し戻しをこのフィルターが邪魔することになりかねないとの判断です（50回とするのも考えたんですが、極稀に「荒らしてるうちに編集回数が50回を超える」荒らしがいるので）
２つ目のフィルターについて、TmvYosizuyaさんより巻き添えの可能性のご指摘がありましたが、10分以内、とある通り10分待てば編集できるのであまり問題にはならないと思います。もともとリダイレクトページなんてそうそう編集されるものじゃないので。--Q8j（会話） 2020年5月28日 (木) 16:58 (UTC)事実誤認を修正。大変失礼しました。--Q8j（会話） 2020年5月28日 (木) 18:05 (UTC)リンク修正。過去ログに送られたため--Q8j（会話） 2020年8月6日 (木) 14:12 (UTC)
- 賛成 普通の利用者なら10分ぐらい待てますが、荒らしであれば早急に荒らさないとブロックされるので、そういった意味で有用な編集フィルターであると思います。1つ目の編集フィルターで、投稿回数100回未満の利用者が行った移動にタグ付けをするとかそういうのがあってもいいと思いますが、まあそれについてはどちらでもいいと思いますし、初心者の方が「なんだこれ？？」となるかもしれないのでタグ付けはなくてもあってもどちらでもいいです。--Tmv（会話|投稿記録） 2020年6月19日 (金) 00:46 (UTC)
- コメント
「もし、提案後1週間が経過し、2人以上の賛成（提案者の提案者票を含めても良い）があり、かつ反対する人がいない場合は、合意がなされたとみなされます。」の要件を満たし、本件フィルターは合意がなされています。本日、LTA:203と思われる移動荒らしが２体出現したこともあり、可能ならフィルター作成をおねがいしたいです。--Q8j（会話） 2020年7月18日 (土) 10:18 (UTC)typo--Q8j（会話） 2020年7月18日 (土) 10:19 (UTC)取り消し。一旦--Q8j（会話） 2020年8月6日 (木) 12:36 (UTC)
- コメント コードを書いてみて気付いたんですが、何個か訂正しました。
- 一つ目。1個目のフィルターの発動条件回数を変更しました。5回以上で発動としています。理由として、多分、ですが「ノートページも移動」にチェックした場合、移動が2回カウントされてしまうと思います。そうなると1時間以内の移動を3回まで、としてしまうとノートも同時移動とすると事実上1回までしか移動できなくなってしまいます。なので２倍にしたいところですが、逆に6回まで許可、とすると荒らしがノートを移動しなかった場合や、ノートが存在しないページへの移動荒らしだった場合6回まで移動荒らしができてしまう。これはさすがにあまりよろしく無いだろう、と思い、それの中間という感じで4回まで許可（5回目以降は不許可）としました。つまりノートも同時移動した場合であっても2回までは移動可能です（編集回数を満たす人は当然影響されません）。
- 2つ目。2個目のフィルター、つまりリダイレクトを編集されて一般利用者に差し戻しができなくなる事態を防止するフィルターですが、「移動する時のウィキテキスト」が取得できなさそうです（てっきりできると思ってたんですが）。ので、苦肉の策ですが「作成後5分以内は（リダイレクトかそうでないかにかかわらず）移動できない」としました（user_editcount＝編集回数は使えるので100回以上の利用者は移動は可能です）。新規利用者が作ったばかりのページを移動したくなった場合（WP:NC違反に気づいた時など）は案内文を表示して5分待ってから移動してください、というようにしたいと思います。なお、編集の際はold_wikitextが使えますので、編集の際は当初提案通り「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」となります。
- 以上です。賛成票を投じていただいたTmvさん、この変更後でも賛成していただけますか。他の皆さんはいかがでしょう。大幅に条件を変えたので、意見募集期間を振り出しに戻し、追加1週間（最低）とします。また、old_wikitextなど負荷が高いものを使っていますので、負荷軽減のためにいい案がある方は教えていただけると助かります。--Q8j（会話） 2020年8月6日 (木) 12:36 (UTC)
- コメント 通知が来たので回答いたします. 回数の変更についてですが, 4回まで移動というのは妥当であると思います. 荒らしがノートのないページを移動で荒らすときと, 一般利用者がノートのあるページを荒らすときの間を取るのって結構難しいですね. 一般利用者さんが移動するときは合意形成を取ってから移動しますからノートがある場合も多いと思いますし, 荒らしの場合はノートがないページの移動も結構あると思います. そういうのを鑑みると4回というのは妥当な数字だと思います.
- 2つ目についてですが, こちらについても賛成です. ページ作成から5分以内のページを移動しようとする, という操作についてですが, 一応明らかなページ名のミスなどがわかってすぐ移動する例というのはあります. ただ, 5分以内なので待てばいいですし, 投稿回数100回未満の利用者がミスを見つけて移動するという操作をすることも少ないと思います.
- 以上です. 私は変更後の案に賛成いたします. --Tmv（会話|投稿記録） 2020年8月6日 (木) 23:01 (UTC)
報告 何度もすみません、微修正しました。今回は発動条件は（理論上）変わらず、パフォーマンス向上のみです（・・・多分）。ので、追加期間はとりません（意見があれば別です）
- 変更箇所。「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」の部分のコードに太字部分を加えました。
user_editcount < 100 & action=='edit' & page_age < 600 & old_size < 309 & contains_any ( old_wikitext , '#転送') - 私の理解が正しければ、フィルターは左から右に検査して、途中で引っかかればそれ以上の検査はしないはずです。つまり、この変更により編集前のサイズが309バイト未満であれば
contains_any ( old_wikitext , '#転送')＝ページに「#転送」が含まれるか、の検査が行われますが、309以上であればこの検査は行われません。 - 理由ですが、old_wikitextには「この変数は膨大な場合があります。」との解説があります。ので、可能な限りその検査をしない条件を考えました。このフィルターが狙っている「自動生成されたリダイレクトの改変防止」という目的であれば、この検出対象は
#転送 [[（名前空間:）ページ名]]の形のはずです。そのうち、#転送 [[名前空間:]]の部分は最大で「プロジェクト‐ノート:」名前空間の#転送 [[プロジェクト‐ノート:]]、43バイト。名前空間を除いた部分の最大は255バイト。なので、移動により生成されるリダイレクトページの最大サイズは298バイト。それに余裕を持って+10した308より大きいバイト数は理論上移動により生成されたリダイレクトページじゃ無いので、弾く必要はなく、old_wikitextの検査をする必要がないと判断しました。--Q8j（会話） 2020年8月8日 (土) 11:57 (UTC)
- 変更箇所。「投稿回数100回未満の利用者が、リダイレクトページであり、かつ、ページ作成から10分以内のページを編集しようとした時」の部分のコードに太字部分を加えました。
取り下げ- コメント すみません。取り下げを取り消します。最近もたまに見かけるようになったので。もちろんフィルター編集者さんが却下されるなら仕方ないですが、依頼者の私としては（試験）フィルターの作成を引き続き希望します。--Q8j（会話） 2021年4月18日 (日) 10:18 (UTC)
- コメント LTA:ASPEやLTA:203対策、あるいは荒らしでなくても事前提案・合意なき移動を行った利用者への対応のことも考えると編集フィルターが役に立つ場面はあるかと思います。ただ、これはまっとうな新規利用者が移動して移動の跡地を記事起こしする、転送先変更する、曖昧さ回避化する場合でも10分以内であれば引っかかるという認識で問題ないですか？あと、自身の利用者ページ（サブページ含む）は除外してもよいかもしれません。sandboxで作成した下書きを記事に移動した跡地ページの処理などもあるので。--郊外生活（会話） 2021年12月1日 (水) 16:43 (UTC)
半保護突破のための編集数稼ぎ防止
提案中
| 目的 | 半保護突破のための編集数稼ぎ防止 |
|---|---|
| 理由 | 同上 |
| 発動条件 | 編集回数500回を満たさないユーザーが ・自らの利用者ページ、利用者ノート、利用者サンドボックスを少ないバイト増減（100バイト未満、随時見直し）で、複数回編集を繰り返す ・ある特定ページを複数回、少ないバイト増減（100バイト未満、随時見直し）で、複数回編集を繰り返す |
| 対処操作 | 不許可 |
LTA:ASPEやLTA:203、LTA:Iccicなどで、半保護突破を目的とした編集数稼ぎが多く発生しています。実現可能なものから早期に実装し、必要に応じて随時拡張をお願いしたいと思います。--Taisyo（会話） 2020年2月2日 (日) 03:46 (UTC)
- コメント Wikipedia:井戸端/subj/Wikipedia:サンドボックスの長期間半保護についてを見てやってきました。基本的には同意ですが、「複数回編集」の定義を明瞭にしていただきたいです。少なくとも、1.どれ位の時間間隔で、2.何回編集した場合に、「複数回編集」と見なされるのか、という条件ははっきりさせておいて欲しいです。もちろんバイト数の条件と同様に随時見直しはされるべきです。--Loasa（会話） 2020年4月1日 (水) 02:58 (UTC)
- 明言したくない理由をお話ししたいと思います。編集フィルターは荒らしへの抑止力と誤爆が少ないを両立させないといけません。間隔や回数ですが、技術的に出来るかどうかの確認の要素がありまして、実際に出来ること出来ないこと。また、出来たとして、どのようなことが出来るのか確認したい部分があります。出来る事の仕様書を頂いた上で、細かい仕様を出すことになると思います。その中で、非公開事項も出てくると思いますし、随時変更もあるとしています。--Taisyo（会話） 2020年4月1日 (水) 10:20 (UTC)
- 仕様について。仕様書がわかりにくいので、ほかの方の再確認があれば心強いです。
- 発動条件で使用できる情報（仕様書）：特定の編集に対し、「編集したページ名と名前空間」「バイト数の増減」を検出できます。「当該ページに投稿した、直前の10人」「ページ作成者」も検出できますが、パフォーマンスが悪いのであまり推奨できません。利用者の情報は「アカウント作成日時から経過した秒数」「編集回数」を取得できますが、「これまで特定ページを編集した回数」は取得できません。
- 対処操作（仕様書、ただし一部英語のまま）：「X秒内にY回以上フィルターにひっかかる操作（編集）を行った場合のみ」「自動承認ステータスを取り消す」「操作を不許可」とすることができます。また、この「X秒内にY回」についてですが、「同じIPアドレス」「同じIPレンジ（/16レンジ）」「同じ利用者名」「アカウント作成日が同じ利用者」「対象ページが同じ」といったグループごとに限定できます。
editcountグループ＝「編集回数が同じ利用者」も指定できますが、正直使い道がわかりません。また、登録利用者の場合、IP利用者と「同じIPアドレス」のグループにもカウントされるかについてはわかりませんでした。- わかりにくいと思いますので、例を挙げます。対処操作に「自動承認ステータスを取り消す」「不許可」を、頻度制限を「60秒内に3回」「アカウント作成日が同じ利用者」「対象ページが同じ」とします。その場合、2020年3月1日にアカウントを作成した全ての利用者（以下グループZとします）は60秒間に合計3回、ページAを編集することができます。その60秒間にグループZの利用者がさらにページAへの編集を保存しようとした場合、保存できない上に自動承認ステータスが取り消されます。一方、2020年3月2日にアカウントを作成した全ての利用者はグループZとは別にページAを60秒間に合計3回編集できます。
- すなわち、私の理解が正しければ、Taisyoさんが作成しようとしている編集フィルターは技術上可能であると思います。--ネイ（会話） 2020年4月1日 (水) 13:01 (UTC)
- 忙しくなったのと、仕様理解に苦労していたので返事が遅れました。とは言いつつも理解し切れていません。処理負荷を考慮しなければ、かなり細かく見ることが出来るみたいですが、負荷の大きい仕様は良くないと思います。仕様を端折るなどして、比較的低負荷なフィルターの構築をお願いしたいと思います。--Taisyo（会話） 2020年4月12日 (日) 13:19 (UTC)
- これ以上編集できなくなるという回数が3回目以降の連続編集のたびに表示され、善意によるプレビュー不使用編集に対応することを条件に賛成します。わかりやすく言えば、「同一利用者が、1時間以内に5回同一ページを編集した時、6回目の同一ページ編集を不許可とする」という編集フィルターを作る場合、3回目の編集の時は、「ウィキペディアへの過剰負荷防止と荒らし防止の観点から、可能な限りプレビュー機能を利用するようにしてください。◯◯分以内にあと2回このページを編集すると、このページへの編集ができなくなります。」と表示され、4回目の編集の時は前掲メッセージにおいて「あと2回」を「あと1回」に置き換えたものが表示され、というように悪意でない編集に対してプレビュー機能の利用を促すことで、善意の利用者に対する啓発や対策をすることが必要だと思います。 片割れ靴下（会話） 2020年4月27日 (月) 02:04 (UTC)
- フィルターの目的の性質上、非公開とせざるを得ない仕様が多いことは理解しています。それでも極力仕様のオープン化および詳細化を求める理由は、このフィルターは副作用の害がかなり大きいと考えられるためです。一番ありえる問題は、本来阻止したい「半保護突破のための編集数稼ぎ」をするLTAなどでない、単なる「不慣れで少しずつ編集をしている初心者」や「利用者ページ（もしくはサンドボックス）で練習をしている初心者」などが引っ掛ってしまうことです。
- そのような場合に、被害の程度がどれくらいのものになるのか、はフィルターの仕様（特に対処部分）に依りますが、たとえば、一度フィルタが発動したら二度とそのページに投稿できない、とか、「自動承認された利用者ステータス」がリセットされて二度と「自動承認された利用者」になれない、といった仕様だと、善意の初心者にとって非常に大きな（場合によっては致命的な）被害になります。
- これはほんの一例です。こういったことをいろいろと想定して考えれば考えるほど、少くとも「発動条件」「対処」「一回対処した後の利用者に対する制約」などの仕様をかっちり詰めていただかないと、悪意のない初心者が巻き込まれる（しかも本人には対処できない状態になる）可能性が高い、このようなフィルターはとうてい安心して承認できません。また、悪意のない初心者がフィルターに引っ掛ってしまい、編集ブロックとかステータスのリセットなどの被害に巻き込まれた場合のフォロー手段と手順についてもきちんと決めておく必要があります。
- 以上のような理由から、対処としては単に「フィルターが発動した段階でその投稿を不許可にする」だけなのか、その段階で「自動承認ステータスを取り消す」のか。その場合再び編集履歴を積み重ねても自動承認ステータスはえられないのか、さらに、一度フィルターの発動条件に引っ掛って編集不許可となったら、そのユーザーは二度とそのページに投稿できないのか、等々、いろいろな発動条件と対処を前もってきちんと議論し、仕様化してから実装していただきたいと思います。仕様を端折るなんてとんでもないことです。
- 少くとも、そういった議論がなされ仕様がしっかりと整られない限り、このフィルターの作製と使用には反対と言わざるを得ません。とりあえず作って運用してみて何か問題があったらその都度修正していけばいいじゃん、というやり方は、害が少ないフィルターならそれでも良いのですが、このような副作用の害が大きいフィルターについては取るべきではありません。--Loasa（会話） 2020年4月29日 (水) 02:29 (UTC)
- （追記）上の片割れ靴下さんのご提案は、私にはまったく思い付きませんでしたが、非常によい方法だと思います。これは安全装置の一つとして、ぜひ仕様に取り入れていただきたいですね。その他にもこの種のフィルターでは、安全装置に相当する仕様を過剰なくらいに取り入れて設計していだきたいと思います。--Loasa（会話） 2020年4月29日 (水) 02:32 (UTC)
- 別に過剰な安全装置の否定をしているわけではないです。もし、片割れ靴下さんのご提案で実際にフィルターが作れるのか。また、そうしたときに過剰な負荷が掛からないか、私も確認したいと思います。確かに、注文を全部取り入れられて、負荷が大した事なければ、理想に思います。--Taisyo（会話） 2020年4月29日 (水) 03:01 (UTC)
- 仕様についてお答えいたします。こちらもほかの方の再確認があれば心強いです。
- 「自動承認ステータスを取り消す」の対処操作：これは取り消しから5日間自動承認されない仕様となっており、以降は再び自動承認ステータスが与えられます。
- 一度引っかかったら二度とそのページ投稿できないのか：「X秒内にY回以上」なので、一度引っかかったら「X秒内にY回以上」を満たさなくなるまで投稿できません。プレビューはできます。
- これ以上編集できなくなる前に警告する操作：警告に使用するシステムメッセージは1フィルターにつき1つしか設定できず、メッセージ側で編集回数は取得できません。また、「X秒内に3回」「X秒内に4回以上」という場合分けもできません（「X回以上」しか設定できません）。したがって、片割れ靴下さんのご提案は技術上実装できないと思います。
- 私見ですが、無関係な被害とLTA対策の均衡は「X秒内にY回以上」の「X秒」の設定によると思います。これを短くすればするほど、無関係な被害が減るものの、LTA対策としての効果も低下します。--ネイ（会話） 2020年4月29日 (水) 04:12 (UTC)
- 返信 (ネイさん宛) ネイさんありがとうございます。詳細についてまだいろいろと不明な点があるので確認および質問をしたいと思います
- A「自動承認ステータスを取り消す」：
- A-1. これは、すでに自動承認されていても取り消されて新規利用者とされる、ということですね。「取り消しから5日間承認されない仕様」ということは、その５日間はどんなに多くの編集をしても「自動承認された利用者」にならない、ということでしょうか。
- 返信 その認識で合っています。
- A-2. また、5日間経過したら即座に「自動承認された利用者」に戻れるのでしょうか。それとも取消しの瞬間にリセットされ、5日間経過した後さらにまた４日経過し１０回以上の編集がないと「自動承認された利用者」に戻れないのでしょうか。
- 返信 試していないので、確かな答えは現時点では提供できませんが、おそらく「5日後に即座に自動承認される」と思います。（1回編集する必要のある拡張承認とは仕様が違います）
- A-3. また、「5日間」という期間は仕様上固定されたものでしょうか。設定でこの期間を変更することはできないのでしょうか。
- 返信 現時点では正確には「432,000秒」（＝120時間＝5日）に固定されており、変更はできません。
- A-4. また、「自動承認された利用者」になる以前の段階で取消しになった場合はどうなるのでしょうか。やはり５日間は何をしても「自動承認された利用者」にならないのでしょうか。
- 返信 その認識で合っています。
- A-1. これは、すでに自動承認されていても取り消されて新規利用者とされる、ということですね。「取り消しから5日間承認されない仕様」ということは、その５日間はどんなに多くの編集をしても「自動承認された利用者」にならない、ということでしょうか。
- A「自動承認ステータスを取り消す」：
- B.「X秒内にY回以上フィルターにひっかかる操作を行った場合のみ発動」：
- B-1. これは同じページの編集に対してのみ発動するのですね。同一の利用者が投稿先を次々と変えて編集した場合は、「X秒内にY回以上」の編集をしても発動しないのですね。（というよりそういう条件は検出はできないかもしませんが）
- 返信 「X秒内にY回以上」は正確には「フィルターの発動条件にひっかかる編集をX秒内にY回以上」なので、フィルターの発動条件によります。たとえば、Wikipedia:サンドボックスでの編集のみ検出するという条件の場合、投稿先を変えることでフィルターにひっかからなくなり、回避できます。条件のほうで調整することになります。
- B-2. 必然的に、あるページの編集に対してフィルターが発動してしばらく投稿できない状態になったとしても、別のページでは普通に投稿できるのですね。
- 返信 フィルターの発動条件にひっかからない編集であればできます。たとえば、バイト数変動が+100未満の場合のみ検出する場合、バイト数変動を+100以上にすることで投稿できるようになります。
- B-1. これは同じページの編集に対してのみ発動するのですね。同一の利用者が投稿先を次々と変えて編集した場合は、「X秒内にY回以上」の編集をしても発動しないのですね。（というよりそういう条件は検出はできないかもしませんが）
- B.「X秒内にY回以上フィルターにひっかかる操作を行った場合のみ発動」：
- C.フィルター発動後に投稿再開できる条件：「「X秒内にY回以上」を満たさなくなるまで投稿できません」どうもよくわからないし、これが肝心なところですので具体的な数値例で詳しく伺いたいと思います。仮に「60秒内に10回以上」の投稿で発動する設定とします。
- C-1. この場合、フィルターが発動してから何秒経過したら次の投稿が出来るようになるのでしょうか。早ければ数秒以内、最長でも60秒経過すれば次の投稿ができるのでしょうか。
- 返信 最長でも60秒経過すればできます。
- C-2. また、この条件にさらにバイト数の制約を入れ「60秒内に100バイト未満の編集を10回以上」とした場合はどうでしょうか。この場合は、フィルター発動直後でも100バイト以上であれば投稿できるのでしょうか。
- 返信 その認識で合っています。（B-1、B-2への回答も参照）半保護されたページの場合は自動承認が取り消されているため投稿できません。
- C-1. この場合、フィルターが発動してから何秒経過したら次の投稿が出来るようになるのでしょうか。早ければ数秒以内、最長でも60秒経過すれば次の投稿ができるのでしょうか。
- C.フィルター発動後に投稿再開できる条件：「「X秒内にY回以上」を満たさなくなるまで投稿できません」どうもよくわからないし、これが肝心なところですので具体的な数値例で詳しく伺いたいと思います。仮に「60秒内に10回以上」の投稿で発動する設定とします。
- いろいろと御手数おかけしますが、よろしくお願いします。--Loasa（会話） 2020年4月29日 (水) 07:02 (UTC)
- 追加質問です。
- A-5. 取り消されてから５日の間に再びフィルターの発動条件に引っ掛った場合、自動承認されない期間はその分延長されるのでしょうか。たとえば、最初に取り消されてから４日目に再びフィルターに発動された場合、最初に取り消されてから9日後まで承認されないということでしょうか。
- 返信 対処操作が発動するごとに自動承認できるまでの期間が5日にリセットされるので、最後の発動から数えて5日間自動承認されないことになります。
- A-5. 取り消されてから５日の間に再びフィルターの発動条件に引っ掛った場合、自動承認されない期間はその分延長されるのでしょうか。たとえば、最初に取り消されてから４日目に再びフィルターに発動された場合、最初に取り消されてから9日後まで承認されないということでしょうか。
- --Loasa（会話） 2020年4月29日 (水) 07:20 (UTC)
- インラインにて回答いたします。かなり複雑な仕様なので、繰り返しになりますがほかの方の再確認があれば心強いです。--ネイ（会話） 2020年4月29日 (水) 07:56 (UTC)
- そうなるでしょうね。技術書を読み込んでいるわけではないので経験則で。基本的に一般利用者は、新登録者（半保護記事の編集が出来ない）→半保護記事が編集できる利用者（従来の一般利用者）→拡張半保護記事が編集できる利用者を基本的には一方通行で上ることになります。フィルター用件によっては、引っかかる限り新登録者に留め置くことは出来ますし、半保護記事が編集できる利用者を新登録者に格下げすることも出来そうです。ただ、その閾値は固定です。これが半保護や拡張半保護の仕組みですので。--Taisyo（会話） 2020年4月29日 (水) 08:15 (UTC)
- 返信 (ネイさん宛) ありがとうございます。まだよくわからない部分があるので、しつこいようですが再度質問させていただきます。
- B.「フィルターの発動条件によります。」「条件のほうで調整することになります。」というのがよくわかりません。
- B-3.結局のところ、「同一の（つまり同じ利用者名の）利用者が、投稿先に関係なく（次々と投稿先を変えたとしても）トータルでX秒内にY回以上の編集をした場合」に発動する、という設定も可能ということでしょうか。(とりあえずバイト数による制限はしない、という仮定でお願いします）
- そこまで条件を緩めるのは無理でも、せめて対象の投稿先を単一ページではなく名前空間レベルまで拡張して指定することはできますか。たとえば標準名前空間を指定したとすれば、「標準名前空間であればどのページでも（途中で投稿先を変えても）X秒内にY回以上の編集をした場合に発動（この場合、発動前に投稿先をWikipedia名前空間に変えれば、その投稿はX秒内にY回以上の編集にカウントされない）」という設定はできるのでしょうか。
- B.「フィルターの発動条件によります。」「条件のほうで調整することになります。」というのがよくわかりません。
- --Loasa（会話） 2020年4月29日 (水) 09:07 (UTC)
- 返信 発動条件では「投稿先に関係なく」でも、「特定の1ページまたは数ページ」「特定の1名前空間またはいくつかの名前空間」の組み合わせでも設定できます（正規表現も使用できます）。すなわち、LoasaさんがB-3で挙げた条件はいずれも可能です。--ネイ（会話） 2020年4月29日 (水) 09:14 (UTC)
- ありがとうございました。ネイさんのおかげで、いろいろと出来ること出来無いこと危険なことなどがわかってきて具体的なイメージが見えてきたので、具体的な仕様案を出してみます。ネイさんの解説に対する私の理解が間違っていなければ、以下のようなフィルターは実装可能のはずです。
- F1.目的と理由については当初の提案通り
- F2.対象となる利用者：
- F2-1.編集回数500回を満たさないアカウントユーザー。
- F2-2. ただし、編集回数500回を超えるアカウントユーザー、およびIPユーザーは対象外
- F3. 対象となるページ：
-
- すべてのページ
- F4. 発動条件：
-
- F4-1. 対象となる利用者が、対象となるページに対して、「投稿先に関係なくT秒間にBバイト未満の投稿をN回以上繰返した場合」に発動。（つまり、投稿先が変動しても頻度の条件を満せば発動）。T、B、N、の具体的な数値は、フィルターの性質上非公開にするのはやむをえないでしょう。
- F4-2. ただし、TとBには上限値、およびNには下限値を定め、その上限値と下限値は公開し、調整はそれらの値の範囲内で行うものとする。
- F5.発動時の対処：
-
- F5-1.「T秒間にBバイト未満の投稿をN回以上」の条件を満たさなくなるまで、対象となるすべてのページに対する投稿を禁止する。（実質的には最大T秒間の投稿ブロックということになります）
- F5-2.警告メッセージが表示される。メッセージの内容は、たとえば、「フィルターが発動したため、あなたはT秒間Wikipediaへの投稿ができません。ウィキペディアへの過剰負荷防止と荒らし防止の観点から、可能な限りプレビュー機能を利用するようにしてください。」このメッセージにおける「T秒間」には、実際の設定値にかかわらず、F4-2.で公開されている最大値を指定する。
- F5-3.ただし、自動承認ステータスの取消しはしない
- 解説：
-
- 「自動承認ステータスの取消し」はたしかに編集回数稼ぎのLTAには非常に有効ですが、効き目の強い薬ほど副作用も大きいことと同様に、この機能もまた有害な副作用が大き過ぎます。ネイさんの御説明によりその危険性がよくわかりました。その有害な副作用に対する有効な安全対策が取れない以上（片割れ靴下さんのご提案は安全対策としてかなり有用な方法だと思いますが、実装できない以上どうしようもありません）、この対処は導入すべきではありません。また、対処が実質的に「T秒間の投稿ブロック」となる以上、どれくらい待てば良いのかわからないのは特に初心者にとって不安かつ迷惑であり、第三者が「ちょっと待っててね」とアドバイスしたくても具体的な解除時間がわからないとそれも言い難いので、上限値の設定と公開は必須としていただきたいと思います。
- 私は、当フィルターに関しては、極力、無関係な被害者が出ないように、また被害が最小限に留まるように、という観点を重視して考えています。もちろんそれは当フィルターの本来の目的ではないので、本末転倒と言われても仕方無い。しかし、何度も繰返し述べているように、このように副作用の害が大きいフィルターでは当初の目的に対する効果が多少落ちる結果になってでも副作用の害を予防することが最重視されるべきと考えるからです。
- --Loasa（会話） 2020年4月29日 (水) 10:48 (UTC)
- 上限値及び下限値の公開について。気持ちはわかるのですが、それを狙ってLTAが編集稼ぎをするのではと思います。つまりは「理想を高く持ったために現実が低くなりかねない」状態に思います。そもそも、明言をしないまでも誤爆率を減らすことは当然のことです。大きく分けて、狙っている対象に確実にHITした（これが理想です）・本来は狙っていない対象にHITしたが実際のところは荒らし編集だった（たちまち問題はないが、誤爆原因の一因になる可能性があるのである程度は検討は必要）・完全な誤爆（これは要対応）とに分かれるように思います。極端に高い閾値にしたら誤爆率も高くなります。上限値公表はこのようなリスクを抱えています。先の話で、丸投げ話にしたのは、技術的にも十分理解していると判断しているので、仕様などの作成に対し、信用しても良いと思ったからです。とりあえずは、Loasaさんの仕様をベースにするにしても、上限値・下限値の公表は慎重にしたほうがいいかもしれません（CUの保持期間の非公表もそれが理由です）。--Taisyo（会話） 2020年5月1日 (金) 09:09 (UTC)
- 当然ですが、ある程度の取り漏らしも織り込み済みです。正常な編集も誤爆するリスクがあるからで、何割か減れば程度で最初から組んでいます。--Taisyo（会話） 2020年5月1日 (金) 09:11 (UTC)
視点を変えて、少しでも半保護突破用アカウントを作りづらくするための編集フィルタ―として考えるのはどうでしょうか？条件を厳しくする代わりに、頻繁に警告文を表示させて、半保護逃れ用編集の速度を遅らせるのです。これなら不許可という強硬な対処ではないので、回数や時間について公表する必要は薄くなると思います。ところで、半保護を突破しようという人たちは、自動承認された利用者がどうすれば手に入るのかを熟知して「犯行」に及んでいるものと思います。であるなら、回数・時間といった値を非公開にしても事前調査などの形で、値が検証され、露見してしまうかもしれません。つまるところ、非公開とする意味合いは大きくないのではないと思うのですが、その点はいかがでしょうか？ 片割れ靴下（会話） 2020年5月1日 (金) 12:33 (UTC)
- 元々、0にするべくフィルターを作っているわけではないです。幾らかの取り漏らしを前提には作っています。とはいえ、前段階の警告フィルターの件。2つフィルターを作れば理屈の上では成立します。同じ内容のフィルターで閾値と対応を分けて、仮に「10件の編集で警告を入れる」と「20件の編集で編集を認めない」の2つのフィルターを用意したら、実現できます。--Taisyo（会話） 2020年5月1日 (金) 13:01 (UTC)
- @Loasaさん、Q8jさん、Taisyoさん、片割れ靴下さん: 5月以降、議論が停止しています。今のところ、Loasaさんの仕様案をベースに議論を再開できそうだと思いますが、どうしましょうか？--ネイ（会話） 2020年8月24日 (月) 09:42 (UTC)
- うーん。僕自身の最近の感想として、最近はLTA:203が目につくんですが（移動荒らしという比較的めんどくさいことをされるためでもある）、結局のところ「バイト数を満たせば投稿はできる」わけですよね。多分発動して、見たら編集フィルターという機能によって阻止されたことがわかる。そしてフィルターのページからこのページにたどり着くことができれば、バイト数が規定より少ない、という条件はわかる。そうなれば適当にバイト数稼げばいい、ということはさすがにわかるでしょう。バイト数を稼ぐために、下手したら著作権侵害のおまけがついてくるかもしれません。・・・というのは203が「阻止されたのが編集フィルターという機能によること」「それが提案（裁量ではない）されたものとわかる（≒このページのフィルターからこの節を見つける）」「それを回避する方法がわかる」という、希望的観測の逆・・・絶望的観測によるわけですが。つまり条件が悟られたらその時点で実質（そのLTA相手には）無駄なフィルターになる可能性はあると思います（もちろんバイト数を増やすことで多少は対応できるでしょうが、こっちが２倍にするだけで巻き添えを考慮しないといけないのに対し、あちらはコピペ一回で済むわけで、いたちごっこはこっちが圧倒的に不利です）。というわけで効果は疑問（正確にはいつまで保つか疑問）ですが、まぁ効かなくなったら残念でした、で無効化すればいいですし、一時的でも効けばその一時は効果がある。希望的観測ですが、悟られなければずっとLTAの邪魔ができるかもしれない。というわけで、色々書きましたが概ね賛成です。
- 仕様について、Loasaさんの案に少し考えてみました。
- F2。500回、とおっしゃいますが、このフィルターの目的は半保護突破防止のはずです。自動承認されていないが、IPでもない、で十分では？（投稿回数が10回を超えたら、その後の編集は「半保護突破目的」ではなくなりますし、拡張半保護突破は到底現実的ではない）。必要ない利用者の編集を検出することは負荷、誤作動につながります。
- F3、対象ページ。私はすべてのページではなく、「標準名前空間以外」でいいような気がするんですが、どうでしょうか。現時点203がターゲットに使うのはサンドボックスが圧倒的に多いという印象ですが、LTA:ASPEやLTA:Iccicは標準名前空間を使うのでしょうか？（LTAページを見た感じでは使わなさそうな感じですが）使わないのであれば、単純に「標準名前空間以外」を条件として、標準名前空間を踏み台にされるようになったら、その条件を撤去することを検討されてはいかがでしょう。標準名前空間を除外するというふうに条件を厳しくすれば、その分要件（Loasaさんの「T」「B」「N」）を緩く（検出しやすく）できるかもしれません（あくまで慎重に）
- F2、F3共にあまり拘りません。--Q8j（会話） 2020年8月25日 (火) 08:03 (UTC)
- Loasaさんの仕様案を元に「閾値を非公開にする」のであれば、良いのではと思います。Q8jさんの指摘の通りです。閾値がバレた時点で、それを狙って編集するだけなのではと思います。やはり、ある程度は心理戦の部分があり、極端に厳しくすると誤爆が増えるリスクが大きいです。そうしないためには、柔軟に閾値を変えた上で、非公表にするが一番実効性が高いと思います。
- 対象LTAについても、指摘の通りLTA:ASPEについては、特に荒らす記事を拡張半保護。LTA:Iccicは薄々は気が付いているのだけど・・・状態でLTA:203対策に限定で良い様に思います。提案時と半保護の仕様が変わったのは大きいです。--Taisyo（会話） 2020年9月11日 (金) 10:49 (UTC)
- コメントが遅くなってすみません。私の意見は特別:差分/77290891の後半で述べたことがすべてですが、もう少し演説します。フィルタに限らずこの種の防御システムは、その効用や緊急性・重大性と副作用のバランスで考えるべきです。たとえば、その防御システムが対象とする問題行為が、ウィキペディアに対して致命的といえるほど重大な損害を与えるようなものであり（重大性）、かつ、緊急な対策を要するものでもあり（緊急性）、かつ、その防御システムがその行為に対する阻止として有効に働く(効用）ものであるならば、若干の副作用はやむを得ないでしょう。しかし本フィルタの対象とする問題行為は、そこまでしなければならないほど緊急性や重大性の高いものではありません。有効性という点でも（パラメーターを非公開にしたとしても）上でコメントされているようにいずれは突破されてしまうだろうし、多少時間をかければフィルターの意味もなさなくなる可能性が高いものです。本フィルタの効果はその程度しか期待できないのに対して、無関係な初心者が引っかかる確率がほぼ１００％であり、しかも短時間とはいえ、ブロックの可能性もあるというリスクは効果に見合ったものとはいえません。そして、フィルタの仕様上、非常に高い確率で無関係な初心者が引っかかる可能性は避けられません。ならばせめて副作用が発生したときの救済措置を十二分に用意しておく必要があります。私の考えではその救済措置の一つがパラメーターの閾値公開なのです。初心者が引っかかったときにT時間待てば自動的に回復できる、とわかるだけでも安心できます。たとえ短時間でもそれがわからないのは非常な不安になるものです。
- そのようなわけで、細かい仕様はお任せしてもよいのですが、パラメーターの閾値公開だけは絶対的な条件とします。ただ、多少は妥協して、NやBに関しては非公開でもよいでしょう。公開するのは最大ブロック可能時間、すなわちTの最大値だけでもよいとします。Tの最大値の公開すら駄目ということであれば、このフィルタは有用性のわりに副作用の害が大きすぎるということで、フィルタの作成自体に反対とさせていただきます。パラメーターTの最大値の公開すら認められない、ということであれば、それならばこのフィルタを作るのは止めましょう、というのが私の最終的な結論です。--Loasa（会話） 2020年12月31日 (木) 07:18 (UTC)
提案 前回の私のコメントから半年以上経過しましたが、Taisyo さんからの再コメントもなく、パラメーターの閾値公開については妥協・譲歩される余地はないようです。私としても前回のコメントで述べたとおり、これ以上の譲歩をする気はありません。したがって、本提案については合意が成立できなかったものと見做し、そろそろ合意不成立でクローズしてもよいのではないでしょうか。--Loasa（会話） 2021年7月23日 (金) 22:39 (UTC)
- 実効性が落ちることを承知の上で、Loasaさんの仕様丸のみで導入はどうでしょうか。丸のみの上で不具合があれば見直しで。見直しの時は再度提案を入れる形になります。--Taisyo（会話） 2021年7月24日 (土) 05:31 (UTC)
- 丸のみということは「Tの最大値は公開する」という条件も含めた仕様で作成する、という理解でよろしいでしょうか。--Loasa（会話） 2021年7月24日 (土) 06:48 (UTC)
- 「Tの最大値は公開する」で大丈夫です。此処で割れている訳ですので、とりあえず公表型で作りましょうです。公表された値に対して荒らしが対応しきれなければそのままですし、荒らし利用者が合わせてくるようであれば、再議論です。実働していないのに、結果を予想するのはある意味ナンセンスな気もしています。--Taisyo（会話） 2021年7月24日 (土) 07:15 (UTC)
- 了解いたしました。そういうことであれば作成に同意いたします。--Loasa（会話） 2021年7月25日 (日) 02:46 (UTC)
- 実効性が落ちることを承知の上で、Loasaさんの仕様丸のみで導入はどうでしょうか。丸のみの上で不具合があれば見直しで。見直しの時は再度提案を入れる形になります。--Taisyo（会話） 2021年7月24日 (土) 05:31 (UTC)
- で、Tの最大値として公表する値は12時間くらいが適当ではないでしょうか。実装上は、誤爆を避けるために Tを大きくすればNの値も大きくせざるを得ないし、実質的にはTが1時間程度であってもNの値はフィルターの意味がなくなる程大きなものになってしまうと考えられるので、12時間という制限は、実質的に実装上での制約にならないくらい十分すぎるほど緩い条件だと思います。--Loasa（会話） 2021年7月25日 (日) 02:46 (UTC)
- 12時間。それだけあれば、たまたま引っかかった利用者が待つのには丁度良く。荒らし目的であれば、その間にブロックしたり、荒らし回数を減らしたり出来ますね。スタートの値として丁度良いかもしれませんね。--Taisyo（会話） 2021年7月25日 (日) 13:11 (UTC)
ノートページでの除去
提案中
| 目的 | ノートページで除去があった編集を検出する。 |
|---|---|
| 理由 | 他人の発言の改竄や、取り消し線を引くべき自分の発言の除去を発見しやすくするため。他人の発言を除去できるケースは同意があった場合と過去ログ化に伴う場合以外では限られており、自分の発言を除去する場合は基本的に取り消し線を引く方が良いため。Wikipedia:編集フィルター/提案/ログ/2011年#会話ページのコメントの除去の防止の再提案。同意がある場合でもタグ付けなら大きな問題にはならないと判断。 |
| 発動条件 | ノートページで何らかの除去があった場合。 |
| 対処操作 | タグ付け |
--プログラム（会話） 2017年5月9日 (火) 08:02 (UTC)
- 私の一存では作成すべきか決められませんので、コメント依頼を提出いたしました。--ネイ（会話） 2017年10月21日 (土) 12:46 (UTC)
- 賛成 過去の利用者とのやり取りで会話ページの白紙化や発言除去が見られたため。--Licsak（会話） 2017年10月21日 (土) 14:22 (UTC)
- では、2人以上の賛成があり、かつ反対がなかったため合意成立とみなします。ただし、発動条件の詳細についてお聞かせください：
- 過去ログ化は除外しますか。除外する場合、どのような条件を想定していますか。
- 「ノートページで除去があった」の判定条件は何を想定していますか。「removed_linesが空ではない」という条件では緩すぎると考えます。
- 以上です。--ネイ（会話） 2018年1月12日 (金) 14:20 (UTC)
- 返信 過去ログ化のみを抽出するのは難しいと考えているため、過去ログ化を含めて検出することを考えています。当初考えていた判定条件は「removed_linesが空ではない」でしたが単純な追加も検出してしまうので、複数行に書き加える頻度は低いと仮定する必要はありますが「removed_linesが複数行あるか、added_linesが空である」あたりでしょうか。--プログラム（会話） 2018年1月15日 (月) 14:02 (UTC)
- コメント 2つ質問があります。
- 意味を変える文字を挿入するなど、バイト数が増える形で荒らしがあった場合はその文字を除去しますが、フィルターだけ見ると荒らしを除去した人が荒らしをしているように見えてしまいますが、それは想定の範囲でしょうか。
- 理由に他人の発言の改竄がありますが、検知するのは除去のみで、前の投稿と比べて増減なしの±0バイトになるような改ざん編集は検知しないのですか。
- 以上です。--duck775（会話） 2018年2月19日 (月) 14:31 (UTC)
- 1については「ノートページからの編集除去があった」という事実を意味するタグを付与するだけなので杞憂だと判断します。そのタグ付けで《荒らしを除去した人が荒らしをしているように見えてしまいます》というように見る人がいるとしても、そもそも現時点でも同様に（バイト数が減る時点で）荒らしをしているように見てしまうんじゃないかと。--iwaim（会話） 2018年4月10日 (火) 06:30 (UTC)
返信 コメントの改竄はできれば検出対象に含めたいと考えています。--プログラム（会話） 2018年9月16日 (日) 18:26 (UTC)
試験中のフィルター
安倍晋三銃撃事件における被疑者名記載の繰り返し緊急対策
試験中| 目的 | 安倍晋三銃撃事件における被疑者氏名が繰り返し記載されることの防止 |
|---|---|
| 理由 | Wikipedia:削除依頼/ログ/2022年7月10日などにある通り、安倍晋三銃撃事件における被疑者指名が（拡張保護にも関わらず）何度も記載される自体が発生しています。まだしばらく報道・世間一般は加熱しており、無知や誤解もしくは手違えや見通しによって、今後も記載の繰り返しが継続することが容易に想像されます。一方、ただでさえ版指定削除は削除者の負荷が高いため、これらの負担の軽減および不幸な事故を防ぐ必要があります。 |
| 発動条件 | 被疑者の氏名そのものおよび「（名字）容疑者」などがadded_linesに含まれる場合。ただし、念のため、管理者とフィルター編集者は発動条件から除外。 |
| 対処操作 | 不許可 |
| 警告文 | MediaWiki:Abusefilter-disallowed-安倍晋三銃撃事件における被疑者名記載の繰り返し緊急対策 |
| フィルター | 編集フィルター#178（変更履歴・一致記録） |
上記の目的・理由のため、緊急対策として、被疑者氏名の加筆を禁止するフィルターを緊急作成し有効および対処操作を「不許可」で試験運用開始しました。発動条件については、禁止ワードそのものが公開されてはいけないためフィルターの詳細は非公開としていますが、上記書いた情報だけで十分伝わるかと思います。 また、式自体は、特別:不正利用フィルター/test/178で、安倍晋三銃撃事件で削除となった版が検出できていること、および他の変更では検出されていないことを確認済みです。
なお、本件は当該記事以外にも大和西大寺駅など関連記事でも発生しており、関連範囲をすべて先回りして保護するなどが事実上不可能なため、また、ノートページ等への記載でも問題となるため、サイト全体での禁止となる編集フィルターでの対応が最善と考えています。
フィルターの稼働期間は、（緊急対策であることを考えて）加筆回数などを様子見しつつ各位がある程度冷えてきたと判断できた時には停止することが妥当かと思いますが、いつまでというのは現時点では全く見通せないので「当面の間」とするしかないと思います。
上記のとおりですので、本節では、コミュニティーに対して、上記の経緯などを説明し、その緊急作成の追認を依頼するものです。ただし、各位お分かりだとは思いますがWikipedia:鼻に豆を詰めないでをご理解の上、質疑や議論・コメントをお願いします。
--青子守歌（会話/履歴） 2022年7月10日 (日) 11:14 (UTC)
- 賛成 多少の誤作動は有れど、慣れていない利用者の記載や、極端な話出典を付けるために無意識的に書いてしまうのは避けられないので、管理活動的に運用する意味はあると思います。--Taisyo（会話） 2022年7月10日 (日) 11:34 (UTC)
- 賛成 対応に同意します。強力な措置となりますが、話題性やコミュニティ対応の負担を踏まえれば他に方法はないでしょう。なお、もし今後の議論で実名記載の合意が形成された場合は、速やかにフィルター停止をお願いする形になりそうです。--Y-route（会話） 2022年7月10日 (日) 11:56 (UTC)
- 賛成 やむを得ないでしょう。フィルターの内容も確認しましたが、最低限の内容で適切な範囲に対する不許可設定がなされていると思います。--Marine-Bluetalk✾contribs✾mail 2022年7月10日 (日) 16:22 (UTC)
- みなさま、賛成（追認）ありがとうございます。フィルター編集権限ある方は見れると思いますが、一致記録では、今日で5件の発動で、いずれも偽陽性なしでした。もうしばらく一致記録などは私の方でも注視していきますが、ひとまず24時間ぐらい経過した感じでは、問題なく意図通り役立っているようです。--青子守歌（会話/履歴） 2022年7月11日 (月) 10:38 (UTC)
- 賛成 上記対応に賛成します。--わたらせみずほ（会話） 2022年7月11日 (月) 12:49 (UTC)
- 賛成 削除対象となる問題投稿の繰り返し、全保護リスク回避（特別:差分/90424021なども考慮）の観点から緊急での編集フィルター対応はやむを得ないと考えます。また、起訴された場合など今後の状況に応じて「（名字）被告」なども適宜対応いただければと思います。1点疑問なのですが、一般利用者にも見えるフィルター解説文を、「プライバシー侵害対策」などに変更することはできるでしょうか？特別:不正利用記録のログを見ると、不許可対象となった一部ログで書かれた情報の組み合わせでWP:DP#B-2案件になる場合があるのではないかと思われます。--郊外生活（会話） 2022年7月15日 (金) 04:19 (UTC)
報告 少し様子を見直して＆直上で@郊外生活さんから提案のあったように、キーワードの追加やフィルター名を穏当にする変更フィルター#178の第6117版（差分）を実施しました。発動記録を見る限りでは現在も順調に（偽陽性なく）動いているようです。なお、追加キーワードですが、あまり増やすしすぎて（特に悪意ある編集者を躍起になってフィルターしようとして）も費用対効果という面で悪化するだけなので、今のところこれ以上はあまり追加したくないところです（細かい保守まで引き継いでくれる方が立候補していただけるなら役目譲りますので妨げるものではありません）。--青子守歌（会話/履歴） 2022年7月16日 (土) 03:29 (UTC)
情報 安倍晋三銃撃事件の2022年7月19日 (火) 02:49 (UTC) の版（削除済）でフィルターすり抜けが発生しました。比較的起こりやすいミスが原因で発生しており、差分を確認いただければ追加規制すべきキーワードも容易に分かると思いますので、再発防止のため対応をお願いします。--Y-route（会話） 2022年7月19日 (火) 15:22 (UTC)
- 報告 既に対応済みであった平仮名・カタカナ・氏名入れ替え・組み合わせ等の対応を強化しました。上記情報のケースにも対応しております。また、他フィルター(160)で抑止していたsummary, page_prefixedtitle, user_nameへの対処を本フィルターに集約しました。--えのきだたもつ（会話） 2022年7月19日 (火) 16:14 (UTC)
- まず、えのきだたもつさんの変更をリバートしました（バグ埋め込んでいるので）。詳細は管理者MLに投げましたので以降はそちらで。それはそれとして、Wikipedia:削除依頼/安倍晋三銃撃事件 20220719については、ミスではなく、悪意とまではいきませんがそういう編集を意図的にしないと発生せず、その投稿者に問題があって普通はそういう加筆はありえないと考えるのが自然です。また、そのキーワード自体に偽陽性が十分にありえるので、追加すべきではありません。偽陰性がある程度あって多少は手動が入るのは仕方ないので、偽陰性をゼロにしようとして偽陽性を増やさないようにしてください（それは編集フィルターの趣旨に反します）。--青子守歌（会話/履歴） 2022年7月20日 (水) 10:51 (UTC)
- 返信 (青子守歌さん宛) まずは、バグを埋め込んでしまい申し訳ありませんでした。偽陽性どころではなく全くの陰性に対しての誤動作でした。修正後はいつもの様に誤動作を監視していましたので、ご指摘のバグについては発生後まもなく修正しており、リバート前の版では修正済みでした。それについてはご確認の上でのリバートだったのでしょうか？バグの原因は、追加したキーワードには全くなく、正規表現の判定文の組み合わせの不具合によるものでした。引き継ぎ宣言もなく修正したのは申し訳なく思います。しかし、私が修正前の版においても、平仮名・カタカナや組み合わせ表現についても判定されており、もはや悪意のない単純な書き込み除去の域は超えていると思います。それらが悪意のないものか否かの判定も難しくなってきています。また、悪意があるか否かに関わらず、版指定削除は発生しコストが掛かることには変わりありません。フィルター160で同様の判定も行なわれていましたので、同じ様な判定を方々のフィルターで行っていては管理・監視上の負担も増えます。よって、一元管理・対処した方が良いと考え、前記通り本フィルターへの集約を行いました。本フィルターでは当初の目的のみを対処すべきとの事でしたらこのままでも良いと思いますが、一元管理・対処しても良いとの事でしたら、遅ればせながら保守の引き継ぎ宣言を致しますので、お任せいただければと思います。以前も申し上げましたが、編集フィルター記録の日に数回～10回程度の監視は今でも行っており、誤動作修正も行っています（それ故今回のバグも早期対処出来ています）。--えのきだたもつ（会話） 2022年7月20日 (水) 12:53 (UTC)
仕様変更提案
LTA対策フィルターを専用のメッセージに変更する
現在、「LTA対策」と書かれている編集フィルターでは、全て汎用のMediaWiki:Abusefilter-disallowedが使われています。
 | 実行された操作は、問題のある操作であると認識され、自動的に取り消されました。
This action has been automatically identified as harmful, and therefore disallowed. この通知の前に、問題点についての説明を既に受け取っていた場合は、それに従い問題点を改善してから、改めて投稿してください。
|
しかし、このメッセージを見て、何が問題だったのか何も書かれておらず、誤作動時の報告で、特に初心者の方々が戸惑っているように見えます。 LTA対策という性質上、偽陽性がある程度多いのは許容するしかないにしても（にしても多い気がしますけども・・・）、例えば「このメッセージは、実行しようとした編集内容が、長期荒らしと傾向が似ていると機械的に判断されたため表示されています。問題がない内容の場合にも誤検出される可能性があるので、その場合は報告してください」ぐらいは丁寧に書いてあげても良いのではないかと思います。
具体的な表現はともかく、ひとまず、フィルターの保守をしている方々（@えのきだたもつさん、@Nnhさん）からの、賛否もしくはコメントあればいただければと思います。--青子守歌（会話/履歴） 2022年7月12日 (火) 09:17 (UTC)
- LTA対策フィルタについては、そうと分かるような警告メッセージにした方が良いかもしれませんね。LTA本人がどう受け取るかは気にしなくても良いでしょう。--nnh（会話） 2022年7月12日 (火) 09:21 (UTC)
- 賛成 確かに専用メッセージに変更した方が良い様に思います。文面も基本的には例示された感じで良いと思います。--えのきだたもつ（会話） 2022年7月12日 (火) 10:00 (UTC)
賛成ありがとうございます。とりあえずメッセージを試作してみました。
| 荒らし・いたずら投稿と似た傾向の編集が含まれているため、操作は却下されました
この通知は、荒らしやいたずら投稿と似た傾向が機械的に検出された場合に表示されます。ただし、この通知を受け取ったからといって、必ず荒らし・いたずら投稿であると断定されたわけではなく、誤検出された可能性もあります。
編集内容を再確認し、荒らしやいたずらと判断されかねない内容が含まれていないかを確かめた上で、心当たりがない場合は誤作動を報告してください。 なお、悪意ある編集者対策も兼ねていることから、具体的にどのような内容が問題とみなされたかについては非公開となりますので、ご了承下さい。 |
細かい文面にこだわりがあるわけではないので、修正案がある場合は、コピペした上で改良して良い案を出していただければと思います。特に反対がなければ、提案後（修正案が提案後）178時間経過したら適用したいと思います。--青子守歌（会話/履歴） 2022年7月16日 (土) 03:51 (UTC)
- コメント 微調整として「誤作動を報告してください。」の句点まで太字に含めること、並びに最後の「ご了承下さい」を表記統一の観点から「ご了承ください」にすべきと思います。--Y-route（会話） 2022年7月19日 (火) 17:42 (UTC)
アカウント作成禁止フィルター（の一部）をタイトルブラックリストに移行できませんか？
誤作動報告のページを見ていて気づいたのですが、主にLTA向け対応でアカウント作成を禁止、つまりaction=createaccountを取り消すフィルターがいくつかあるようです（非公開フィルターなので具体的なリンクは貼りませんが、特別:不正利用記録を見れば、編集フィルター編集者なら分かります）。 これを見ていて気づいたのですが、いくつかは「重すぎるので分割」みたいなフィルターが見受けられました。
そもそもなのですが、これって編集フィルターじゃないといけないのでしょうか？つまり、アカウント名に対する正規表現による作成禁止は、本来、タイトルブラックリスト（※ウィキメディアではグローバルに管理されているmeta:Title_blacklist）によって、MediaWiki本体機能で実現される機能です。 ページの編集（作成されるページ名に対する禁止）であればいろいろな付随情報を組み合わせて精度高い禁止条件を作れるでしょうが、createaccountでは作成しようとするアカウント名ぐらいしか取れませんし、機能的には、フィルターでもタイトルブラックリストとほぼ同じことしかできません。
そこで、できる範囲で可能なものを、タイトルブラックリストに移行することを提案します。
タイトルブラックリストに移行する長所短所は
- 長所
-
- 編集フィルターのような重い処理ではなくサーバー負荷をかけない（#「条件の上限に達しました」の修正のようなことが起きにくくなる）
- （今のフィルターにあるような）あまり意味のないキーワード分割やフィルター分割が必要なく一覧で見られようになる
- jawikiだけでなく、全プロジェクトにおいてLTA対策になる
- 短所
-
- 即効性に欠ける：metaの管理者かスチュワードに、依頼して対応を待たないといけない
- 説明が大変？：metaの管理者やスチュワードに、キーワードの意味とかを英語で説明しないといけない
- 正規表現式（≒発動条件）が公開になる（ただ、一部例えばISECHIKAなどは公開状態でも対応されていることから、あまり問題にはならない？）
という感じだと思います。この長所短所の天秤（特に、正規表現式の公開/非公開の違い）移行できる式は移行するのが良いと思います。
実際にそれを判断できるのは、そのフィルターを活用してLTA対策をしている人たち（≒フィルターの主要編集者）だと思うので、以下で、たぶんそうだろうと思う方をpingします（違ったらor漏れてたらすみません）。
@えのきだたもつ, Nnh, and W.CC: 検討してもらえませんか＆検討結果を書いて教えてもらえますか。みんな管理者っぽいので、非公開の場での情報提供とか議論が必要なら管理者MLへ投げてください。
あるいは、全然違う理由で編集フィルターじゃないと駄目な理由などがあるのであれば、どこか（少なくともフィルターの説明欄）には書いておいたほうが良さそうです＋可能であればどのような条件の時は編集フィルターにすべきかという指針や経験則をオンウィキのWikipedia:編集フィルターのガイドラインあたりに書いて、未来の自分たちのために残したほうが良いです。--青子守歌（会話/履歴） 2022年2月16日 (水) 12:40 (UTC)
- コメント 長い間固定化しているキーワードでしたら移行した方が良いかと思います。現在の編集フィルターの仕様ですとcreateaccountは機能しますがautocreateaccountは機能していません。その為、ISECHIKAなどは他でアカウントを作成してjpwpにログインする（アカウント作成記録で「自動的に作成されました」と表示される）というフィルター回避を行っています。それがブラックリストに移行する事で全プロジェクトにおいてLTA対策になれば、非常に有効だと思います。そういう意味でブラックリストに移行したいキーワードはあります。とりあえず第1弾としてまとめておきますので、ブラックリストへの移行（依頼）はお願い出来ますでしょうか？
- 「重すぎるので分割」がどれを指されているのは分かりませんが、キーワード容量あるいはキーワード数の上限で関数がエラーとなったので関数呼び出しを2つに分けたり、#「条件の上限に達しました」の修正にも書きましたが、フィルター容量（おそらく行数でなくバイト数）の上限に達して全部保存されなくなり、特定LTA用として分離独立させた事はあります。「重すぎるので分割」した記憶はありません。
- #「条件の上限に達しました」の修正で問題となったのは、条件式や関数呼び出しなどのカウントが多くなりすぎて、1,000の条件制限に達していた為で、現在は解決済みです。このカウントに処理時間は含まれておりません。カウント方法などに関してはmw:Extension:AbuseFilter/Conditionsを参照して下さい。各フィルターの処理時間については、各フィルターの編集画面で、「最近のx,xxx操作のうち、このフィルターはx件(x%)に対して発動しました。平均して、実行時間はx.xxミリ秒でx件の条件制限を消費しました。」と、そのフィルターの実行時間を見る事が出来ます。mw:Extension:AbuseFilter/Conditionsには、要約すると「関数をキーワード毎に呼び出すより、1関数にまとめてキーワードを渡す方が速いよ。」とは書いてありますが、渡すキーワード数が多いと問題である事は書いていないので、キーワード数に関してはあまり気にしなくては良いのではないでしょうか？マニュアルにも「この関数は重いから避けた方が良いよ」みたいな事は書いてありますが、キーワード数に関しては特にありませんし。実際、createaccountを使用しているフィルターに関しては、実行時間は他のフィルターと比べても短いものです。--えのきだたもつ（会話） 2022年2月27日 (日) 09:47 (UTC)
「追加除去キーワード一致」系の編集フィルターはキーワードが追加除去されていない場合に発動しないように正しく設定する
誤作動報告を眺めて気づいたのですが、特定のキーワードが追加除去された場合に発動するフィルターが悪質なコードになって偽陽性を頻発している事に気づきましたので、正しく修正を提案するものです。 修正が仕様の変更にも及ぶ可能性があるのでここに書きます。
具体的には、Aというキーワードに反応したいフィルターがあった場合
- 追加系
contains_any(added_lines, A)
- 除去系
contains_any(removed_lines, A)
というような式だけになっているフィルターが散見されます。 しかし上記のような設定の場合、最初から「Xである。Aである。」と書かれた行からXを除去して「Aである。」だけにしたり、あるいはYであると追加して「Xである。Yである。Aである。」とした場合にも発動して、編集自体にはキーワードが含まれていないにもかかわらず発動する誤作動（偽陽性＝発動すべきではないのに発動してしまうこと）を引き起こします。 なぜなら(added|removed)_lines変数は名前にlinesと書かれている通り行単位だからです。 ですので、特に（ウィキテキスト上で）1行が長いページでは確率的に頻発します。 added|removedが分かりづらければ、それぞれ「編集後の行」と「編集前の行」と読み替えれば誤解することもないでしょう。
本来の意図は編集でそのキーワードが追加除去されたかを見たいはずなので、正しくは以下のようにすべきです。
- 追加系
contains_any(added_lines, A) & !contains_any(removed_lines, A)
- 除去系
contains_any(removed_lines, A) & !contains_any(added_lines, A)
つまりキーワードが「追加|除去された行に含まれている」だけではなく「追加|除去される前の行＝除去|追加された行に含まれていない」こと確実に見る条件でなければいけません。
なお、念のため書いておきますが、上記コードはあくまで例であり、in,like系のキーワードや他の機能を使って同様の「キーワード検出」を意図したコードも対象に含まれます。
なぜこんなコードが多く存在してしまっているかというと、おそらく
- 最初に「追加除去キーワード一致」系のフィルターを作った編集者が、編集フィルターの仕様について無知であったためバグを埋め込み
- さらに動作状況について定期的な確認を怠って偽陽性に気づかないまま放置し動作し続けており
- それをまた別に無知なフィルター編集者が中身を理解せずコピペして（＆発動結果の確認が不足して気づかず放置して）
- かついずれもフィルターの作成報告義務を果たさなかったためフィルターの内容周知が不十分で
- 上記2-3が繰り返されねずみ算的にバグコードが増加し
- 最後に止めるべき他のフィルター編集者の相互監視も不足し今日まで誰も指摘しなかった
という悪い連鎖があったのだと思います。 直接的には1-5番のような行動をしたフィルター作成者の責任が重いものの、最後の要因を考えれば、このような低質なフィルターが蔓延してしまったのを許したのは、私を含めたフィルター編集者全員の問題だったと思います。 特に、対処操作を不許可にしているフィルターにおいて偽陽性を埋め込んだ＆長期間放置した＆見過ごしたのは、なによりも避けるべきことであって（cf. ガイドライン）、これによって少なくない数の善意の利用者の意欲を削ぐことでウィキペディア日本語版の発展を大きく阻害してしまったことを自覚しましょう。
そこで、ここでは現時点で編集フィルターの編集権限を持っている全員に上記内容を通知し、以降に同様の問題を再発させないよう徹底させると共に、現時点で存在する（有効化されている）フィルターの全再点検＆修正を始めたいと思います。
まず以下、フィルター編集者全員への通知＆確認です（順は就任日順）。上記内容を全て読んで理解した方は、後ろに自分の4チルダ署名を書いてください。気になる点・不明点・コメントなどあれば本節末尾で解決してから署名をお願いします。 3ヶ月程度経過しても署名されていない場合は、フィルター編集者として活動する予定がないか、理解できる＝フィルターを正しく設定するだけの能力が不足していると考えられるので、フィルター編集権限の除去依頼を出すことを先に予告しておきます。 また、追加作業や手戻りを避ける観点から、上記内容を理解するまで（署名するまで）、各位にはフィルターの新規作成を含むフィルターの編集は控えていただくようお願いします。
- @Ks aka 98:
- @青子守歌:--青子守歌（会話/履歴） 2020年12月26日 (土) 02:53 (UTC)
- @Muyo:
- @Penn Station:
- @Chatama:
- @Triglav:
- @Iwai.masaharu:
- @Jkr2255:
- @VZP10224:
- @Taisyo:--Taisyo（会話） 2020年12月26日 (土) 12:30 (UTC)
- @Ohgi:
- @Tomo suzuki:
- @Cpro:
- @Whym:
- @Freetrashbox:
- @MaximusM4:
- @Y-dash:--Y-dash 2020年12月26日 (土) 22:27 (UTC)
- @ネイ:--ネイ（会話） 2020年12月28日 (月) 12:36 (UTC)
- @赤の旋律:
- @Infinite0694:--Infinite0694（会話） 2021年1月6日 (水) 19:10 (UTC)
- @アルトクール:--アルトクール（会話） 2022年4月6日 (水) 09:54 (UTC)
- @Yapparina:
- @えのきだたもつ:--えのきだたもつ（会話） 2021年1月1日 (金) 15:11 (UTC)
- @Miya:：上記内容を全て読んで理解しました。不用意に条件文をさわってこの問題を起こさないよう注意します。--miya（会話） 2021年2月6日 (土) 09:21 (UTC)
- @Sumaru:
- @伊佐坂安物:
- @Sakoppi: --Sakoppi (会話・投稿記録) 2020年12月26日 (土) 03:32 (UTC)
- @W.CC:--W.CC（会話） 2020年12月28日 (月) 10:27 (UTC)
次に現時点で存在しているフィルターの確認＆修正ですが、数がかなりあるので人海戦術するしかなく、上記で理解した署名をつけられたフィルター編集権限を持っている全員で、時間のある限り少しづつ協力をして、進めましょう。 以下の表に、少なくとも(added|removed)_linesが含まれる現在有効なフィルターの一覧を書いておきました（検索機能で抽出した）ので、これを全部埋めれば完了で良いと思います。
各セルに
- 修正の要・不要確認（不要な例：キーワード系ではない/意図して行単位条件になっている、など。先述の通り、例であげたコードそのままだけではなく同様の機能を使ったコード全てが修正が必要な対象です）
- 修正の完了報告（{{編集フィルター履歴}}をつけて）
をそれぞれ署名付きでお願いします。 どちらかだけでも、両方ともでも構いませんが、判断に迷う場合、フィルター作成者or直近の編集者にフィルターの意図や仕様などを問い合わせたほうがいいかもしれません。 その問い合わせの手間を考えると、可能であれば自分が作成したor詳しいフィルターは自分自身で確認＆修正が望ましいと思います。
緊急で無理してでも今すぐというほどの必要性はないと思いますが、対処が遅れれば遅れるほどjawpコミュニティーから編集フィルター（の編集者）への信用度が低下し続けますので、できる範囲で少しずつでも進めていきましょう。
編集フィルター（ひいてはjawp）の未来は、編集者各位（私も含めて）の腕にかかっています。対応よろしくお願いします。 質疑・コメント等は以下へお願いします。--青子守歌（会話/履歴） 2020年12月26日 (土) 02:53 (UTC)
質疑・コメント
コメントします。
- 上記の内容は理解しました。私個人については、当面は編集フィルターを編集する予定はないので、編集権限を除去頂いてもかまいません。
- 上記の提案を通すのであれば、「Wikipedia:編集フィルター/作り方」等に、避けるべきコードの例を書いておくべきように思います。過去の議論を全部読まなければフィルター編集者になれない、という状況は避けるべきように思います。
--Freetrashbox（会話） 2020年12月26日 (土) 05:10 (UTC)
- （追記）「修正要」と判断された場合は、判断した理由（さらに実際に誤作動したのか、誤作動しうるということか）と、できれば誤作動の例を差分で示して頂けるとわかりやすいと思います。--Freetrashbox（会話） 2020年12月26日 (土) 23:18 (UTC)
- （追記） いくつかチェックしてみたところ、アルゴリズムの問題というよりは、フィルターの保守の問題であるように思われます。ちゃんと保守が行われているフィルターであれば青子守歌さんが指摘するような文になっていても大きな問題はなさそうに思えます。また、編集フィルター#22などは青子守歌さん自身が比較的主要な編集をしているように思われますが、典型的な誤動作をしており、青子守歌さんでもうっかりするような構文上のミスをフィルター編集者全員に求めるのは少し酷なようにも思います（この編集が問題ないのであれば、提案の問題点をもう少し詳しく説明してもらえると助かります）。--Freetrashbox（会話） 2020年12月28日 (月) 21:50 (UTC)
- （追記） フィルター#126のように記載すればいいんですかね？#126は記載が大変読みやすいです。「模範例」を挙げて貰った方が改定が進むように思います。書き直したソースのダメ出しされるのは辛い。--Freetrashbox（会話） 2020年12月29日 (火) 23:29 (UTC)
- @Freetrashbox: 模範例は既に冒頭に書いた通り(added|removed)_linesを両方確認する以上はないのですけれども、具体例をということでフィルター#17の第2423版（差分）を修正しました。例えば、要不要コメントにある特別:不正利用記録/1327626はこれで条件一致しなくなりますが、（意図が正しいかはおいといて）意図通りと考えられる特別:不正利用記録/1306000はこれまで通り条件一致します（それぞれに対して#17を試験すれば確認できます）。--青子守歌（会話/履歴） 2020年12月30日 (水) 03:21 (UTC)
- 例示、ありがとうございます。なるほど、変数も使えるんですね。#126のように同じ単語を2回並べるのはバグの遠因になると感じたので、確認できてよかったです。--Freetrashbox（会話） 2020年12月30日 (水) 03:32 (UTC)
- コメント contains_anyに関してですが、配列変数に対応しているのは第1引数（通常added_linesやremoved_linesなどを書きます）だけで、第2引数以降は対応していないので、例えば、
- 例示、ありがとうございます。なるほど、変数も使えるんですね。#126のように同じ単語を2回並べるのはバグの遠因になると感じたので、確認できてよかったです。--Freetrashbox（会話） 2020年12月30日 (水) 03:32 (UTC)
- @Freetrashbox: 模範例は既に冒頭に書いた通り(added|removed)_linesを両方確認する以上はないのですけれども、具体例をということでフィルター#17の第2423版（差分）を修正しました。例えば、要不要コメントにある特別:不正利用記録/1327626はこれで条件一致しなくなりますが、（意図が正しいかはおいといて）意図通りと考えられる特別:不正利用記録/1306000はこれまで通り条件一致します（それぞれに対して#17を試験すれば確認できます）。--青子守歌（会話/履歴） 2020年12月30日 (水) 03:21 (UTC)
keywords := ["A", "B", "C"]; contains_any(added_lines, keywords) & !contains_any(removed_lines, keywords)
- の様なコードを書いても正常動作しませんので、第2引数以降に列挙するしかなく、現状のコードになります。回避策をご存知の方がおられましたら教えて下さい。--えのきだたもつ（会話） 2020年12月31日 (木) 09:12 (UTC)
- 変数が使えないのであれば、少なくとも複雑な構文のフィルターについては、安易に変えない方がいいかもしれませんね。--Freetrashbox（会話） 2021年1月1日 (金) 01:53 (UTC)
- の様なコードを書いても正常動作しませんので、第2引数以降に列挙するしかなく、現状のコードになります。回避策をご存知の方がおられましたら教えて下さい。--えのきだたもつ（会話） 2020年12月31日 (木) 09:12 (UTC)
コメント 非公開フィルターの内容確認が目的でフィルター権限をつけっぱなしにしているだけで、構文の知識はほとんど持たない者ですが、いくつか順番に見てみました。
- 上の表についてですが、「要・不要」が何を意味するか、「修正の要・不要」なのか、それとも「フィルターの要・不要」なのか、分かりにくいです。（Taisyoさんは「フィルターの要・不要」とお考えなんじゃないでしょうか？）
- 上の表にフィルター作成者の欄を設けて、作成者の意見も書いてもらってはどうでしょう？
- ( rmwhitespace(added_lines) rlike rmwhitespace(" とか
( rmwhitespace(added_lines) rlike rmwhitespace("& contains_any(lcase(added_lines),は問題ないのでしょうか？（不勉強ですみません） - 途中まで見て回ったのですが（ちょっと本件からは外れますが）特別:不正利用フィルター/15と特別:不正利用フィルター/50は、なぜ非公開フィルターなのか、疑問に思いました。#50はWikipedia:編集フィルター/一覧にも見つかりませんし。
--miya（会話） 2020年12月26日 (土) 12:41 (UTC) 訂正：コピペミスがあった箇所に修正を入れました。--miya（会話） 2020年12月26日 (土) 13:48 (UTC)
- 私向けのメッセージがあったので。確かに「実際に使っているかどうか」「実際に有効性があるかどうか」のコメントです。修正の必要・不要では見ていないです。元の構文（今回は禁句系フィルターの元）を作るのは正直に難しいです。半面、引っ掛けるワードを考えるのは、結構有効なワードを見つけています。あとのコメントにもつながるのですが、構文が分からない人でも「本文ｏｒ概要、両方か」、「反応させる編集数」・「引っ掛けたいワード」を入れたら簡単に動く「禁句系フィルター」を用意した方が良いのではと思います（できたとして、移行をどうするかの問題はありますが）。--Taisyo（会話） 2020年12月26日 (土) 13:02 (UTC)
- @Miya and Taisyo: 表の下の「こういう風に書いてください」というお願いにちゃんと書いてある通り、また、本日の晴天さんや私の前例通り、その列では修正の要・不要を求めています。なぜならここは「フィルターを修正する必要がある」という変更提案の場であって、フィルターを廃止するという話は別にしていませんので（廃止しても良いから修正不要、という話ならそれはそれで良いと思いますが）。というわけで、もし間違った意味で書いてしまっていたのなら、修正あるいは除去してもらえますか。表の方にも間違えないように明記しました。--青子守歌（会話/履歴） 2020年12月26日 (土) 13:19 (UTC)
- 了解しました。削除時の偽陽性反応問題の対応で、構文問題であることを理解しました。そのあと、この様な目線でのコメントに書き換えます。だた、偽陽性判定も問題ではありますが、いくつか見ていて他の問題点も見つけました。
- 現在使用していない（極端な話削除済も）の同様のフィルターも、コピペによる拡散防止のために正しい公文に書き換えるべきでは。
- 数が多いのは仕方ないにしても、同じ目的のフィルターが複数ある場合があるので、まとめた上で廃止フィルターを削除するべきでは。
- 削除時の偽陽性を含め、他に考えられる対応を行った方が、さらに良いのではと思います。--Taisyo（会話） 2020年12月27日 (日) 05:19 (UTC)
- 了解しました。削除時の偽陽性反応問題の対応で、構文問題であることを理解しました。そのあと、この様な目線でのコメントに書き換えます。だた、偽陽性判定も問題ではありますが、いくつか見ていて他の問題点も見つけました。
- @Miya and Taisyo: 表の下の「こういう風に書いてください」というお願いにちゃんと書いてある通り、また、本日の晴天さんや私の前例通り、その列では修正の要・不要を求めています。なぜならここは「フィルターを修正する必要がある」という変更提案の場であって、フィルターを廃止するという話は別にしていませんので（廃止しても良いから修正不要、という話ならそれはそれで良いと思いますが）。というわけで、もし間違った意味で書いてしまっていたのなら、修正あるいは除去してもらえますか。表の方にも間違えないように明記しました。--青子守歌（会話/履歴） 2020年12月26日 (土) 13:19 (UTC)
- 私向けのメッセージがあったので。確かに「実際に使っているかどうか」「実際に有効性があるかどうか」のコメントです。修正の必要・不要では見ていないです。元の構文（今回は禁句系フィルターの元）を作るのは正直に難しいです。半面、引っ掛けるワードを考えるのは、結構有効なワードを見つけています。あとのコメントにもつながるのですが、構文が分からない人でも「本文ｏｒ概要、両方か」、「反応させる編集数」・「引っ掛けたいワード」を入れたら簡単に動く「禁句系フィルター」を用意した方が良いのではと思います（できたとして、移行をどうするかの問題はありますが）。--Taisyo（会話） 2020年12月26日 (土) 13:02 (UTC)
- @Miya: rmwhitespaceやlcaseは引数の文字列を置換するだけの関数なので、問題があることに変わりありません。投稿者が追加除去していないキーワードが含まれているのは同じですので。--青子守歌（会話/履歴） 2020年12月28日 (月) 01:14 (UTC)
コメント 禁句系フィルターは上手に使えば、記事の保護やIPのブロック数など減らすことが出来るなど有効な側面もあります。また、個人名をばらまく、いわゆる「知能知数が低いと思われる事が原因のLTA」には相当有効（そうしないと抑止力が無い）です。構文ミスを防ぐ側面もあり、2015年7月17日のフィルター37の不具合時に「簡単に運用できる禁句系フィルター機能」の実装をお願いした記憶があります。しかし、「メタに要望しています」や「お願いしましたが出来ませんでした」など、連絡はいただけておりません。今でも、「簡単に運用できる禁句系フィルター」の実装をお願いしておりますので、今からでも良いので、動いてもらえないでしょうか。実際の動作状況は、フィルター37の不具合以降は、目に見える形での大規模不具合は起こしていないはずです。--Taisyo（会話） 2020年12月26日 (土) 12:54 (UTC)
- 優先して修正すべきなのは投稿が差し止められる（かつ無効化されていない）フィルターあたりでしょうか。対処操作が何も付いてないフィルターは当面放置しても実害はほぼないだろうと思います。[5]から「対処操作」の列をコピーしておきました（ただし、あくまで現時点の対処操作を記しているだけなので、今後フィルターが変更されれば齟齬が出るかもしれません）。 --whym（会話） 2020年12月27日 (日) 11:43 (UTC)
- コメント フィルター126ですが、禁句ワード加筆（主に悪戯）を有効に検出しているのに、フィルター内のメモにも書いてありますが、誤動作の多さを理由に「不許可」が外されていました。確かに誤動作もありましたが、毎日の様に検出される（悪戯加筆が行われる）のに不許可に出来ないものかと、本提案前でしたが、2020-10-22にadded_linesに加えremoved_linesにない事もチェックする様に修正し、かつ禁句ワードを含む正常ワードを辞書等で調べて上げて除外ワードとする処理も加え誤作動の防止を強化し、試運用ののち2020-10-29に不許可を復活させました。その甲斐もあってか、毎日の様に行われる悪戯投稿を有効に不許可に出来ております。それでも、思いもよらない禁句ワードを含む正常ワードは出て来る（作品特有ワードが多いです）ので、毎日数回の「編集フィルター記録」のチェックは欠かさず続けており、メンテナンスは怠っておりません。
- この様に誤動作防止の為には、added_linesとremoved_linesの両方をチェックするだけでなく、禁句ワードを含む正常ワードを除外ワードとする処理も状況によっては必要ではないでしょうか？また、特に現在「編集フィルター記録」で動作が確認出来る不許可フィルターについては、作成者または編集者が、毎日（私は一日数回行っていますが、最低1日1回）のチェックを行い、誤動作の早期発見と早期対応を行うべきかと思います。
- contains_anyでadded_linesとremoved_linesの両方をチェックするという事は、検索が2倍になるという事で、単純計算で動作時間が2倍になるという事になります。contains_anyは負荷が重く避けるべき関数とはされていませんが、最終的な対処フィルター数は分かりませんが、数多くのフィルターで対処が行われた場合、フィルター全体の動作時間のシステムへの負荷の増加は大丈夫なのでしょうか？
- 本提案とは別件になりますが、先日あるLTAの問題加筆ワードを不許可に出来ないかと、それを行っている既存フィルターがないかと、全フィルターを見て探していたときに思ったのですが、現在「編集フィルター記録」を見ても動作状況を見ても、しばらくの間全く動作していないフィルターも見受けられたので、急ぎではありませんが、これらの整理（削除）も負荷軽減の為にも必要ではないかと思いました。--えのきだたもつ（会話） 2020年12月28日 (月) 06:08 (UTC)
- 読んで少し言葉が足りなかったかと思ったので、謝罪と補足をさせてください。ここで↑にあげたフィルターおよびフィルター編集者が全て悪いとは言うつもりはありません。誤解を招く表現だったかもしれず、そこはお詫びします。補足するならば、「今回指摘されたような問題が含まれている」フィルターと、「そのような問題のあるフィルターの管理を放置して誤作動を見過ごした」フィルター編集者に責任と努力不足があるということです（後者の「見過ごし」という意味では相互監視すべき全員の問題という意味はあると、これは先に述べたとおりです）。列挙されているのはそれら問題を含む可能性がある候補の一覧であり、こえこそ偽陽性を多分に含みます。もし、えのきだたもつさんを含む適切に管理・修正をかけているフィルター編集者が管理しているフィルターについては、そのままで問題ないのであれば「修正不要」と報告いただければ十分だと思います。--青子守歌（会話/履歴） 2020年12月28日 (月) 14:39 (UTC)
- コメント 15番は作成時の議論では「どの部分を残せば発動しないかと言う事があるので、非公開であるべきである」との意見がありますが、現時点でのフィルターで発動しなければ「削除依頼テンプレートの除去編集」と言えなくなると思います。したがって、「どの部分を残せば発動しないか」の秘匿に意味はないと考えます。
- 「3ヶ月程度経過しても署名されていない場合は、（中略）フィルター編集権限の除去依頼を出す」ことに反対します（「反対票を投じる」という意味で捉えてください）。Wikipedia:編集フィルター/権限付与の申請では「一定期間、活動がとまっている」としか書かれていないので、議論もなしに「一定期間」をかなり短い3か月間に定めていると捉えられかねないためです。悪用された場合の危険性がより高いインターフェース管理者は6か月と定められているので、「一定期間」が常識的に3か月間を指すとは言えませんし、編集フィルター編集者の規定がインターフェース管理者よりも厳しい理由も説明されていません（したがって、この議論を合意形成として扱っても現状では反対します）。なお、これを機に編集フィルター編集者の自動退任を定める合意形成を行うことには賛成し、合意形成を行わない場合でも（削除者とボットフラグと同等の）1年後に除去依頼を出すことには賛成します。--ネイ（会話） 2020年12月28日 (月) 12:36 (UTC)
- 15番は作成時には非公開で提案しましたが、現在は当時とは状況も内容も変化しているため、公開とすることに反対しません。 除去提案を行うことについても、最終的にはコミュニティの意見に基づいて除去が判断されることになるため、それ自体には反対はしません。しかし、3か月という短い期間設定や、反応がなければ全員一律で除去提案を行うということは少々強引な印象を受けます。例えばオーバーサイトであるPenn Stationさん、Infinite0694さんについては、仮に今後反応がなかったとしても、非公開フィルター履歴へのオーバーサイトが不可能になる&他のオーバーサイトによる秘匿処理の正当性を監視できなくなるという点において、除去には強く反対せざるをえません。（非公開フィルターの検知履歴は、管理者権限のみでは閲覧できません（参考リンク）。一般利用者にも閲覧できないためオーバーサイト実施の優先度は下がりますが、編集フィルター編集者には依然閲覧可能な状態となるため、方針に該当する記述があれば秘匿処理を行うことになります。）オーバーサイトでなくても、管理者と兼任する方であれば、荒らし対応の参考に非公開フィルターの内容や履歴を閲覧したい方はいるはずです。なお、編集者権限は編集目的の保持に限るべきと考える方が多いならば、今後管理者には「abusefilter-view-private」権限を設定することは一つの選択肢になるかもしれません。--W.CC（会話） 2020年12月28日 (月) 13:52 (UTC)
- まず最初に、3ヶ月という期間に別にこだわりがあるわけではないので、半年でも1年でもなんでもいいんですけれども。ここで私が求めたのは「フィルター編集者がフィルターを編集するに当たって当然知っておくべきことを通知するので、ちゃんと応答（署名）してね」という至極単純なことです。しかもpingで通知までされている中で、見落としがないように注意も払ってます。その状況下ですら短い応答もできないのであれば、そのような人が、今後もフィルターを正しく作成・編集し、かつログを定期確認してコードを管理してバグ報告もちゃんと読んで応答して、ということが出来るのかはかなり疑問です。完璧にやれとは誰も言ってません（私もできてませんから）。しかし重大な問題があったという報告下で、最低限の要望として「うん、分かったよ。今後は気をつけるよ」の一言を求めていることに、そこまで目くじら立てて「やりすぎ」と主張する気持ちに、逆に私は理解が及びません。権限保持の目的がログ閲覧目的かどうか、それによって応答に「編集しないから関係ないよ」が含まれているかは知りようがないのでどっちでもいいとして、なんにせよ管理者権限と同程度の非公開情報を閲覧できることから管理者と同じく同等の「3ヶ月」、という期間がそんな大騒ぎするような設定なんでしょうかね…。最初に書いた通り、期間とかは些事であって、もちろん不活性な人を辞めさせるかどうかも自転車置き場の屋根の色程度の話であって、重要なことは既存＋今後のフィルターが正しくバグなく修正＆作成されることですので、それが達成・促進できる代案があるなら期間延長でもなんでも議事を進めていただければ助かります。--青子守歌（会話/履歴） 2020年12月28日 (月) 14:29 (UTC)
- ひとまず、3か月という設定にこだわりがないとのことで安心しました。私もご提案の趣旨や目的には賛成しております。オーバーサイトのお2人に対する除去反対を除けば、「そこまで目くじら立てて「やりすぎ」と主張する」ほどのことをしたつもりはないのですが、そのように伝わってしまったのであれば申し訳なく思います。幅広く活動していらっしゃる青子守歌さんにおかれましては十分ご存じのことと思いますが、強い言葉を使えば強い反応が返ってくることは自然なことですので、表現にはご配慮いただければと思います。--W.CC（会話） 2020年12月28日 (月) 14:55 (UTC)
- 【署名について】「理解した方は署名を書いてください」と「理解するまでフィルターの編集は控えてください」を切り分けてほしいです。つまり
- 「読んだら署名してください」
- 「完全に理解するまでフィルター編集は控えてください」
- を分けてほしいのです。私はご意見の趣旨は理解しましたが「気になる点・不明点・コメントなどあれば本節末尾で解決してから署名をお願いします」と言われたら署名できません。--miya（会話） 2020年12月29日 (火) 01:25 (UTC)
- 署名する＝理解する＝フィルターの編集ができるようになる、という等式を分離することは出来ないと思います。まず「単に読んだら署名」というのは良くなくて（最初そう書いてましたが気づいたのでやめた）、「なんだか分からんけど読んだからヨシ」みたいなのは困るわけです。この段階で署名されても何の意味もなくて、何が求められているのかが分からないなら（他の人も同じことで困ってるかもしれないので公開の場で）聞いて、自分の腑に落ちてから署名してもらう必要があります。署名の理由は、「署名した＝この問題を起こさないようにします」という宣言をしてほしいという意味であって、署名してからでないとフィルターの編集をしないでくれというのはここから来てます。先述の通り「問題を起こさないです」に「俺はログの閲覧しかしないから」が含まれているかは（知りようがないので）不問です。このように、これらは全部同時に起きるはずなので、分けても意味がないと思うのですけれども…？--青子守歌（会話/履歴） 2020年12月30日 (水) 04:16 (UTC)
- 「署名した＝この問題を起こさないようにします」という宣言をしてほしいという意味とのこと、了解しました。--miya（会話） 2021年2月6日 (土) 09:21 (UTC)
- 署名する＝理解する＝フィルターの編集ができるようになる、という等式を分離することは出来ないと思います。まず「単に読んだら署名」というのは良くなくて（最初そう書いてましたが気づいたのでやめた）、「なんだか分からんけど読んだからヨシ」みたいなのは困るわけです。この段階で署名されても何の意味もなくて、何が求められているのかが分からないなら（他の人も同じことで困ってるかもしれないので公開の場で）聞いて、自分の腑に落ちてから署名してもらう必要があります。署名の理由は、「署名した＝この問題を起こさないようにします」という宣言をしてほしいという意味であって、署名してからでないとフィルターの編集をしないでくれというのはここから来てます。先述の通り「問題を起こさないです」に「俺はログの閲覧しかしないから」が含まれているかは（知りようがないので）不問です。このように、これらは全部同時に起きるはずなので、分けても意味がないと思うのですけれども…？--青子守歌（会話/履歴） 2020年12月30日 (水) 04:16 (UTC)
- 【署名について】「理解した方は署名を書いてください」と「理解するまでフィルターの編集は控えてください」を切り分けてほしいです。つまり
- ひとまず、3か月という設定にこだわりがないとのことで安心しました。私もご提案の趣旨や目的には賛成しております。オーバーサイトのお2人に対する除去反対を除けば、「そこまで目くじら立てて「やりすぎ」と主張する」ほどのことをしたつもりはないのですが、そのように伝わってしまったのであれば申し訳なく思います。幅広く活動していらっしゃる青子守歌さんにおかれましては十分ご存じのことと思いますが、強い言葉を使えば強い反応が返ってくることは自然なことですので、表現にはご配慮いただければと思います。--W.CC（会話） 2020年12月28日 (月) 14:55 (UTC)
- フィルター#22ですが、警告の際に表示されるメッセージで、誤爆の可能性と、フィルター発動の条件になるマジックワードの仕様に関する調査をお願いする文言を挿入しています。おぼろげながらですが、ここで言われている典型的な誤作動に気が付いて、その当時はそのような仕様であると判断したのと、マジックワードが多用されている状況に対する抑止力のようなものを期待して警告文書に文言を入れたような感じだと思っています。修正対象の文書であるかどうかに限らず、#22で検知対象としているマジックワードは標準記事空間での使用は極力回避すべきと考えているので、現行のままで置いておくのも一つの手段ではないかと思いますが、「誤作動をなくす」ことを最終目標とすることに強い合意があるのであれば、そちらを優先することに異存はありません。--VZP10224（会話） 2020年12月31日 (木) 08:49 (UTC)
- 修正するにしても、修正を行ったことで構文を間違えたことでの誤動作を防止するために、構文の修正を一時的にはありますが見送っています。具体的な構文が欲しい側面もあります。曲りなりに誤動作なく（潜在的な誤動作リスクはありますが）有用に動いているので、一定間隔で動作チェックはしていますので、一時的な未修正が大きな問題になることは無いと思います。荒らし利用者に「編集フィルターやめるから、荒らし行為やめてね」なんてことは出来ませんし。--Taisyo（会話） 2021年1月1日 (金) 01:17 (UTC)
- 私も、現状おおむね問題が無く、管理する人がいるフィルターに関しては、現状維持でよいと思います。前にも書いた通り、今回提案された方法でも誤作動を完全に防ぐことはできないので、従来通り、有用性と無害性を比較した上での小まめな調整が一番かと思います。--Freetrashbox（会話） 2021年1月1日 (金) 01:53 (UTC)
- 補足説明。私自身は長い目で見たら直すべきの立場も取っています。提案内容にもある誤動作のリスクは確かにありますので、（0に出来ないにしても）誤動作リスクの軽減は一定の理解はできます。ただ、不確かな修正を行うことでフィルターの有効性が無くなったり、別の意味での誤動作を起こす可能性も存在しています。5年前に青子守歌さんが「誤動作内容に必要なチェックを」と言われて、実際に行っています。また、誤動作があるにしても、引っ掛ける言葉の工夫で誤動作回避を実際には既に行っている場合もあります。修正に伴う誤動作と発生と、監視することでの軽減。提案者の青子守歌さんが、モデルフィルターを作って対応してもと思います。先にも言いましたが、私は5年前に「誤動作の少ない禁句系フィルターの作成のお願い」をしております。これだけ多いということは、日本語版の荒らし対応に有効であると認められているといったところです。別に編集フィルターが特権階級のものとも思いません（青子守歌さんはそんなことを言っていたような気がします）。使える道具はどんどん使っていくべきです。半保護にも限界はありますし、全保護してしまうと記事の発展は止まってしまいます。拡張半保護は最近出来ましたが、禁句系フィルターは結構有効なのです。ヘタな修正をしないように、様子を見ている部分もありますし、別に信用無くすことはしてないぞと言いたいです。--Taisyo（会話） 2021年1月3日 (日) 03:47 (UTC)
#15の対処操作
編集フィルター#15（変更履歴・一致記録）（削除依頼テンプレートの除去）は正式運用中ですが対処操作がありません。対処操作を「警告、タグ付け」とすることを提案します。--プログラム（会話） 2019年1月4日 (金) 09:53 (UTC)議論ページへリンク--プログラム（会話） 2019年1月14日 (月) 04:48 (UTC)
- 以前の議論でも言及されているとおり、テンプレートを除去してよい場合（たとえば、削除依頼テンプレートを貼ったがサブページを作成しないまま放置した場合）もあるので、警告するのはもう少し慎重に行いたいと思います（警告文の内容にもよります）。一方、タグ付けに関しては行っても特に問題はないと思います。--ネイ（会話） 2020年5月5日 (火) 09:57 (UTC)
- 一部
対処 タグ付けのみ実施しました。--ネイ（会話） 2020年6月4日 (木) 03:04 (UTC)
- 一部
@プログラム and ネイ: WP:EF/FPでの報告で気づいたんですが、これ「試しに作ってみた」が実装内容や対処操作をどうするかなどの合意や議論を経ずに放置されたままのがいつの間にか「正式運用」になってしまって、#提案から正式稼動までの流れに違反していたものなのですね（cf. Wikipedia:編集フィルター/一覧/削除依頼テンプレートの除去）。操作がタグ付なのであまり大きな影響はないですが、誤作動の報告もあることですし、対処操作付けの提案＆実施はちょっと誤りだった（先にやるべきことがもっとあった）のではないかな、と思います。差し戻せ、というわけではもちろんないですが、気づいたことのコメントだけとりあえず。--青子守歌（会話/履歴） 2020年7月21日 (火) 15:08 (UTC)
- うーん、誤作動の修正提案のついでに、正式稼働の追認提案も行うのはどうでしょうか。--ネイ（会話） 2020年7月21日 (火) 15:41 (UTC)
- 先にフィルターの公開提案を出すので、こちらは一旦保留（公開提案が決着した後に再開）ということで。--ネイ（会話） 2020年12月29日 (火) 05:40 (UTC)
#15を公開する提案
「「追加除去キーワード一致」系の編集フィルターはキーワードが追加除去されていない場合に発動しないように正しく設定する」の節でも提起されたことですが、編集フィルター#15（変更履歴・一致記録）（削除依頼テンプレートの除去）は非公開になっています。現行版では非公開にする必要がなさそうです。作成時の議論では「どの部分を残せば発動しないかと言う事があるので、非公開であるべきである」との意見がありましたが、現行版ではそのような問題がなくなっています（フィルターが発動しなければ、削除依頼テンプレートの除去をしていないと言える）。したがって、フィルターの公開を提案します。--ネイ（会話） 2020年12月29日 (火) 05:40 (UTC)
- 半年以上経過しましたが、反対はありませんでした。これ以上コメントがなければ、1週間後をめどにフィルターを公開します。--ネイ（会話） 2021年7月24日 (土) 06:09 (UTC)
- 対処 公開しました。--ネイ（会話） 2021年10月4日 (月) 04:29 (UTC)
#12でグローバル利用者名変更者に関する条件を外す提案
編集フィルター#12（変更履歴・一致記録）（新規利用者による他利用者ページの編集）はグローバル利用者名変更者による編集を除外する必要がありました。しかし、利用者名変更操作に伴うページ移動はphab:T212082での修正（2019年9月）により編集フィルターにかからなくなったため、除外の必要がなくなりました。したがって、当該条件の除去を提案します。--ネイ（会話） 2020年12月29日 (火) 05:45 (UTC)
- 半年以上経過しましたが、反対はありませんでした。これ以上コメントがなければ、1週間後をめどに編集します。--ネイ（会話） 2021年7月24日 (土) 06:15 (UTC)
- 対処 編集しました。--ネイ（会話） 2022年1月12日 (水) 06:00 (UTC)
#12での不許可メッセージ文面およびログ文面を修正する提案
昨年12月29日にWikipedia:編集フィルター/誤作動/報告#Oda shiga：利用者:ポンコツ1号において、編集フィルター#12（変更履歴・一致記録）（新規利用者による他利用者ページの編集）に関する誤作動報告が寄せられましたが、フィルターは設定どおりの動作をしており誤動作ではありませんでした。不許可メッセージには「新規利用者がほかの利用者の利用者ページを編集することは許可されていません。 」という一文がありますが、これが「自動承認された利用者」ならば編集できるはず、という誤解を与えたのだと思います。実際には、「新規利用者」より厳しい条件が設定されていますので、「自動承認された利用者」になっただけでは、利用者ページの編集をする事は出来ません。ログで公開されている文面にも「新規利用者による他利用者ページの編集」とあり、同様の誤解を招いているものと思われます。そこで、今後同様の誤解を招かない為にも、両文面の修正を提案します。
ウォッチリストのフィルターなどで用いられている利用者区分で、仕様に合った丁度良い言い方があるのですが、#12は非公開フィルターであるので、間接的に仕様を明らかにする事になり、それを許容するか否かが問題になってきます。また、「新規利用者」「自動承認された利用者」の程、よく知られた言い方ではないではないので、適切ではないかもしれません。 その他で考えたのですが、「新規利用者」を「編集経験の浅い（または、「少ない」）利用者」と変更するのは、どうでしょうか？他に良い文面があれば提案して下さい。--えのきだたもつ（会話） 2022年1月4日 (火) 14:37 (UTC)
- コメント 「編集経験の浅い利用者」に変えることに反対はしませんが、他の案を挙げるなら「新規参加者」でしょうか。Wikipedia:新規参加者を苛めないでくださいから着想しています。Wikipedia:新規参加者を苛めないでくださいは自動承認されれば考慮しなくても良いということにはならないと思います。ただ、紛らわしいという意見は予想します。
個人的には、基準を拡張承認に揃えて公開するというのも考えましたが（そのほうが純粋な新規利用者にはフィルターに関して説明しやすい）、特定利用者に粘着するLTAによる利用者ページ荒らしの可能性を考えると悩みますね（公開すると、荒らしにとっては明確な目標がわかってしまうため。また特定ページの基準を強化しにくくなるため。管理者・インターフェース管理者以外の利用者ページだと全保護での対応も容易ではないため）。もし管理者・インターフェース管理者以外の利用者ページで現実化した場合は、極端な話、利用者ページなので本人と管理者以外不許可にする条件を追加する方法もあるとは思います（本人を救済した点を除けば事実上の全保護）。あとは、拡張承認にしても（原則の基準は公開されているとしても）、拡張半保護突破荒らしがあったページのみさらに厳しい基準を設定するためフィルター自体は非公開という手もあるかもしれません。--郊外生活（会話） 2022年1月12日 (水) 20:21 (UTC)- コメント 基準を拡張承認にすることは私も考えました。そうすれば文面も明確な言葉を使えますし。反面、フィルターを非公開のままにするにしても、実質文面から仕様が読み取れてしまうので、仰られている様な弊害を招いてしまいます。ただ、基準を拡張承認にするという事は、実質利用者ページ全部に拡張半保護をかけるのと同じで、拡張半保護突破が殆ど行われていない現状（たまに拡張承認利用者が強引な編集をしてしまうくらい？）ですと、荒らしがそこまでの手間をかけて利用者ページを荒らす事に執着するだろうかとも思います。これは言っても構わないと思いますので言いますが、現状でも利用者本人は対象外となっていますので、これは変える必要はないと思います。
- 通常、利用者ページは本人以外が編集する事はないので、基準を拡張承認にしても良いとは思いますが、現状の仕様でも不正編集を十分防げているので、このままでも良いとも思います。他利用者が利用者ページを編集するので良く見かけるのは、{{Indefblockeduser}}・{{Sockpuppet}}などのテンプレを貼るのがIP・アカウント利用者とも見られ、本フィルター基準以下の利用者は弾かれています。これらの編集を現状より厳しくしてもよいかという疑問もあります。あとは、うろ覚えですが、テンプレかカテゴリの使用方法が不適切で、ウィキ全体に利用者ページがカテゴライズされていて、その利用者に会話ページで断った上で修正編集されていたのを見た記憶があります。これは、この方法が良いと思いますし、これ以外の場合でも他人の利用者ページを編集する必要があるときは、断った上で編集するのが礼儀だと思います。大至急直さねばならない状況はちょっと思い付きません。
- 先述通り、私は仕様変更はどちらでも良いと思っているので、今まで挙げられたメリット・デメリットを考えた上で変更すべきという意見があれば、変更しても良いとは思います。ただ、検討に時間が掛かる様であれば、提案の文面の変更のみを先行して合意を取って実行し、仕様変更は別途継続審議とするのが良いと思います。--えのきだたもつ（会話） 2022年1月24日 (月) 17:04 (UTC)
- コメント 遅くなってしまいすみません。基準を拡張承認することで不必要に制限を増やすことの問題点は納得いきましたので仕様変更＋（実質）公開は外します。名前を変えるなら「編集経験の浅い利用者」か「新規参加者」かだと思います。ウォッチリストなどで利用されている用語でも反対はしないのですが、公開することそのことへのリスクよりは、その用語を用いた場合、仮に今後突破荒らしが出た場合に裁量で基準変更などの対応がしにくくなるのを心配します。--郊外生活（会話） 2022年4月3日 (日) 17:46 (UTC)
- コメント 放置してしまっていてすみません。では、「編集経験の浅い利用者」に変更する事で最終合意を取りたいと思いますので、よろしくお願いします。--えのきだたもつ（会話） 2022年6月20日 (月) 16:46 (UTC)
- 賛成 「編集経験の浅い利用者」に変更問題ありません。よろしくお願いします。--郊外生活（会話） 2022年7月15日 (金) 04:21 (UTC)
#57のCSS除外の追認提案
2022年1月12日 (水) 00:18 (UTC)の編集で、TemplateStylesなどのCSSが「カテゴリを含まないテンプレートの作成」から除外されました。CSSを除外するという仕様変更は2020年6月にも提案されましたが、のちにCategory:テンプレートスタイルの存在が判明したため、提案者により取り下げられています。したがって、自明なバグ修正ではないものとして、追認提案を出します。
フィルターを編集した利用者と2020年6月の議論に参加した利用者に通知を飛ばします（敬称略）：本日晴天、青子守歌
--ネイ（会話） 2022年1月12日 (水) 06:15 (UTC)
- あー・・・すみません。これは私がやらかしですね。。確かに
/* [[Category:テンプレートスタイル|テンプレート名]] */で使えるのですから、誤作動ではありませんでした。というわけで、自分で修正しておいてなんですが、追認には反対（？）で、差し戻しを提案します。--青子守歌（会話/履歴） 2022年1月12日 (水) 07:38 (UTC)
条件付賛成 提案- なるほど、そういう経緯があったんですね。
- ならば、理想的には、エラー時にCategory:テンプレートスタイルに関する説明を表示できると、自己説明的にできたわけですね。現状の仕様で対応可能かは理解してませんが、合わせて検討できると良いかと思います。
- つまり、シンプルな差し戻しのあとにUI改善を提案したいです。--Wint7（会話） 2022年1月12日 (水) 08:42 (UTC)
- UIというのを何を指すかによりますが、通知メッセージはMediaWiki:Abusefilter-warning-カテゴリを含まないテンプレートの作成にあるので、これを編集すれば済みます。これを見るとHelp:カテゴリ#テンプレートのカテゴリ付けへのリンクがありますし、そっちのヘルプページにTemplateStylesへの言及があれば十分なのかもしれませんね。--青子守歌（会話/履歴） 2022年1月12日 (水) 09:08 (UTC)
- 賛成
- 確かに皆が
からすぐに辿ることが期待できますね。テンプレートにカテゴリをつける方法がわからない場合 - それで再発防止策になると思います！--Wint7（会話） 2022年1月14日 (金) 07:05 (UTC)
- UIというのを何を指すかによりますが、通知メッセージはMediaWiki:Abusefilter-warning-カテゴリを含まないテンプレートの作成にあるので、これを編集すれば済みます。これを見るとHelp:カテゴリ#テンプレートのカテゴリ付けへのリンクがありますし、そっちのヘルプページにTemplateStylesへの言及があれば十分なのかもしれませんね。--青子守歌（会話/履歴） 2022年1月12日 (水) 09:08 (UTC)
版番87621958（差分）で、Help:カテゴリ#テンプレートのカテゴリ付けにTemplateStyleのカテゴリ付けについて追記しました。
ということで改めて「編集フィルター#57（変更履歴・一致記録）からCSSを除外している分の除去」（つまり、フィルター#57の第4850版（差分）の差し戻し）を提案します。反対がなければ168時間後ぐらいに実施します。--青子守歌（会話/履歴） 2022年1月21日 (金) 02:53 (UTC)
- 編集フィルターの差し戻しに 賛成 --ネイ（会話） 2022年1月21日 (金) 04:49 (UTC)
ありがとうございます 賛成 --Wint7（会話） 2022年1月21日 (金) 14:58 (UTC)
遅くなりましたが、フィルター#57の第5147版（差分）で差し戻しました（差し戻し結果の確認用リンク）--青子守歌（会話/履歴） 2022年2月16日 (水) 11:59 (UTC)
「条件の上限に達しました」の修正
フィルターの数が多くなったためか、最近「条件の上限に達しました」のタグがつけられる編集が多発しています。どのように修正すればいいのかあまりわかりません（例えば、「追加除去キーワード一致」系LTA対策フィルターを1つにまとめることが考えられるが、改善につながるかがわかりません）が、ひとまず問題を提起します。
直近1か月に編集フィルターを編集したことのある利用者に通知を飛ばします（敬称略）：Nnh、えのきだたもつ、青子守歌
--ネイ（会話） 2022年1月12日 (水) 06:15 (UTC)
- コメント 具体的には実際タグを付けているソフトウェアで実際どう判定しているかによりますが、「条件の上限に達しました」なので、処理される条件の負荷により、一定時間以上処理時間が掛かる場合などに、上限に達したとして途中キャンセルしているものと思われます（Wikipedia:編集フィルター#安全装置）。だとすると、フィルターをまとめても、判定される条件数が変わらなれば負荷は変わらないので、状況は変わらないと思います。また、フィルター編集を行っていて気が付いたのですが、1つのフィルターサイズには上限があるらしく、上限を超えた分は保存されなくなります（保存時にエラーは出ず、再読み込み＆修正したときに、構文エラーが出るのでおかしいな？と思ったら、サイズ上限を超えた分が切れていましたので気が付きました）。余程のサイズまでは大丈夫だとは思いますが、用途別にフィルターが分かれていて、フィルター番号でどのLTA対策なのか分かりやすい事もありますので、まとめる事はあまりしたくはありません。
- やはり、条件文・関数呼び出し・判定項目（キーワード数）など、処理の負荷になっているのを削減するのが一番だとは思いますが、正にアクティブに機能しているフィルターなどは、対策を緩め荒らしを防げなくなる事にも繋がりますので難しいところです。機能を維持しつつ、条件文・関数呼び出し・判定項目（キーワード数）などを見直すのが良いと思います。とりあえずは、1年以上（2021年1月1日以降）発動していないフィルターは無効にしてみました。あと、まだ少しですが見直し修正も行いました。これでどれだけ効果があるか分かりませんが、状況を見守ってください。時間があるときに、引き続き見直し修正も行っていこうと思います。
- あと、気になる点がありまして、フィルター修正での確認テストで時間が掛かるとき（最悪TimeOut）がありますので、実際のフィルターの動作においても、サーバーの全体の負荷により、上限になるときとならないときがあるかとも思います。--えのきだたもつ（会話） 2022年1月12日 (水) 21:04 (UTC)
- 判定キーワードに特定のURLが含まれる場合、MediaWiki:Spam-blacklistで代用できると思います。--ネイ（会話） 2022年1月17日 (月) 10:51 (UTC)
- 報告 少しずつですが見直し修正を進めていった結果、2022-01-25 19:31:11 を最後に「条件の上限に達しました」タグは付かなくなりました。かなりの大物（大幅に関数呼び出しを削減したフィルター）がありましたので、それが大きかったかと思います。編集フィルター管理でも連日「最近のx,xxx操作のうち、0件(0%)が1,000の条件制限に達しました。」と出ています（ここに上限数が1000と出てましたね）ので、おそらく余程の大きな追加がない限りはもう大丈夫だと思います。
- mw:Extension:AbuseFilter/Conditionsにも解説がありますが、例えば「contains_any(user_groups, "user")」は、この条件文以降はIP利用者は処理されないので、この様に実行対象を大きく削減出来る条件文を出来るだけ最初の方に持ってくる事で、実行される条件数を少しでも減らす事が出来ますので、フィルター編集者の方は留意頂けると良いと思います。各フィルターの編集画面で、「最近のx,xxx操作のうち、このフィルターはx件(x%)に対して発動しました。平均して、実行時間はx.xxミリ秒でx件の条件制限を消費しました。」と、そのフィルターの最近の条件制限消費数を見る事が出来ますので、こちらも参考になると思います。--えのきだたもつ（会話） 2022年2月3日 (木) 15:28 (UTC)
#57の一部除外提案
本日 {{Asbox}} を使用してスタブテンプレートを作成したら。このフィルターに引っかかりました。このテンプレートを使用した場合、自動的にCategory:スタブテンプレートに入るため、#57のチェックを外していただけるなとありがたいです。
フィルターの条件作成のルールがわかっていないのでできないようなら取り下げます。--PuzzleBachelor（会話） 2022年4月24日 (日) 07:51 (UTC)
- コメント 非公開フィルターでないのでご覧頂けると思いますが、最後の条件「カテゴリを付与するテンプレを使った場合を除外」としているテンプレート群に{{Asbox}}を追加すれば対象外には出来ます（テスト済）。個人的にはそれで問題ないと思いますが、念の為他の方々にも確認して頂き、反対がなければ修正したいと思います。--えのきだたもつ（会話） 2022年4月24日 (日) 08:41 (UTC)
- 取り下げ 「他の方の意見」が全くつかないので取り下げます。少なくとも現在テンプレート新規作成の提案はなく、早急に改善が必要な案件でもないでしょう。--PuzzleBachelor（会話） 2022年6月25日 (土) 10:44 (UTC)
#12 の一部除外依頼
Wikipedia‐ノート:管理者伝言板/保護ページ編集#Please allow staff to edit user script pages に、User:Jon (WMF) さんらから「#12 新規利用者による他利用者ページの編集」への要望が寄せられているので転記します。
- Please allow staff to edit user script pages
- Hi there! Apologies for writing in English. There is a popular gadget running in a user page e.g. User:<username>/<scriptname>.js
- Its reporting various errors in error logs at a problematic level. I tried to make a fix and hit an AbuseFilter warning (他の利用者の利用者ページの編集は許可されていません！). This filter was triggered because you tried editing other user's userpage..
- Could this filter be modified to allow edits to titles with ".js" in them or to users with "(WMF)" in their username, as being able to edit these in these kind of situations is essential.
- Thanks in advance!--Jon (WMF)（会話） 2022年6月15日 (水) 17:35 (UTC)
- @ネイ, could you please take a look? Would you be able to fix that yourself of ask someone else who could modify the filter? Thank you in advance!--SGrabarczuk (WMF)（会話） 2022年6月16日 (木) 00:29 (UTC)
以上。--Kurihaya（会話） 2022年6月16日 (木) 01:07 (UTC)
- 賛成 .js、.cssのように他利用者利用者サブページの編集自体にインターフェース管理者権限が必要な場合であれば#12から除外しても問題ないと思います。財団職員でない人が成りすましで(WMF)を入れたとしても権限申請を通過できない（あるいは権限付与後だとしても利用者名変更が認められない）でしょうから、成りすまし荒らし対策もできると思います。あとは、本件に限らず一般化できるように代案を挙げておくと、別途合意形成が必要そうですが、拡張承認利用者は#12の対象外にし、他言語版・他プロジェクトで実績のある人、財団職員などは必要に応じて拡張承認で対応するというのもあると思います。--郊外生活（会話） 2022年6月16日 (木) 01:38 (UTC)
- コメント .jsや.cssページに限らず、グローバルインターフェース管理者を除外して対応するのでも問題ありません。--郊外生活（会話） 2022年6月16日 (木) 20:02 (UTC)
- コメント グローバルインターフェース編集者権限（やスタッフ）を除外対象にすることが望ましいと考えます。スチュワードなどのグローバルな利用者ページ編集を行うユーザーは既に除外対象になっています。--Marine-Bluetalk✾contribs✾mail 2022年6月16日 (木) 17:25 (UTC)
- コメント 私も同じく、権限グループで制御すべきだと思います。今回の場合は特に.js/.cssという特殊なページですから、編集する（できる）人が最初から限られていますし、フィルター作成時にはなかった仕様で[[編集できるようになった人たち（特別:グローバル利用者/global-interface-editor）が増えたということで、本来の仕様に合わせるのが正しい解決方法だと思います。割と自明な解決方法ですし、どちらかというとWP:EF/FPで対応すべきような範囲でもあると思うので、特に反対ないければ24時間後ぐらいには修正します。--青子守歌（会話/履歴） 2022年6月16日 (木) 19:53 (UTC)
反対もなかったので、予告通りフィルター#12の第6004版（差分）でglobal-interface-editorを適用除外に入れました。--青子守歌（会話/履歴） 2022年6月18日 (土) 02:48 (UTC)
- Thank you! ありがとうございます--Jon (WMF)（会話） 2022年6月23日 (木) 15:41 (UTC)
#12 の一部除外提案 20220621
上の節の内容と一部重複しますが、フィルター12からbotを除外できないでしょうか。botの利用者グループは 制限されたページを編集 (extendedconfirmed) の利用者権限を持っていますが、稼働仕立てのbotは新しく作ったアカウントのことが多く、利用者名前空間にあるページは、サブページも含めてフィルターに弾かれる関係で現状編集できません。ご一考いただけますと幸いです。--Dragoniez (talk) 2022年6月20日 (月) 18:56 (UTC)
- フラグ付きボットはビューロクラットやその他の利用者が編集内容を事前にチェックしており、速度などの問題があったとしても編集内容自体は問題ないだろうと考えたここと、拡張承認をいちいち申請させるのが面倒だろうということで提案に盛り込んだ記憶があります。
- ここ半年程度でフィルター12に引っかかっていたフラグ付きボットはDragoBotのみでしたが、ボットを拡張承認にした経緯を考慮すると除外対象に加えても問題ないのかなという気はします。--Marine-Bluetalk✾contribs✾mail 2022年6月21日 (火) 15:38 (UTC)
ログ
- Wikipedia:編集フィルター/一覧 - 正式運用中のフィルターの一覧と議論の過去ログ
- Wikipedia:編集フィルター/提案/ログ - 正式運用に至らなかったフィルターの議論の過去ログ