要約

  • 10月27日付の個人Internet-Draftは、求人・取引・教育サービスのアプリ内でサポート担当者や採用担当者に似せる送信者を扱う。新しい通信プロトコルは定めない。
  • 草案は、Unicodeのスケルトンが完全一致するかだけを見る検査と、不可視の書式文字を残したままホスト名を受け入れる検証器を問題に挙げる。送信者、リンク先、依頼内容を合わせて判断する構成を示す。

求人サイトの受信箱に「公式サポート」を名乗るメッセージが届く。読み手が見る名前を入力できることと、その名前で運営会社を代表できることは別だ。送信者のなりすましを扱う新草案は、送信者のアカウント、表示名、ドメイン、リンク先、求める行動を一通ごとに調べる。アプリ内の二つのアカウントの間には、受信者企業のメールゲートウェイがいない。窓口の名前を管理し、表示する側の製品が最初の検査を引き受ける。

草案は手掛かりを三つに分ける。送信元とリンク先のホストを保護対象の名前と比較する。無関係のドメインを使うアカウントがブランド名を表示名にしていないか見る。そして認証情報の要求、外部サイトへの誘導、運営権限の主張を読む。似た名前だけで強い処分を決めれば、本物の大学就職課にも当たる。名前の一致は調査の入口であり、処分の結論ではない。

最初の技術的な穴は文字の変換にある。Unicode UTS #39は、紛らわしい文字列のスケルトン変換と複数の文字体系の検出を定義する。草案が示すのは、スケルトンの完全一致だけに頼った実装の取りこぼしだ。ギリシャ文字の小文字カッパやキリル文字の小文字テは、ASCIIではないラテン文字を原型とする。このため、見た目が似た名前でもASCIIの保護対象とスケルトンが一致しない場合がある。草案は文字体系の混在検査と、スケルトン間の範囲を限った編集距離を加えるよう提案する。

もう一つは画面に幅を取らない文字だ。草案によると、調査した複数の検証ライブラリはU+00AD、U+200B、U+2060、U+FEFFなどを含むホスト名を受け入れ、見えない文字を残して返した。RFC 5890は国際化ドメイン名の枠組みを、RFC 5892は文字の扱いを定め、Unicode UTS #46は互換処理を記す。草案は許可リストとの照合前にIDNA2008またはUTS-46で処理し、書式文字や既定で無視される文字を含むラベルを拒むよう求める。検証器が「有効」と返した元の文字列を次の部品が信用すれば、見えない差分も一緒に通る。

最終的な権限はプラットフォーム内で決まる。どのサポート名を守り、どのアカウントに使わせ、疑わしい一通に警告を出すか停止するか。草案は言語モデルを補助に使う場合にもメッセージ本文を信用しない入力として扱い、決定的な送信者の証拠をモデルの判定より優先すると記す。Datatrackerの状態は個人草案のI-D Existsで、目標はInformationalだ。

草案には検証ライブラリの名前と版、再現用の入力・出力表が載っていない。その表が公表されれば、不可視文字の問題が現行版にも残る範囲を確かめられる。