Twitterのスパム対策

https://blog.twitter.com/2014/fighting-spam-with-botmaker

1 comment | 1 point | by WazanovaNews 3年以上前 edited


Jshiike 3年以上前 | ▲upvoteする | link

導入以来、スパム量を40%削減したBotMakerについて、Twitterがエンジニアブログで紹介しています。

サービスの性質的にスパム対策の難易度は高い

例えばメールであれば、コンテンツは非公開であり、スパム対策による多少の配信遅延は、サービスのクオリティ上は問題ない。一方Twitterは、APIを介して配信でき、リアルタイムでコンテンツを公開するサービスゆえに、

  • スパムの配信成功/ブロックがスパム配信者からもわかってしまう。
  • スパム対策による配信遅延は、サービスのクオリティ低下になる。

という事情がある。

満たすべき要件

誤ってスパム判定してしまうことなく、かつユーザの目にスパム投稿がふれないようにするには、

  • スパムコンテンツを作成を極力難しくする。
  • スパム投稿が掲載される時間を最短にする。
  • 新しいスパムへの対応。すばやくデータ収集 / 分析 / 新ルールのデプロイ / 対策のモデル化ができるようにする。

必要がある。遅延のないシステムを担保しながらも、

  • Twitterのメイン機能(Tweet / Retweet / favorite / follow / message)の書込みパスで実行
  • コンピュータ計算能力を多いに必要とする機械学習ベースのルールをサポート
  • 開発者がルールの作成/修正をタイムリーにできる環境を提供

できるという条件を満たさなくてはいけない。

BotMakerの実行タイミング

参考図

  1. リアルタイム(Scarecrow): Twitterの主要機能と (?) 同じパスで同期して、リアルタイムでスパム検知 & 配信阻止ができる。
  2. かなりリアルタイム(Sniper): Scarecrowの網をすりぬけたスパム投稿に対応。依存する機能の関係で、リアルタイムでは対応できない機械学習のモデルがある。非同期ゆえに、遅延して配信されるものも検知できる。
  3. 定期的なジョブ : ユーザの振る舞いを一定期間監視し、大量のデータを抽出しなくてはいけないモデルは、オフラインのジョブとして定期的に実行される。

BotMakerのルール設定言語の特徴

BotMakerの開発言語は、タイプセーフで、immutableなデータ構造をもち、ランタイムは一般的なfunctionalプログラムの語彙をサポートしている。

  • 読みやすい文法。
  • 組み合わせることで、複雑な機能を書ける。
  • 既存コードの変更や再コンパイルなしに、新しいルールを追加できる。
  • 本番環境へのデプロイは数秒で可能。

#twitter

Back