2024年に発生しているメンションを主に行うスパムに対する課題点の整理・対策について (Organizing and addressing problems and solutions to spam that are occurring in 2024)

[tai-cha]

#14888 からのトピック分離

スパムによる無差別メンション受信、送信

#14888 (comment)

に関する現状の課題点の整理や解決策に関する議論はここで（とりあえずの場所建てです）

[eternal-flame-AD]

I have been discussing this on and off over my own misskey that I wish to summarize here, all are automated controls that do not involve additional manual vetting:

(0) I hope there can be some kind of pluggable dynamic filtering (like the infrastructure of Milter) in whether to allow a post or not (inbound or outbound), it can be completely plug-gable like requesting an API before actually creating a resource, but it is very useful if instance owners want to design their own defenses without having to couple tightly to misskey code. This also reduces maintenance overhead of the main functionality because spam control can be adapted without changing the codebase or requiring any action from misskey-dev. Effective solutions developed by instance owners can be shared unofficially by misskey-dev as well in a "contrib" repo. I have developed one but I have not figured out how to elegantly get contextual information that is only retrievable from within Misskey, but it has been helpful in other things like filtering out activities that are likely to cause other performance issues, and auditing messages from other instances for later analysis when issues were identified. https://forge.yumechi.jp/yume/fedivet
(1) I thought of a metric of 'orphan mentions' which is the number of mentions that are not present in the thread it was replying to (if any). There are many genuinely heated discussions that grow and involve multiple users, and because of this many instance owners might be hesitant to set a low maximum mention limit leading to a sub-optimal effectiveness. I think this should somehow be part of the role system but have not figured out how yet.
(2) A more engineered approach is to actually do some statistics or even machine learning on the sending instances, optionally cross referencing historical data stored in the database and/or Fediverse Observer and identify abnormal patterns such as increase in posting frequency, increase in number of users, etc.
(3) I personally do not think simply disabling direct messages from users who do not have local followers is an effective solution, because this (1) only works for large instances (2) can lead to frustrations because the sender might have a genuine matter and believed their message to be delivered when it was not (3) can be easily bypassed if they have bots like Ai which you can just tell them to follow you and now you have a local follower.

私は自分の misskey で非公式にこれについて話し合ってきましたが、ここでまとめたいと思います。すべては追加の手動審査を必要としない自動化された制御です:

(0) 投稿を許可するかどうか (受信または送信) に関して、何らかのプラグイン可能な動的フィルタリング (Milter のインフラストラクチャのような) があることを願っています。これは、実際にリソースを作成する前に API を要求するなど、完全にプラグイン可能なものですが、インスタンス所有者が misskey コードに密接に結合することなく独自の防御を設計したい場合に非常に便利です。これにより、スパム制御をコードベースを変更したり、misskey-dev からのアクションを必要とせずに適応できるため、メイン機能のメンテナンス オーバーヘッドも削減されます。インスタンス所有者が開発した効果的なソリューションは、misskey-dev によって「contrib」リポジトリで非公式に共有することもできます。私は 1 つ開発しましたが、Misskey 内からのみ取得可能なコンテキスト情報をエレガントに取得する方法がわかりません。ただし、他のパフォーマンスの問題を引き起こす可能性のあるアクティビティをフィルタリングしたり、問題が特定されたときに後で分析するために他のインスタンスからのメッセージを監査したりするなど、他のことに役立っています。https://forge.yumechi.jp/yume/fedivet
(1) 私は「孤立したメンション」という指標を考えました。これは、返信先のスレッド (存在する場合) に存在しないメンションの数です。本当に白熱した議論は数多くあり、複数のユーザーが関与して拡大するため、多くのインスタンス所有者は、最大メンション制限を低く設定することをためらう可能性があり、その結果、最適ではない効果につながります。これは何らかの形でロール システムの一部になるべきだと思いますが、まだ方法がわかりません。
(2) よりエンジニアリングされたアプローチは、送信インスタンスに対して実際に統計や機械学習を実行し、オプションでデータベースや Fediverse Observer に保存されている履歴データを相互参照して、投稿頻度の増加、ユーザー数の増加などの異常なパターンを特定することです。
(3) 個人的には、ローカルフォロワーを持たないユーザーからのダイレクトメッセージを無効にするだけでは効果的な解決策ではないと思います。これは (1) 大規模なインスタンスにしか機能しない (2) 送信者が本気でメッセージを送っていて、実際には届いていないのに届いたと信じてしまう可能性があるため、フラストレーションが生じる可能性がある (3) Ai のようなボットがあれば簡単に回避できるため、フォローするように指示するだけでローカルフォロワーを獲得できます。