要約

  • Usenetのcancelは、通常の記事と同じ分散経路を進む制御記事であり、Message-IDを指定して撤回を求めても全コピーを回収する命令にはならなかった。
  • 実行権限は各serving agentにあり、要求の無視も、元記事より先に届いたcancelを記憶するprecancelもローカルな方針だった。
  • 後年のCancel-LockとCancel-Keyは公開時に仕込む撤回承認の証拠を提供したが、記事全体の完全性、普遍的な本人性、全保存先での消去までは保証しない。

消したい記事と同じ道を通る要求

中央サービスなら、管理者が一つの正本を書き換えれば「取り消し」を一つの時刻で語れる。Usenetはそうではない。自律したサイトがローカルのspoolを持ち、隣接先から記事を受け取り、さらに別の相手へ渡す。ある記事がどこに存在するかを一者が完全には把握しない。

この環境では、取り消しも配送されなければならない。RFC 850は1983年、制御メッセージが通常のUSENETメッセージと同じ仕組みで配布されると記した。さらに、実装者や管理者が自動実行するか、人の判断を待つ列へ入れるかを選べるとしていた。

つまりcancelは遠隔削除APIではない。「このMessage-IDについて行動してほしい」という記事だ。受信側に対象があり、方針が許せば読者から見えなくする。方針が拒めば何も変わらない。プロトコルは要求を相互運用させたが、他人のディスクへの統治権までは運ばなかった。

識別子は対象を揃え、依頼者を証明しない

歴史的な形式は cancel <message ID> だった。コピーごとに格納場所や到着順が違っても、Message-IDなら同じ論理記事を指せる。RFC 1036は1987年にもこの形式とローカルな効力を維持し、取り消せないシステムはそのcancelを隣接先へ転送すべきでないとした。

ここで二つの問いを分ける必要がある。どの記事が対象か。そして、依頼者にその記事を引っ込める資格があるか。Message-IDが答えるのは前者だけだ。

初期仕様では、投稿者またはローカルのsuperuserを認め、制御記事と対象記事のSenderやFromを比較した。協調的な運用で誤操作を減らす手掛かりにはなる。しかし誰でも複製できるヘッダー文字列は、本人による承認の証明ではない。

RFC 5537はこの比較の義務を削除した。安全性を与えず、かえって情報を隠す誘因になったからである。代わりに世界共通の本人確認機構を置いたわけでもない。許可はローカル、非標準、あるいは人手でよく、serving agentが制御記事に従う義務はない。

これは後退ではなく、証拠の限界を明示した変更だった。文字列一致を認証と呼び続けるより、各サイトが何を根拠に実行するのかを自ら引き受ける方が、連邦型ネットワークの実態に合う。

まだない記事を忘れないprecancel

配送順はサイトごとに異なる。cancelが先に届き、元記事が別のキューで遅れている場合、その時点で削除対象は存在しない。何も記録しなければ、数時間後に元記事を受け入れ、取り消し済みのはずの記事が復活する。

RFC 5537は、この場合に対象Message-IDを記憶し、後から来た元記事を拒否するprecancelを説明している。内容を保存するのではなく、不在の対象についての否定的な状態を残す。複製システムでいうtombstoneに近い。

ただし墓標が立つのはそのサイトだけだ。cancelが届かなかったサイト、記録を早く期限切れにしたサイト、precancelを採用しないサイトでは元記事が残り得る。元記事と似たNewsgroupsを使うことは同じ受信者へ届く可能性を高めるが、配送集合の一致を保証しない。moderated groupではApprovedの要件も加わる。

Supersedesも同じ境界を越えない。RFC 5536が以前の記事を指定するフィールドを定め、RFC 5537がその撤回効果にcancelと同様の認可判断を求める。新しい版を投稿した事実だけで、古い版の全コピーに対する権利は得られない。

便利な制御面は、攻撃者にも便利だった

別の記事を不可視にできるメッセージは、誤りを直す投稿者にも、言論を消したい攻撃者にも有用だ。自動処理を広げれば偽造cancelの被害が大きくなる。全面的に無視すれば、正当な修正やスパム対策が難しくなる。

RFC 2635は、反復投稿や大量クロスポストへの運用上の対応としてcancelbotを記録した。これは迷惑投稿が自動化を促した証拠であって、botに普遍的な権限を授ける規定ではない。受け入れるかどうかは依然として各サイトが決めた。

RFC 5537も、認証の難しさと悪用のため、多くのサイトがcancelやSupersedesを無視したと述べる。共通フォーマットが共通の統治を意味しない好例である。どの誤りを重く見るか――偽の撤回を実行する危険か、真の撤回を拒む損失か――は運用者に戻ってきた。

公開時に錠を置き、撤回時に鍵を示す

RFC 8315は2018年、この認可問題の一部へ限定的な暗号学的解を与えた。元のproto-articleに Cancel-Lock を入れる。これは秘密材料から作ったハッシュで、秘密そのものは明かさない。後のcancelまたはSupersedesを含む記事が Cancel-Key を提示し、参加agentが元記事の錠と対応するか確かめる。

重要なのは事前性だ。問題が起きてからFromを写すのではなく、記事をネットワークへ投入する時点で将来の撤回能力を約束しておく。投稿者、posting agent、moderator、injecting agentがそれぞれ錠を持てる。注入後のrelayは錠を変更してはならない。複数ある場合は、そのうち一つに対応する秘密の知識で承認できる。

証明する命題は狭い。「この依頼者は、元記事に置かれた撤回用コミットメントと結び付く知識を示した」。RFC 8315は、これが記事全体のintegrityを与えないと明記する。他の部分は変更され得る。現実の人物を普遍的に同定せず、サイトへ実行を強制せず、参加しない保存先には何も起こさない。

IANAのNetnews Parametersはハッシュ名と用途状態を登録している。RFC 8315ではSHA-256が必須で、レジストリにはSHA-512のほか、obsoleteのMD5、limited-useのSHA-1も残る。登録は解釈を揃えるためのもので、導入率や取り消し成功率の統計ではない。

撤回の証明書は全ネットワークの死亡証明書ではない

一連の動作には少なくとも、要求の作成、配送、受信、認可、ローカルな非公開化がある。それぞれについてログを持てても、一つのログから残り全部を断定することはできない。

Cancel-Keyの照合成功は、参加agentが元の錠に対する承認を確認したという事実だ。ローカル削除は、そのagentが自分のコピーを提供しなくなったという事実だ。別のpeer、gateway、archive、読者の保存物は外側にある。ArchiveやDistributionに希望を書いても、開かれたプロトコルの全参加者へ保管方針を強制できない。

Usenet史が教えるのは、撤回を一つの動詞で済ませないことだ。対象の同定、承認証拠、要求の到達、ローカル実行、外部保持を分けて説明する。「このサーバーでは見えない」は確認できる。「ネットワークから消えた」は、誰も全コピーを支配していない以上、別種の約束になる。

出典