ウォッチした単語

少なくとも2つのサイトが、LLMを汚染するように設計されたスパムの波に見舞われました。同じ攻撃は、少なくとも1回(https://meta.discourse.org/t/anyone-else-currently-undergoing-mass-spam-attack/378972)ここでも報告されています。最善の解決策は、https://meta.discourse.org/t/discourse-ai-spam-detection/343541 を設定することですが、これは少し面倒です。ここでは、数分で実装できる一時的な対策を紹介します。

これは、Unixライクなオペレーティングシステム(例:LinuxまたはMac)を使用していることを前提としています。Windowsを使用しており、ターミナルにコピー&ペーストできる場合は、DiscourseサーバーにSSH接続してこれを貼り付けることができます。

これは、最近見た攻撃から生成された監視単語のセットを作成します。nanoなどのエディタに慣れている場合は、実行前に編集できます。そうでない場合は、このスクリプトを実行してから、クリック1回で不要な単語を削除できます。

ブロック単語は、正当なユーザーがそれらの単語を含む投稿を作成できなくなる可能性があるため、非常に迷惑になる可能性があります。そのため、フォーラムで正当な投稿に表示される可能性のある単語がないことを確認してください。

サイトのURL、APIキー、APIユーザーを下のボックスに入力します(これらはブラウザにのみ表示されますが、そのまま貼り付けて、必要に応じてファイルを編集することもできます)。次に、コードブロックをターミナルにコピー&ペーストします。これにより、upload_watched_words_full.shが作成され、実行可能になります。次に、./upload_watched_words_full.shで実行できます。

cat <<'EOF' > upload_watched_words_full.sh
#!/usr/bin/env bash
# Usage: ./upload_watched_words_full.sh

DISCOURSE_URL="=URL="
API_KEY="=API_KEY="
API_USERNAME="=API_USERNAME="

# High-confidence block words
BLOCK_WORDS=(
  "customer service number"
  "contact number"
  "support number"
  "refund phone number"
  "toll free"
  "24/7 support"
  "helpline"
  "call us"
  "live representative"
  "technical support"
  "lufthansa"
  "royal caribbean"
  "coinbase"
  "robinhood"
  "reservation number"
  "booking number"
  "flight cancellation"
  "name change fee"
  "║"
  "⇆"
  "★"
  "®️"
  "™️"
)

# Medium-risk flag words
FLAG_WORDS=(
  "customer service"
  "customer support"
  "support team"
  "help desk"
  "hotline"
  "agent"
  "representative"
  "contact us"
  "phone support"
  "service center"
)

# Require-approval words
REQUIRE_APPROVAL_WORDS=(
  "urgent"
  "immediate action"
  "act now"
  "limited time"
  "exclusive offer"
  "approve this"
  "verify account"
)

# Function to send words in batch
add_words () {
  local ACTION="$1"
  shift
  local WORDS=("$@")

  # Build words[] parameters
  local DATA=""
  for w in "${WORDS[@]}"; do
    DATA+="words%5B%5D=$(printf '%s' "$w" | jq -s -R -r @uri)&#"
  done
  DATA+="replacement=&action_key=${ACTION}&case_sensitive=false&html=false"

  echo "Uploading ${ACTION} words..."
  curl -s -X POST "${DISCOURSE_URL}/admin/customize/watched_words.json" \
    -H "Api-Key: ${API_KEY}" \
    -H "Api-Username: ${API_USERNAME}" \
    -H "Content-Type: application/x-www-form-urlencoded" \
    --data "$DATA"
  echo -e "\nDone."
}

# Upload block words
add_words "block" "${BLOCK_WORDS[@]}"

# Upload flag words
add_words "flag" "${FLAG_WORDS[@]}"

# Upload require-approval words
add_words "require_approval" "${REQUIRE_APPROVAL_WORDS[@]}"
EOF

# Make the script executable
chmod +x upload_watched_words_full.sh

echo "Script 'upload_watched_words_full.sh' created and made executable."

「いいね!」 8

しかし、Watched word Approval doesn't work if a user edits the reply はどうでしょうか?

まあ、それに気づいていませんでした。私の素朴な希望は、スパマーがそれに気づかないだろうということです。 :person_shrugging:

「いいね!」 1

数年前のボットは、dhfhstyhjfhhr のような意味不明な文字列をトピックタイトルとして投稿し、スレッドを生成してキーワードフィルターを回避し、その後、実際の「最高のオンラインカジノ」スパムメッセージに編集していました。:expressionless_face:

「いいね!」 2

編集で投稿を回避できるのは奇妙ですね。

このスパマーのグループはそうしないかもしれません。あるいは、これも全く役に立たないかもしれません。:person_shrugging:

「いいね!」 1

ジェイさん、ありがとうございます。素晴らしいスクリプトです。作成していただき感謝します。「投稿の編集」の回避策に関して、これを使用した方で効果があったという方はいらっしゃいますか?ボットは投稿を編集しているのでしょうか、それとも直接テキストをスパムしているだけなのでしょうか?

わかりませんが、それが問題であれば、一部のユーザーが投稿を編集できないように設定を変更することができます(「投稿編集許可グループ」)。例えば、TL2を要求し、TL2に到達しやすくしたり難しくしたりするように設定を調整することによってです。

通常のユーザー、特に新しいユーザーにとっては、投稿を編集できないことはそれほど大きな問題ではないかもしれませんし、期待していないことかもしれません。

「いいね!」 1

良い点ですね。tl_0 が投稿を編集できないように変更します。

最近の投稿の1つを確認します。

最初は単なるゴミのような内容で、その後スパムに編集されたようです。これは、私の理解が正しければ、Watched Words を回避することになります。

無害なゴミのような内容からスパムへの投稿編集が、スパムフィルターを回避するためのボットの常套手段の一部になりつつあることを考えると、Discourse チームはデフォルトで tl_0 が投稿を編集できないようにすべきだと考えているでしょうか?

「いいね!」 4

すごい。デフォルトでTL0が含まれていることに驚いています。

これらのスパマーがそのトリックを使用していることを確実に知っておくと良いでしょう。

AIスパムモジュールが検出したと思います。

「いいね!」 2

確かに検出したでしょう。しかし、AIを導入するにはそれほど高価ではないものの、スパム対策のためにすべてのDiscourseにAIを設定するのは少し面倒です。私のフォーラムの多くは、他の非常に便利なDiscourse AI機能のためにそれ(またはそれを望むこと)を必要としないでしょう。

「いいね!」 1

ここでの解決策は、tl0 や他のグループが投稿を編集するのを防ぐことではありません。

解決策は、投稿の編集がサイトの保護を回避しないようにすることです。編集された投稿には(実際にあったように)スパム、ヘイト、その他の望ましくない動作が含まれる可能性があります。編集された投稿が Watched Words やその他のフィルターをバイパスすると、これは間違いなく、サイトの保護を回避したい人間だけでなく、ボットにとっても標準的なアプローチになるでしょう。

「いいね!」 3

同意します。そのように機能しないのは奇妙なことです。そして、私の理解が正しければ、それは長い間壊れていました。

ああ、これは「期待される動作」です:

おそらく、これが原因でこうなったのでしょう。

監視対象の単語は before_save に適用できると思いますが、コードは見ていません。

「いいね!」 2

編集に対して監視対象の単語のタイプの一部が適用されることが意味することについての疑問がありますが、この制限が監視対象の単語の価値を大幅に低下させることも明らかです。

編集の場合に各タイプで正確に何が起こるべきかの仕様を提案することが役立つと予想されます。そうすれば、機能リクエストはより実行可能になります。ただし、私はその作業を行っていませんが、特定のケースについて時折考える時間を費やしてきました。

「いいね!」 3