PN経由で匿名スレッドを投稿するか、匿名でフィードバックを送るためのプラグイン

カスタマイズ プラグイン
1
:information_source: 概要 2 つの独立した匿名投稿フォームを提供します
:hammer_and_wrench: リポジトリリンク GitHub - elRicharde/discourse-anonymous-feedback: Anonymous Feedback Formular in Discourse · GitHub
:open_book: インストールガイド Discourse へのプラグインのインストール方法

この Discourse プラグインは、「匿名フィードバック」と「ホワイトボード」という 2 つの独立した匿名投稿フォームを提供します。両方のフォームは「ドアコード」（簡単なパスワード）によって保護されており、アカウントを持たないユーザーでも、事前に設定されたユーザーグループにプライベートメッセージを送信できます。通常のフォーラムではログインが必要ですが、この 2 つのフォームでは必要ありません。

技術的には、ログインを必要とせずに Web ページから投稿が送信され、プライベートブラウジングタブでも使用可能です。IP アドレスは記録されないため、送信者を追跡する方法はありません。このプラグインは、安全で機密性の高いコミュニケーションチャネルを提供するように設計されています。

このプラグインを使う理由

多くのコミュニティでは、機密性の高いトピックやアイデアについて、匿名性を保証し社会的プレッシャーを軽減するフィードバックチャネルが必要です。このプラグインは、いくつかの重要な課題に対処します：

  • 抑制されないフィードバックの促進：ユーザー（およびドアコードを外部で共有している場合、非ユーザーさえも）が、判断や報復を恐れることなく、率直でフィルターされていない意見、懸念、革新的なアイデアを共有できる安全なスペースを提供します。これにより、それまで控えられていたより率直で価値のある意見が得られる可能性があります。

  • 機密性と信頼：IP アドレスの記録なしに HMAC ベースのレート制限などの技術的措置によって匿名性を保証することで、このプラグインは信頼を築き、特にデリケートな話題において参加を促進します。

  • コミュニケーションのギャップの解消：公開投稿をためらう人々や Discourse アカウントを持たない人々にとってアクセスしやすいコミュニケーションの架け橋を作り、コミュニティ参加の範囲を広げます。

  • 構造化された入力：フィードバックを特定のプライベートグループに誘導することで、機密情報が適切なチームメンバーによってレビューされ、公開の場から離れた場所で焦点を絞った議論と対応が可能になります。

  • 非ユーザー向けの簡便さ：ドアコードメカニズムにより、外部関係者や一時的な訪問者が、完全なアカウント登録のオーバーヘッドなしに入力を提供できます。

最終的に、このプラグインは、重要な議論や提案のためのより包括的で安全な環境を可能にすることで、コミュニティの相互作用を強化します。

仕組み（技術的概要）

このプラグインは、匿名性とセキュリティに重点を置いて開発されました。

  1. アクセス：ユーザーは /anonymous-feedback または /white-board に移動します。

  2. 解除：ユーザーは正しいドアコードを入力する必要があります。サーバーがこのコードを検証します。

    • ブルートフォース攻撃を防ぐため、サーバーはユーザーの IP アドレスと回転するシークレットの HMAC ハッシュに基づくレート制限システムを使用します。IP アドレス自体は決して保存されません。

    • コードが正しい場合、サーバーはユーザーのセッションに一時的な、一度だけ使用可能なフラグを設定します。

  3. 送信：ユーザーはメッセージを書き、送信します。

  4. PM の作成：サーバーはセッションフラグを確認します。有効な場合、設定されたターゲットグループへの新しいプライベートメッセージを作成し、設定されたボットユーザー（またはシステムユーザー）として投稿します。その後、セッションフラグは直ちに削除され、ユーザーはさらにメッセージを送信するたびにドアコードを再度入力する必要があります。

使用事例/ワークフロー

このプラグインは柔軟に設計されています。以下に、実装できる 2 つの一般的なワークフローを示します：

使用事例 1：「ホワイトボード」- 管理された公開掲示板

この使用事例は、コミュニティ内で観察された機密性の高いトピックや不適切な行動（イベントや一般的な相互作用など）の可視化のために設計されています。例えば、セクシズムなどの問題を目に見えるようにすることです。

目的：報告者の身元を明かすことなく、重要な問題をコミュニティに可視化することです。焦点は送信者ではなく、メッセージ（場合によっては関与する個人さえも）にあります。名前を挙げずに不適切な行動の状況を単純に表現するだけでも、可視性が生まれ、意識が高まります。

ワークフロー：

  1. 送信：ユーザーは /white-board フォームを通じて投稿を送信します。これはメンバー（MG）、見習い（ANW）、ファシリテーター（FM）がアクセスできます。投稿を作成できるのは「Anonymous」ユーザーのみです。

  2. プライベートレビュー：投稿は、設定された target_group（例：モデレーションチームまたは「信頼と安全」委員会）へのプライベートメッセージとして到着します。「ホワイトボード」エントリとして識別可能です。

  3. 審査：チームは、事前定義された基準（例：個人的攻撃なし、侮辱なし、コミュニティガイドラインの遵守など）に基づいて送信内容を審査します。

  4. 公開（承認された場合）：管理者がメッセージに招待され、専用の公開「ホワイトボード」カテゴリで公開トピックに変換します。このトピックは、特定の汎用アカウント（例：「WhiteBoardBot」または「Anonymous」ユーザー。bot_username 設定で構成）を使用して投稿されます。このユーザーのログイン情報は、審査グループと共有できます。公開は「Anonymous」ユーザーによって行われます。

  5. 議論の制御：「ホワイトボード」カテゴリの権限は、メンバー/見習い/ファシリテーターには表示されますが、コメント不可に設定されます。通常のフォーラムモデレーターは、この特定の領域を管理しないことが期待されます。これは指定された target_group のみの責任です。ホワイトボードにサブカテゴリ（例：「匿名クローズド」や target_group 投稿用のカテゴリなど）を含めるべきかという問題も残っています。

  6. 却下の処理：匿名の送信者に連絡する方法がないため、公開基準と投稿が却下される可能性のある理由を説明したピン留めトピックを「ホワイトボード」カテゴリに作成するのが良い慣行です。非公開を正当化する規則は、常にフォーラム内の 1 つの場所で公開されるべきです。

使用事例 2：匿名フィードバック - 直接のプライベートチャネル

この使用事例は、あらゆる種類のフィードバック（投票フィードバックやその他の匿名提案など）を特定のチームに直接提供する機密性の高い通信回線を提供するためです。

目的：メンバーおよび非メンバーが、コミュニティ事項、投票、その他のトピックに関するフィードバックを、リーダーシップまたは関連委員会に直接、安全な方法で提供できるようにすることです。

ワークフロー：

  1. 送信：ユーザーは /anonymous-feedback フォームを通じてフィードバックを送信します。件名はメッセージのカテゴリ分けに役立ちます。この投稿は、件名プレフィックス「Anonymous Message - dd.mm.yyyy, hh:mm:ss」で target_group の集合的な受信トレイに到着します。

  2. プライベート配信：メッセージは target_group へのプライベートメッセージとして到着します。件名プレフィックスによって「Anonymous Feedback」として識別可能です。その後、target_group はメッセージの処理方法を決定します。

  3. 内部処理：チームはフィードバックをプライベートで議論し、必要に応じて他の関係者を巻き込むか、対応策を決定できます。このフィードバックは、投票フィードバックやその他の匿名提案に使用される可能性があります。

  4. 不適切なフィードバックへのベストプラクティス：送信内容が不適切な場合、チームは単純にそれを削除できます。一般的な公開通知（例：「ニュース」カテゴリ）を投稿することを検討してください。「[日付] に受け取ったフィードバックは、敬意あるコミュニケーションに関するコミュニティ基準に違反したため処理されませんでした」という内容です。これにより、送信者に詳細を明かすことなく通知し、より建設的な方法で再送信するよう促します。ホワイトボード用の投稿の場合（特別なマークがないか、必要に応じてサフィックスがあることで識別可能）：モデレーターはメッセージに招待されますが、誰も返信しません。モデレーターはメッセージを「ホワイトボード」カテゴリのトピックに変換します → メンバー/見習い/ファシリテーターに可視で、コメント不可。

機能

  • 2 つの独立したエンドポイント：/anonymous-feedback と /white-board を提供し、それぞれに独自の個別設定があります。

  • ドアコードによる保護：各フォームはスパム防止のために独自の秘密のドアコードで保護されています。ドアコードは全員にとって同じであり、ページはプライベートモードや親のコンピューターでも使用できます。

  • 設定可能なターゲットグループ：各フォームからのメッセージは、特定の設定可能なユーザーグループへのプライベートメッセージとして送信されます。

  • ワンタイムセッション：メッセージが正常に送信されると、ユーザーはドアコード画面に戻されます。別のメッセージを送信するにはコードを再度入力する必要があり、単純なマルチポストスパムを防ぎます。送信後、ドアコードに戻り、マルチポストは容易にできません。

  • 匿名性を維持するレート制限：IP アドレスを記録することなく、ブルートフォース攻撃やスパムから保護します。

  • ボット保護：単純なボットを捕捉するための隠しホニープットフィールドが含まれています。

  • カスタム送信者ユーザー：各フォームに対してボットユーザーを定義でき、プライベートメッセージがこのユーザー（例：「FeedbackBot」）によって送信されたように表示されます。ユーザーは存在している必要があります。空の場合、デフォルトでシステムユーザーが使用されます。

  • クリーンでモダンなユーザーインターフェース：フォームは、一貫性のあるクリーンなユーザーエクスペリエンスを提供する再利用可能な Ember.js コンポーネントに基づいています。

インストール

Discourse プラグインのインストールに関する標準ガイドに従ってください：プラグインのインストール。

  1. プラグインのリポジトリ URL を app.yml ファイルに追加します：

    hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/elRicharde/discourse-anonymous-feedback

  2. コンテナを再構築します：cd /var/discourse && ./launcher rebuild app

設定

インストール後、Discourse 管理者設定でプラグインを設定できます。「anonymous feedback」を検索してください。すべての設定は「Anonymous Feedback」と「White Board」フォームに対して独立しています。

設定 説明
anonymous_feedback_enabled /anonymous-feedback ページをオンまたはオフに切り替えます。
white_board_enabled /white-board ページをオンまたはオフに切り替えます。
... door_code メッセージフォームにアクセスするためにユーザーが入力する秘密のパスワードです。
... target_group プライベートメッセージを受け取るユーザーグループの名前です。このグループは存在している必要があります。
... rate_limit_per_hour 乱用を防ぐために 1 時間あたりに送信できるメッセージ数のグローバル制限です。0 に設定すると無効になります。
... max_message_length メッセージテキストで許可される最大文字数です。
... hmac_rotation_hours レート制限用の秘密鍵が回転する頻度です。短い期間はブルートフォースロックをより早くリセットしますが、セキュリティはわずかに低下します。
... bot_username オプションです。PM を送信するユーザーのユーザー名です。ユーザーは存在している必要があります。空の場合、システムユーザーが使用されます。

開発/アーキテクチャ

  • バックエンド：単一の Ruby on Rails コントローラー AnonymousFeedbackController が、両方のエンドポイントのすべてのリクエストを処理します。これはリクエストパス（/anonymous-feedback 対 /white-board）をチェックしてどの設定を使用するかを決定する kind メソッドを使用します。これによりコードの重複を避けています。動的な setting ヘルパーはさらに設定の読み取りを簡素化します。

  • フロントエンド：ユーザーインターフェースは、単一の再利用可能な Ember.js コンポーネント <AnonymousFeedbackForm /> に基づいています。

    • このコンポーネントには、フォームの状態（解除、送信、エラー処理）のための完全な HTML、CSS、Javascript ロジックが含まれています。

    • ルートテンプレート（anonymous-feedback.hbs と white-board.hbs）は非常にシンプルになりました。これらは単にこのコンポーネントをインスタンス化し、正しいパラメータ（例：タイトル、API URL）を渡します。この DRY（Don’t Repeat Yourself）アプローチにより、フロントエンドコードはクリーンで保守が容易になります。

深掘り：匿名性とレート制限（HMAC）

このプラグインの中核機能は、完全な匿名性と乱用（スパム）からの保護のバランスです。

問題：有限の IP アドレス

IPv4 アドレスは、有限の組み合わせセット（約 43 億）で構成されています。

  • リスク：ハッシュ関数（SHA256 など）は不可逆的な一方向関数です。しかし、単に SHA256(IP_Address) を保存した場合、攻撃者（または管理者）は既存のすべての IP アドレスのハッシュを数秒で事前計算できます（「レインボーテーブル」）。保存されたハッシュをリストと比較することで、元の IP を即座に明らかにできます。

解決策：回転する秘密鍵を伴う HMAC

HMAC（Hash-Based Message Authentication Code）を使用します。これは、ハッシュする前にメッセージ（IP）を暗号学的な秘密鍵と組み合わせます。

  • メカニズム：識別子 = HMAC(IP_Address + Secret_Key)

  • なぜ機能するか：攻撃者がすべての可能な IP アドレスを知っていても、Secret_Key を知りません。この鍵がないと、ハッシュを事前計算できません。秘密変数が欠けているため、「レインボーテーブル」攻撃は不可能になります。

前方秘匿性（鍵の回転）

Secret_Key は自動的に回転します（例：4 時間ごと）。

  • シナリオ：サーバーがハッキングされ、攻撃者が現在の秘密鍵とデータベースを盗んだと仮定します。

  • 保護：鍵は定期的に変わり、古い鍵は永久に破棄されるため、攻撃者は現在の時間ウィンドウ（例：過去 4 時間）の IP ハッシュのみを計算できます。昨日や先週のすべての活動は、もはや存在しない鍵でハッシュされました。これにより前方秘匿性が保証されます。現在のシステムが侵害されたとしても、過去の匿名性は破られません。

高速回転 vs 低速回転

回転間隔（hmac_rotation_hours）を設定できます。

  • 高速回転（例：1 時間）：

    • 長所：最大の匿名性。異なるアクションを同じ（不明な）アクターにリンクできる時間ウィンドウは非常に短いです。

    • 短所：レート制限における「記憶喪失」。鍵が回転すると、サーバーは誰がすでにメッセージを送信したかを「忘れ」ます。1 時間目にブロックされたスパマーは、2 時間目には事実上ブロック解除されます。

  • 低速回転（例：24 時間）：

    • 長所：ブロックがより長く持続するため、スパムに対する保護が強化されます。

    • 短所：この 24 時間のウィンドウ内では、管理者は「User X」が 5 つのメッセージを送信したことを確認できます（「User X」が誰かは知らなくても）（リンク可能性）。

推奨：4 時間から 12 時間の値が、堅実なバランスを提供します。

「いいね！」 3