分散型SNSとスパムとkmyblue
あすかです。
※この記事にはマウント取りが含まれますので読まないほうがいいです
顛末
さて、みなさんご存知かもしれませんが、２０２４年２月に分散型SNSを荒らしが襲ったという事件がありました。
あすかが把握している範囲では、まず２月上旬ころに、詳しい経緯は知りませんがMisskeyのサポートフォーラムが荒らされて殺害予告が書き込まれたという。それが記憶にある限り一番古い情報です。
その時に村上さんがサポートチャットボットに『サポートフォーラムが荒らされている』という項目を追加したの覚えてる人いるかもしれません。
その次に、誰もいない、放置されたMisskeyインスタンスに大量登録がありまして、そこからMisskeyを中心としたいろいろなサーバーへスパムメンションがとびました。
当時の被害はMisskeyが中心でしたが、これからすぐたって、Mastodonにも迷惑なメンションがとんでくるようになりました。そこから先はみなさんご存知のとおりです。（雑）
Mastodonにおけるスパムの手口
MastodonやMisskeyって、誰でも手軽にサーバー建てられるんですけど、所詮個人サイトです。昔あちこちにあった掲示板と基本的には変わらないです。つまり、個人サイトなので放置されることもあるわけです。放置された掲示板にはスパムがわくっていいますけども、まさにそのとおりです。人類はなぜ学ばないのか。
具体的に何をしたかというと、そのサーバーに大量にアカウントを作って、そこからあちこちのアカウントにメンションをとばしまくります。
アカウント一覧はおそらく、適当な大手サーバーに登録してそこの連合タイムラインを読んでいるんじゃないかと思います。そこで得られたアカウント一覧を使って、あちこちの放置サーバーのアカウントを動かしてメンションをとばしまくります。
スパムによる投稿って大体いくつかのパターンがありまして、自分が把握しているのは大体これでした。
１つの投稿にメンションを１０個＋引用（初期に多い）
１つの投稿にメンションを５個＋画像１枚
１つの投稿にメンションを５個＋リンク１つ
１つの投稿にメンションを５個＋ハッシュタグ１つ
１つの投稿にメンションを２個＋画像１枚（一時期）
こんにゃくで尻を叩くメンション１個（レア）
韓国語でメンション（一時期）
これまでのスパムと決定的に異なる特徴
これまでにも確かにスパムはありましたが、その手口は大体決まっていまして、
mastodon.socialのような人の多いサーバーにアカウントを大量に作って、そこから各所に約１０個のメンション＋リンクをダイレクトメッセージで送りつける
pawoo.netに法律上危険な投稿を大量に行うbotを作って、それを分散型SNS上のあちこちのサーバーに新しくアカウント作ってそこからフォローすることでbotの投稿をそれぞれの連合タイムラインに流す。pawoo.netは危険だからドメインブロックするよう各サーバーの管理者に迫る
この手口の共通点としては、どちらもたった１つのサーバーをドメインブロックまたは制限することで（スパムへの勝ち負けは別として）対応は可能という点です。たった１つで済むから楽なんですよね。
今回は、相手が大量のサーバーから直接メンションを大量に送ってくるんです。ドメブロ１つで済んでたのが、１００個にも２００個にもなっちゃう。従来のやり方ですと、ブロックしなければいけないドメインが大量に生まれますし、逐次追加されていきます。
しかも、もともと誰かが建てていた健全なサーバーをスパムが乗っ取っていたわけでして、もともとの住民に配慮するためにスパム対策が終わったサーバーはドメブロを解除するのが良心的な対応ですけど、それが出来ているかあちこちのサーバーをいちいち巡回して解除する人も何人かいました。
これでドメインブロックに限界を感じた人も大量にいらっしゃるんじゃないかと思います。
各所の状況と対策
共通
Misskey・Mastodonのほとんどのサーバーで、登録時CAPTCHA認証追加／承認制移行といった対応がとられていました。特にMisskeyではCloudflare・hCaptchaと２種類の認証に対応していたことから、両方を採用するサーバーも散見されました。
ただ、今回のスパムは連合から来るものであって、自分のサーバーの登録を止めたところで意味はないです。これはあくまで『自分とこはスパムおらんからドメブロしないでくれ』っていうメッセージです。
肝心のスパム対策としては、当初は数えられるほどのサーバーからしかスパムが発せられていなかったこともありほとんどのサーバーは当初はドメインブロックでなんとかしようとしてて、対象となるドメイン一覧も積極的に共有されていました。ですがサーバーが増えるにつれてドメインブロックでは不十分という認識が支配的になり、NGワード／自動凍結ツールなどの開発が進んでいったようです。
標準Misskey：禁止ワード
Misskeyの動きはたいへん早かったです。今回のスパムを受けて、禁止ワード機能を追加したバージョン2024.2.0を２月１７日にリリースしました。これがMisskey本家の正式リリースですから、あちこちのサーバーに取り込まれて、禁止ワードの対応が容易になったのではないかと思います。
にじみす：ホワイトリスト
一方、にじみすの初期対応も早く、２月１７日にはホワイトリスト制に移行しました。ここでmisskey.ioやfedibird.comなど複数のドメインを登録し、利用者の声に合わせてドメインを次々と追加しました。
にじみす以外にもホワイトリストを導入したサーバーが複数あったようです。
misskey.io：なんか頑張ってた
misskey.ioの対応について追いきれていない部分もありますがこちらから把握できたのは大きく分けて２つ。
モデレーターが頑張っていたらしい＋Tor禁止など一般的な対策
misskey.ioのフォロワーを持たないリモートアカウントからのリプライを全てブロック
特に２つ目は、後で詳しく紹介しますけど、大手サーバーならではの賢い対応ではないかと思います。
標準Mastodon：ひたすら通報を処理しまくってた
標準のMastodonはリリースサイクルがMisskeyほど短くなく、搭載されている機能もスパムに対しては脆弱です。
一応、Mastodonには『ワードミュート』『フォロワー以外からの通知を受け取らない』というユーザー設定が存在します。ユーザーレベルでしのげますが、管理者ができることは実は多くありません。
思いつくだけでも、自分のサーバーの登録を審査制にすること、ドメブロすること、地道に通報を受け取って凍結すること、この３つだけです。Cloudflareなどの外部ツールを利用して機能を追加することも一応はできますし、やった人もいました。
mastodon-japan.netの管理サイドは、大量の通報を受け取ってリモートアカウントを凍結していたようです。少なくとも４桁はあったと思います。
なお標準Mastodonの最新の開発版では、『管理者やモデレーターが一定期間ログインしなかったら登録を自動的に承認制にする』という変更が入ってまして、これはバージョン4.3.0に搭載されると思います4.2.8で緊急リリースが入りました。思ったよりめちゃくちゃ早かった。
FediverseってなにもMastodonだけではないので、これをやったところで絶対的に安全というわけではありませんが、今回のスパムの手口を考えると大変画期的で、自分のサーバーのドメインブロックを回避できるものでもあります（なお仕事しない管理者やモデレーターが出たらｒｙ）。
標準Mastodonのパッチ
というわけで標準のMastodonでできることが少なすぎるため、Fedibird管理者ののえるさんが、標準Mastodon（v4.2.7）でNGワード機能が使えるようにしたパッチを公開しまして、取り込んだサーバーも複数あったようです。
他にも、特定の条件を満たした投稿を受け取らないパッチというのも作られまして、こちらはHostdonに取り込まれて多くの人の助けになったようです。
Fedibird：なんか頑張ってた＋NGワード
当のFedibirdも、モデレーターは大変だったようで、詳細は伏せますけども、ここに書ける範囲では、今回のスパムよりも前から『フォローしていない新規ユーザーからの通知／ダイレクトメッセージをブロック』というユーザー向け設定項目が存在しました。それを設定するよう案内がありました。
これは作成してから３日間（のちに７日間）のアカウントから来たメンションをブロックすることができます。
モデレーターもなんとか頑張って大量の通報に対応していたようです。
またFedibirdには、今回の騒動以前からNGワード機能（Misskeyの禁止ワードとおそらく同一）があるようで、それも活用しているようです。
kmyblue：なんか頑張ってた＋NGワード＋ホワイトリスト
kmyblueも、自分のことですからどうしても他の場所と比べて書ける分量に差ができてしまうので、ここでは簡潔な内容にとどめますけども、今回の騒動以前からNGワード機能を実装してまして、それを使って対応していました。
ただNGワードだけでは対応が不十分な条件が出てきたため、最終的にはホワイトリスト（みんなが考えてるのとは多分違う。詳細は後述）を作って対応してました。
スパムと連合
繰り返しますが、今回のスパムの特徴は、大量のサーバーにアカウントを作成したという点にあります。この時点でドメインブロックは事実上無効化されます。
どんなに強力な機能を作っても、結局設定するのは人間なので、個人サーバーの管理者が２４時間張り付いて管理できるわけでもないですし、１００を超えるドメインをいちいちブロックした上で解除してもいいタイミングを知るためにいちいち巡回してっての、限界があると思います。
ここで、分散型SNSにおけるスパムの特異性について書いてみます。
掲示板におけるスパムとの違い
上の方で、MastodonやMisskeyの各サーバーは掲示板のようなものみたいなこと書いたと思うんですが、それぞれの掲示板とは決定的な違いがあります。
自分が普段使っている掲示板にスパムが大量に溢れて管理者不在で対応できないってなったら、みなさんいったん他の掲示板に逃げるってやると思います。
でも分散型SNSでそれは成立しないです。なぜなら連合するからです。掲示板同士が繋がっているようなもので、全く別の掲示板から直接連絡することができてしまうようなものです。
もともとがFediverseという１つの大きなネットワークですから、どこにいても繋がれるっていうことは、どこにいてもスパムと繋がれるということです。
スパムのいるサーバーをドメインブロックするということ
で、今回、スパム専用のサーバーが立ち上がったわけではないということは強調します。どこにでもある、５人１０人おはぎ人が使うような、趣味や日常をただ書き連ねるだけのサーバー。そこがスパムに汚染されているわけです。なのでそのサーバーをドメインブロックするってことは、そのサーバーにもとからいる人達も一緒にうちから排除しますよと。つまりスパムのためとはいえ、ひとつのサーバーを排除することに変わりはないです。
なので、ドメインブロックしたサーバーを後から解除するために巡回しちゃう人が出てくるのです。管理が厳しくないだけで、基本は自分たちと同じようなサーバーですから、自分と同じものをブロックしたくないんです、本当は。それが当たり前になってしまうと、今度は自分たちが排除されかねない。自分のことだと思ってるんだと思います。
スパムに対して管理者が連合を制限する（ホワイトリストを使用する）ということ
前の節とも深く繋がる話ですけど、分散型SNSっていろんな規模があります。４０万人もいるサーバーもあれば、１０人、５人しかいないサーバーもあります。
今回のスパム対策でドメイン単位のホワイトリストを導入したサーバーあるようですけど、４０万人いるところはともかく、１０人とかそういう小さいサーバーは間違いなく排除されます。調べれば分かりますけど、Fediverseでユーザー数４桁以上のサーバーって実は全体の３～４％くらいしかないんです。ほかは全部３桁以下のサーバーです。この事実はもっと広く知られて欲しい。
で、例えば１０００人以上いるサーバーをホワイトリストに登録しますよってことは、９６％のサーバーを全部切り捨てるということですね。
Fediverseは自由に、どんな人でも参入を歓迎されるべき空間だと思いますけど、ホワイトリストで小さいサーバーたちを排除しちゃうと、Fediverse全体が敷居の高い空間になるんですよね。エンタメの業界でもよく言われますけど、良作は駄作がないと生まれないんですよ、駄作がたくさんあるってことはそれだけ参入しやすくて、才能ある人も気軽に参加できてしまうからそこから名作が生まれる。サーバーも同じで、人が何万人何十万人いるサーバーも、最初は１０人～１００人程度の小さいサーバーから始まってるんです。Misskeyというソフトウェア自体も、去年一気に有名になるまではただの泡沫でした。スパム対策強くしすぎてそういうの排除しちゃうと、今後素晴らしいサーバーは生まれなくなるかもしれない。そのことは念頭に置いてほしいです。
Fediverse全体を一つの巨大なSNSとみなすならば、ドメイン単位で制限することがそもそもの間違いかもしれません。Fediverseの意義が問われるということになります。
ただ、ホワイトリスト化もどうしても必要な場合はあります。偉そうなこと書いてしまいましたけど、これは所詮きれいごとです。管理者にもモデレーターにも生活がありますし、無料でやってるんですからリソースもありません。連合先を制限するのも、サーバーや実装によっては仕方ないと思いますし、実際うちのサーバーもホワイトリストを導入してます。
ホワイトリスト作る時は連合とのトレードオフってことは常に意識して、覚悟を持って決めていきたいなってのはあります。
スパムに対して各ユーザーが自衛するということ
標準Mastodonに用意されたユーザーによる自衛手段は主にこの２つです。
フィルター（ワードミュート）
フォローしてるユーザー以外からの通知をブロック
Fedibirdみたいに他の自衛手段が用意されているサーバーもありますけど、基本的にはこの２つです。フィルターによって、特定の文字列が含まれるメンションを通知から隠せます。
これはいいんですけど、思いつく限りで２つ問題があります。
１つは、そんな設定に手間がかかるってこと。ユーザーといってもまちまちで、ソシャゲのデイリーミッションの要領で１日１分しかログインしない人もいます。いくらこういう設定がありますよって管理者やみんなが一生懸命に告知していても、それを読まないで、スパム増えたまぢ無理やめょ。。。っていう人必ず出ます。
ユーザー全員に同じ設定をさせるってやっぱり無理がありますから、結局管理者が何とかしないとって思考に行っちゃいます。
１つは、通知を自分の関係者に限定することで、自分と繋がっていない人といつまでたっても繋がれなくなってしまうことです。
当然、自分のフォローしていない相手からフォローされたときにも通知は来ませんから。フォロバするってことができなくなっちゃう。すると、その人からメンションが来ても通知来ないから完全無視するしかないです。フォロワーの通知だけ受け取る設定にしちゃったら、今度はフォロースパム来ますから。
そうやって、既存のネットワークでしか繋がれなくなってしまう、相手と話したければたまたま相手と相互になるのを待つしかない。繋がりにくくなっちゃうんです。
スパムと繋がりにくさはトレードオフ
これあすかの持論なんですけど、今後のFediverseはスパムを前提に設計すべきだと思っています。今回の騒動が１０年に１回の規模だとか書いてる人見ましたけど、厳しいこと言いますけどもね、その程度の認識じゃやっていけないと思います。
なぜならFediverseって自由だから。誰でも個人でもおはぎでも参入できるオープンな場所です。Fediverseという巨大なネットワークの中に、自分のサーバーも入ることができます。
ただね、前の節で多くの人が感じたかもしれませんけど、スパムに対策するってことは、それ以外の正常な投稿も受け取れなくなります。リスクが上がるじゃないです、できなくなります。
例えば今回の件でうち、メンション数制限を設けて、制限を超えたメンション数を持った投稿はリジェクト、うちのサーバーの人には届きませんってのやったんですけど、例えばあちこちのサーバー管理者に注意喚起する意味で回覧板のようにたくさんメンションつけて送りまわる人がいても、こっちには来ないです。
スパムを切り捨てるのと同時に、正常な投稿も消えます。スパム１００％じゃないです。大体８～９０％くらい。この割合をいかに上げるかが落としどころだというふうに思ってます。
もう１つ問題ありますけど、分散型SNSですよね、あちこちのサーバーで管理者違いますよね。スパム対策もまちまちです。
これがTwitterだったら、運営が最近こういう制限をかけたらしいっていう話が１つ回ればスパムじゃない人は対策できる、それでいいんですけど、分散型SNSはあちこちで対策が違いますから、自分のサーバー内ではOKでも相手のサーバーには届かなくなる、そういう状況は発生します。
スパムに対するkmyblueの対応
と、上の方でめちゃくちゃ偉そうなこと書いてしまいましたけど、kmyblueも既存の機能ではスパム対策が不十分でしたから、スパムの変化に対していろいろ機能足していきました。その経緯を簡単に書いてみます。
あくまでkmyblueの宣伝ではなく、知見としてです。このスパム対策機能だけを口実にkmyblueを使ってほしくないし、みんな、それぞれ自分の使いたいソフトウェアを使ってほしい、欲しい機能があればそれぞれのソフトウェアの開発元に要望してほしいです。これは分散型SNSのスパム対策の一例として参考になれば幸いです。
kmyblueの従来の考え方
はっきり言って、今回のようなスパムは必ず出るし、むしろ出るのが遅すぎると思ってました。これ言うとあれなんですけど、これまで海外で出ていたスパムは正直、ちょっと手加減しすぎではないかと思ってました。mastodon.socialのような巨大サーバーにしがみついてるから、その単一のサーバーがスパム対策したら終わりです。
むしろあすかが元々想定していたのは、今回のような『分散型スパム』です。個人のSNSなんてどうやっても脆弱ですから、そこを突くのは簡単です。Twitterより簡単です。素人でもできます。それが既存のドメインブロック機能だけでは対応不可能なことも、あらかじめ想定していました。
で、具体的にどういう対策を事前にやっていたかというと、今年１月にリリースしたkmyblueフォークバージョン10.0の時点では、以下の設定項目がありました。
NGワード（正規表現OK）
NGワード（正規表現OK）（フォローしていない相手からのメンションにのみ適用）
フォローしていないアカウントへのメンションのNGワードを、ローカルユーザーによる投稿にも適用する
投稿に設定可能なハッシュタグの最大数
ログインしていない状態でローカルユーザーの投稿をタイムラインから取得できないようにする
簡単に言うと、NGワード・ハッシュタグ最大数が主でした。一番下の設定なんかは標準Mastodonにも似たような設定ありますけど、連合タイムラインが見れるかでも大体違ってくると思って入れましたけどいらんかも。
kmyblueの想定外
kmyblueにも想定外はありました。そもそもこれで何を想定していたかと言うと、mastodon.socialのようなMastodonで商品宣伝を目的とした『分散型スパム』が発生した場合、になります。今回のスパムは、確かに『分散型スパム』ではありましたが、最初はMisskeyのほうで発生してました。この時点で想定とずれています。
まず、MisskeyはMastodonと違って『引用ができる』『タグ文化が定着していない利用者層を中心に展開している』という特徴があります。
例えば上の設定項目、フォローしていない相手からメンションされた時限定のNGワードありますけど、引用は対象外です。ハッシュタグの上限ももちろん使い物になりません。
なので、スパムが主軸をMastodonに移すまでは、通常のNGワードでちまちまやっていくしかありませんでした。
そもそも分散型SNSといえば今はMastodonですから、それよりも人口の少ないMisskeyで先に発生するのは想定外でした。いやこう、結果論込みでいいのなら、去年の７月にmisskey.ioがDDoS攻撃を受けていた時点で察しろ、になりますけど。
kmyblueの初期対応
２月にスパムが発生した時点で、Misskeyや標準Mastodonがドメインブロックで慌てる中で、kmyblueはもともとNGワード機能を搭載してましたからそれで粛々とやっていました。スパムが引用を使っていたのは痛かったですが、なんとか共通の言葉を見つけて、それでやってました。
その中でも、メンション限定NGワードを引用（参照）にも適用する変更はしっかりやってました。
今回のスパム騒動を受けて最初に新設した設定項目の１つが、kmyblueフォークの管理者から提案を受けて作ったメンション数制限でした（本当はもうちょっと複雑な条件がありますがここでは伏せます）。
これはスパムが、定型文使うのをやめて、ただメンションだけで本文空っぽの投稿を連発するようになる直前に実装したものです。なので確かにNGワードは貫通しましたが、この設定のおかげでこちらへの被害はゼロでした。（なお提案した当のフォーク管理者は最新の開発版を使ってるわけではないのでこの機能が使えるわけではなかったというのは補足します）
ただその数時間後に、スパムがメンション２つだけの投稿を連発するようになりましたので、既存の対策では無理だと判断して、やむを得ずホワイトリストを導入することにしました。
kmyblueのホワイトリストの特徴
上にも書きましたけど、分散型SNSでホワイトリストはできるだけやりたくないです。自分にとってホワイトリストとは敗北なので。なので少しでも抵抗する意味で、ホワイトリストと言いながら、ちょっと違うものを実装しました。
まず設定項目の名前がホワイトリストではありません。正確な設定項目は『リモートの新規アカウントを保留する』です。
うちが相手からの投稿（メンション付き含む）を受け取る時、まず相手のアカウント情報を取りに行きます。誰の投稿か分からないと保存できませんからね。で、今回の設定は、それが自分のサーバーにもともとないアカウントだった場合の処理を遮断します。
これによって自分は新しいリモートアカウントを認識できなくなります。なので当然その投稿も受け取りません。
単純なホワイトリストですと、自分のサーバーの利用者がそれぞれのフォロワーと繋がれなくなる恐れがあります。misskey.ioやnijimiss.moeなどの有名所ならいいんですけど、零細サーバーからフォローされている人もたくさんいます。普通のホワイトリストにその零細なサーバーを全部追加しようとすると個人じゃ無理ですので、管理者が合理的に行動する限り、それらは振り落とされます。人の少ないサーバーの排除になります。それはできる限りやりたくなかったんですよね。
なので、まず『自分のサーバーがこれまでに認識したリモートアカウントは全ていったん信頼する』という前提を作りました。
その中には当然スパムアカウントも混在するわけですが、これ以上リモートアカウントを増やさない限り、通報してもらえればスパムアカウントは減る一方です。増えることはありません。新規の流入を止めることで時間稼ぎをしているんです。
普通のホワイトリストと違って、設定したところでスパムがいきなり減るわけではないというのはデメリット、かつ技術に詳しくない利用者やモデレーターにとってわかりにくいところだと思ってましたが、案外皆さん、技術的な詳細はともかく理解してくれたようで大変助かってます。
でも、分散型SNSですから、他のサーバーでは新しいアカウントがどんどん作られていきます。misskey.ioのようなモデレーションがちゃんとしているサーバーの新規アカウントも排除することになってしまいますので、『このサーバーで新規に作られたアカウントは無条件で信頼する』という前提も作りました。これが実質的なホワイトリストのようなものとして機能します。
でもでも、やっぱり問題は２つ残っています。
１つは、分散型SNSですから、５人しかいないサーバーに新しく人が増えることもありますし、サーバー自体が新しくできる場合もあります。上にも書いた通り、ホワイトリストにそういう小さいサーバーをいちいち書いていくのは不可能なので、それをどうするかという話です。
１つは、このホワイトリストのやめ時が分からないということです。ホワイトリストはちゃんと運用している限り安全で、スパムを防げる確率が大幅に上がります。だから、自分の知らない間にスパムが消えても、それが自分とこだと分からない。ずっとホワイトリスト設定したままになって、他のサーバーがうちと連合できなくなるんじゃないかという懸念です。
そこで作ったのが、リモートアカウントの審査。このホワイトリストに引っかかって作成をブロックされたアカウントは、いったんサスペンド状態になります。そのサスペンド状態になったアカウントの一覧というのを別途作りまして、これは承認する・しないを選択できるようにしました。
もちろんリモートアカウントって大量にありますから、いちいち承認するのは面倒。信頼できるドメインはその場でホワイトリストに追加できるようなボタンも作りました。
なので、この機能はアカウントに対するホワイトリストであり、ドメイン（サーバー）に対するホワイトリストでもあり、両方の役割を兼ね備えています。
この承認制度によって、小さいサーバーのアカウントも（時間差ができるとはいえ）うちと連合できるようになりますし、ここにあがるスパムアカウントが減ったらそれがホワイトリストのやめ時になります。
未承認のリモートアカウントから来たActivityは原則ブロックされますが、現在（kmyblueバージョン11.1時点）ではフォローリクエストは保存され、承認時に発動します。これとは別に、メンションもuriだけ保存できるようにする予定もあります。これももちろん、アカウント承認時に初めて連合タイムラインや通知に入ります。
もっとも、この複雑な構造がこの機能の説明をたいへん難しくしています。他のサーバーの方でこの仕組みを評価されている方も散見されましたが、この方法が広まるのはハードルが高いんじゃないかと思ってます。
そもそもこの機能は普通のホワイトリストと何が違うのか？それを理解するために、まず分散型SNSのアカウント認識の仕組みを理解しなくちゃいけない。そこまで知ってる人は少ないでしょうから、要するに、知識と理解のハードルが大変高いです。
うちは対外的にはホワイトリストと言ってますけど、もうちょっと正確に言うなら『承認機能付きホワイトリスト』。
ホワイトリストという言葉が独り歩きしても今は仕方ないと思いますが、なんだろうこう、説明するのって難しいですね。
ホワイトリストの欠点と現在開発中の機能（現在進行中）
という感じで、自分がスパムのメンションが２つになったのを見て即席で思いついたにしてはなかなかいい線を行っているかもしれませんが、ホワイトリストにも欠点があります。
１つは、承認制にしてしまったことです。もちろん承認制にしないことのほうがデメリットが大きいですが、承認制にしたことで今度は、大量のリモートアカウントを承認する作業というのが発生しました。これがとても大変。だいたい世の中にアカウントいくつあると思っているんですかと。
実際にやってみれば想像ほど大変でないことは分かります。リストからそれっぽいのを選んでOKすればいいだけの話です。でも毎日やることが増えます。これをずっとやるのはだるいです。
kmy.blueのような規模ならできますが、Fedibirdやmisskey.ioのような大手がこれをやるのは大変難しいんじゃないかというふうに思ってます。
１つは、承認作業が手動であることです。どうしても人の目が入りますから、間違いは必ず出ます。スパムを間違って通すのは、受け取った人が通報すれば済む話ではありますが、正常なアカウントを間違ってブロックしちゃったら、自分が気づかない限り気づきません。（一応システム的には後から凍結解除できます）
あと欠点には数えませんがもう１つ、ホワイトリストって（人的ミスさえなければ）利用者にとっては究極的に安全な制度です。なので、ホワイトリストをやめると同時にスパムがまた来て、これまでスパムのない環境にいた繊細な人たちがこれに反応して不快になるってこともあるかもしれません。それを思うとなかなかやめられないっていう管理者もいらっしゃるかもしれない。一種の依存です。
ある程度は自由とのトレードオフだと思って、やめる時は思い切ってやめるしかないんだと思います。
やっぱり強力な機能は強力な分、欠点も大きいです。なので、ホワイトリスト以外にもスパム対策機能を現在開発中です。ことの性質上新機能の詳細は控えますが、実際にうちのサーバーに配置して使ってみたところ、効果は確かにありますが設定が大変面倒そうという感想を持ちました。おそらくもっといいスパム対策機能が他にあるかもしれませんし、これ以上はサーバーが自分で実装すべき範囲を超えている（外部ツールでなんとかすべき）ところまできているかもしれません。
スパム対策機能を作る時の考え方
検閲であることを常に意識する
本家Mastodonでも言われてますけど、強力なスパム対策機能は、同時に強力な検閲機能でもあります。政治的に間違っている投稿とか、管理者の思想にあわない投稿とか、そういうのを自由にブロックできてしまいます。なので利用者は自由に他の人と交流できない。大体昔のソ連と同じようなもんです。
なので、強力なスパム対策機能がどれだけ効果を発揮するかは、管理者がどれだけ信頼できる人であるかというところにも大きく依存するでしょう。
もちろん従来のMastodonでもドメインブロック機能が存在し、それがすでに検閲として機能するという意見もあります。サーバーごとにルールがあって、モデレーターを使ってルール違反の投稿を処分するのも、言い換えれば検閲の一種です。これは定量化できない程度の問題かもしれません。
本家Mastodonで、スパム対策機能の設定（例えばドメインブロックのリスト）をサーバー間で共有する機能についての提案もありましたが、これはあすか反対です。
仮にスパムをブロックするドメインブロックリストを誰かが作って共有したとして、その中にこっそり、単に自分と政治的に意見の異なる普通のサーバーを足してしまうとします。ドメインブロックのちゃんとしたメンテナンスをしない限りそのことに気づく人は多くありません。
日本人の場合、pawoo.netとかの画像は海外では違法なことがあります。『スパム／違法なコンテンツの含まれるサーバー一覧』というタイトルであれば聞こえはいいんですけど、海外の人が作るようなリストであれば、その中にpawoo.netは入ります。結局自分と立場の違う人が作ったリストは、自分のサーバーにとっては何の役にも立たないどころか、かえって不便になる、あるサーバーの連合が理不尽に切られる結果になると思います。
あくまで多様なサーバーが存在し、自分もその多様の一種として、たとえ汎用サーバーであろうと必ず何らかの個性を持っているということは、受け入れなくちゃいけないと思ってます。
ログは取る／確認する
NGワードとかで投稿をブロックしたら、その履歴は（プライバシーにも配慮した上で）保存すべきだと思いますし、kmyblueもバージョン11からはそのようにしています。
理由は複数ありまして、１つは上にもホワイトリストの件で書いた通り、『制限のやめ時を把握する』。それから、『正常な投稿をうっかりブロックしていないか確認する』
ただこの履歴のミゾは、検出されずブロックされなかった投稿は記録されないということです。スパムがなにかやり方を変えて、既存のNG設定に引っかからなくなったとしても、ログからはそのことが分かりません。いきなりログが減ってきたなと思ったら、それはもしかしたら規制のやめ時かもしれませんが、同時に危険な徴候であるかもしれません。結局は通報頼みになります。
ログはあくまで、制限がきつすぎないか確認するための指標にしかならないかもしれません。
まとめ
漫画描く時間なくなった。。。。。。
この記事が気に入ったらサポートをしてみませんか？