要約

  • DNSが表すのは名前の委任とデータの権威であり、組織や信頼の境界ではない。Public Suffix Listは、共有される接尾辞と登録可能なドメインをソフトウェアが区別するための、運用上の不足情報を提供する。
  • このリストはMozillaの取り組みとして始まり、現在は外部のボランティアが支えるコミュニティー資源である。ICANN、IANA、IETFの直接統制下にはなく、公開参加や掲載はDNS全般への包括的な権限を意味しない。
  • 上流で正しくマージされた変更と、利用者の端末で有効な変更は同じではない。ブラウザー、OS、ライブラリー、サービスは異なる版を異なる方法で取り込み、ときには省略や追加もする。正しい一行が同時に世界を変えるわけではない。
  • 責任は制御面に沿って分けるべきだ。名前空間の運営者は権限と運用実態を示し、リスト保守者は証拠と整合性を扱い、配布者は変換と版を示し、製品は採用版・更新時期・一致した際の効果に責任を持つ。
  • 必要なのはリストをDNSの中央規制者へ膨らませることではなく、申請、検証、マージ、配布、製品統合、実行を結ぶ証跡である。記録とローカルな方針と実際の保護を区別できてこそ、分散した統治は説明可能になる。

分析

点の数では管理境界を数えられない

ドメイン名は右から左へ階層が深くなる。その見た目から、右端の二つを取れば組織の単位になると考えたくなる。shop.example.com なら example.com が登録者の単位であることが多い。しかし example.co.uk では co.uk が共有された登録階層であり、同じ方法は失敗する。さらにホスティング基盤では、alpha.github.io と beta.github.io が同じ親の下にあっても、管理者は別々で相互に信頼していないかもしれない。

DNSの階層は技術的な委任を正確に表せる。どのネームサーバーがあるゾーンのデータに権威を持つかは追跡できる。だが、ゾーンの内部でサブドメインを顧客へ割り当てる契約、会社の所有関係、アカウント間の隔離、あるいは同一のセキュリティー方針までは表現しない。技術上の親子関係と行政上の親子関係は重なる場合もあるが、同じ概念ではない。

RFC 8499は、ある名前がpublic suffixであることをドメイン名自身が示す内在的な印はないと説明する。かつてのIETF DBOUNDワーキンググループの憲章も、DNSだけでは管理関係が分からず、右端二ラベルという単純な答えでは不足する点を出発点にした。これは特殊な国別ドメインだけの問題ではなく、名前を共有するあらゆるサービスに現れる構造的な欠落である。

ブラウザーはこの欠落を無視できない。アドレス表示では利用者が認識すべき部分を強調したい。Cookieでは状態が無関係な利用者へ越境しないようにしたい。履歴、権限、追跡防止、メール認証、サイト単位の保存領域も、何らかの境界を必要とする。数え方だけでは足りず、DNSの委任だけでも足りないため、外部の運用知識が必要になる。

Public Suffix Listはその知識を計算可能な規則へした。公共の登録構造だけでなく、サブドメインを独立した利用者へ渡す民間サービスも含む。これは別のDNSではなく、名前の木が沈黙している管理境界についての限定的な記録である。価値は限定にある。一致した規則は、すべての法的・商業的・安全上の関係を証明するものではない。

したがって、リストから得られるのは結論ではなく証拠である。製品はその証拠を使ってCookieを拒否したり、表示を変えたり、データを分類したりする。どの効果を与えるかは製品の選択であり、上流の一行に元から埋め込まれている命令ではない。この区別が、誰に何を説明させるべきかを決める。

Cookieがテキストの一行を防壁へ変えた

もっとも直接的な利用例はCookieである。RFC 6265は、サーバーがpublic suffixをDomain属性に指定しようとする危険を扱う。仮に attacker.com が com 向けのCookieを設定できれば、その状態は無関係な多数のドメインへの要求に添付され得る。ユーザーエージェントはそのような広すぎる指定を拒否する必要があり、最新のPublic Suffix Listを使うことが推奨される。

ここでは分類データが実際の防壁になる。ただし、防壁を作るのはリスト単独ではない。ブラウザーが版を選び、アルゴリズムを実装し、更新を配り、既存Cookieを扱って初めて効果が生まれる。保守者はCookieを送信せず、ブラウザーを配布せず、利用者の端末を更新する権限も持たない。それでも規則の採否は下流の判断を変えるため、影響は大きい。

RFC 6265bisの現行草案は時間軸の危険をよりはっきり示す。古いリストによって悪意ある宛先へ機密Cookieが漏れる可能性があり、リスト変更によって以前は有効だったCookieが無効になる場合もある。アルゴリズムが正しくても、データが古ければ安全結果は正しくない。逆に新しいデータが届けば、古い状態との互換性が問題になる。

新たな境界は保護と障害を同時に生み得る。共有サービスが正しくPRIVATE節へ入れば、異なる利用者間のCookie共有を防げる。一方、サービスが旧分類の上にログインや設定を設計していたなら、セッションの切断や予期しない再認証が起きる。精度の向上は移行コストを消さない。製品は変更前後の状態を試験し、運営者は依存を把握しなければならない。

ここで名目的な権限と実効的な権限が分かれる。上流保守者は規則を受け入れるが、下流製品はその規則にどの意味を与えるかを決める。製品がPRIVATE節を使わない、独自規則を足す、更新を遅らせるといった選択も可能である。利用者が経験するのは、上流の判断ではなく一連の選択を通った最終挙動だ。

したがって「リストがWebを安全にする」という説明は広すぎる。リストは特定の安全方針に必要な入力を提供する。完全な保証には、現実に合う規則、追跡できる根拠、適切な配布、文書化された解釈、移行試験が必要である。どの層も、自分が制御する失敗を上流のせいだけにはできない。

Mozillaから始まった記録が公共的な依存先になった

プロジェクトのサイトは、Public Suffix Listを既知のpublic suffixの一覧であり、Mozillaが始めたコミュニティー資源だと説明する。公式リポジトリーは、ICANNの世界と開発者・利用者の世界を結ぶ橋と位置付ける。ICANNのOCTO-011はさらに明瞭で、このリストがICANN、IANA、IETFの直接的な管理や統制の外にあり、外部のボランティアによって保守されていると記す。

Mozillaはここで、プロジェクトの発起者とFirefoxを通じた大規模な下流実装者という二つの限定された役割を持つ制度上の主題である。本稿は、共有記録が実行コードになるときにその役割から生じる責任を検討する。それはMozillaが現在のコミュニティーリストを所有し、ほかの利用者へ命令できるという意味ではない。

この出自は形式的な主権を誤認しないために重要である。ICANNは識別子調整の特定部分を担い、IANAは定められた機能を実行し、IETFは公開プロセスで技術標準を作る。リストはDNS上の名前を扱うからといって、それらの権限を継承しない。広く利用されているからといって、ドメインの規制機関になるわけでもない。

その一方、「Mozillaのファイル」にすぎないという見方も現実を捉えない。ブラウザー以外の多数のソフトウェアがコピーし、変換し、組み込んでいる。保守者が各利用者へ命令しなくても、互換性と便利さが採用を促す。読みやすいテキストは小さな形式でありながら、組織の壁を越えやすい。公共性は所有名ではなく、依存の広がりから生まれている。

インターネットでは、このような実効力が珍しくない。中心が端点へ命令するのではなく、狭く有用な記録を維持し、独立した実装が自発的に利用する。上流で誰も採用しない一行を加えても公共効果はほとんどない。逆に主要ブラウザーが同じデータを別の意味で使えば、上流を変更せずに大きな効果を生める。

実行中のコードを重視する原則は、文書や合意を軽んじるものではない。文書は何が提案され、どんな証拠が受理されたかを示す。コードはその記録を現実の判断へ変える。統治上の問いは「誰が最上位か」ではなく、「どの移行を誰が制御し、どこまでを証明できるか」である。

リストの正当性も、この分業から理解できる。保守者は目的が限定された記録を、公開の履歴と一定の審査で維持する。利用者は採用を選び、自らの用途に責任を持つ。双方が役割を越えた権限を主張しないからこそ、異なる組織が共通の基盤を利用できる。

ICANN節とPRIVATE節は同じ種類の事実ではない

リストの形式はICANN節とPRIVATE節を分ける。前者は公共の登録方針に関係する接尾辞を主に扱い、後者は民間サービスがサブドメインを独立利用者へ割り当てる境界を示す。利用するソフトウェアは両方を同じように採用する必要はなく、用途に応じて節を選べる。この区分は由来の違いを保つための設計である。

規則には完全一致、ワイルドカード、例外がある。最長一致によって一般的な構造を捉え、例外で特定の名前を修正する。少ない行で複雑な登録階層を記述できる反面、一つの誤りが広い範囲へ及ぶ。過度に広いワイルドカード、抜けた例外、形式上の誤りは、変換後の製品で多数の名前を再分類する可能性がある。

公式リポジトリーは、不正な項目がCookieに有害な影響を与え得ると警告する。ガイドラインは申請目的、権限ある代表者であること、DNSによる制御証明を求める。_pslに置かれた信号や申請に結び付くTXTレコードなどを使い、単なる自己申告より強い根拠を得る。敏感な名前空間では追加確認が行われ得る。

PRIVATE節では、実際に継続運用されるサービスかどうかも問題になる。一時的な実験や便宜的な要求を採用すれば、共有記録が製品待遇を得るためのスイッチになりかねない。一定の運用期間や目的の説明は、申請の外形ではなく実態を確認するためにある。

しかし、DNSでの証明は万能ではない。特定時点の技術的な制御は示せても、すべての契約上の権限や将来の所有関係までは示せない。DNS代行者が操作できる場合、資格が失効した担当者が残る場合、企業が売却される場合もある。検証は不確実性を減らすが、永久の事実を作るわけではない。

だからこそ、規則と来歴を結び付ける必要がある。現在のテキストは高速な計算に適する。申請、証明、議論、マージ時点、後の訂正を示す履歴は、なぜその行が存在するのかを説明する。運用実態が変わった際に、履歴がなければ再評価は推測に頼ることになる。

節の違いは下流の自由も守る。Cookieでは両節を使い、公共登録構造の研究ではICANN節だけを見るという選択ができる。重要なのは、その選択をDNS自身が命じたように説明しないことである。ローカルな方針はローカルな所有者を持つべきだ。

参加の窓口と決定の権限を混同しない

公開リポジトリーは、運営者や利用者が問題を指摘し、修正を提案し、審査の履歴を読むための窓口になる。各サービスの運営者は自分のサブドメイン配布方式を最もよく知る。外部研究者は異常な境界を発見できる。公開された議論は後の検証にも役立つ。参加の広さは情報収集の強みである。

だが、誰でも提案できることと、誰の提案でも受け入れられることは別である。マージも、申請者にブラウザーやメール製品全体への権限を与えない。申請者は自分の名前空間について根拠を示し、保守者はリストの基準に照らして判断する。製品はその結果を採用するか決める。それぞれの判断は隣の判断を置き換えない。

近年のガイドライン変更は、運用に応じて統制が調整されることを示す。2026年5月6日の告知は新規申請に標準フォームを求め、宣誓を一貫した公開審査記録として残す。2025年5月27日の告知はCloudflare固有のサブドメイン制限を回避するためにPSLを使う要求を退ける。いずれも共同資源の目的を守る実務上の統制である。

認証の意味も限定して読む必要がある。所定のDNSレコードを置ける主体は、そのゾーンに技術的な制御を持つ可能性が高い。しかし運用代行会社が顧客に代わって管理することもあり、資格情報が侵害されることもある。技術的制御と商業的な代表権が常に一致するとは限らない。証明には時点と範囲がある。

よい記録は、最終状態だけでなく理由を残す。誰が何を示し、どの基準で審査され、いつ受理されたかが分かれば、運営者の変更やサービス終了後に再検討できる。履歴は手続きの装飾ではなく、訂正可能性を作る安全機能である。

下流製品も、ボランティアの無料資源だからという理由でリスクを上流へ移せない。重要な安全判断に使うなら、変更監視、回帰試験、更新方針、緊急時の回復を自分で整備する必要がある。依存が大きいほど、消費者側の説明責任も大きくなる。

マージされた日と利用者が変わる日は一致しない

ICANNのOCTO-011は、配布の多様性を具体的に描く。最新版を取得するソフトウェアもあれば、構築時に静的なコピーを埋め込むもの、OSが持つ版に依存するもの、更新が遅いか止まっているものもある。節を省略したり、独自項目を追加したり、形式を変えたりする消費者もいる。モバイルではアプリではなくOS更新に左右される場合がある。

したがって、インターネット全体に一つの発効時刻はない。申請、確認、マージ、パッケージ化、製品公開、端末導入、有効化という複数の時点があり、最後には更新されない長い尾が残る。主リポジトリーを見て確認できるのは上流の状態だけで、利用者の保護状態ではない。

Firefoxのソースツリーにある有効TLD名のスナップショットは、来歴を示す一例である。上流のURL、版の日時、commitが記録され、製品内のデータがどこから来たかをたどれる。それだけで全利用者の実行版を証明できないが、出所不明のコピーより監査と事故対応が容易になる。

配布の証跡は段階ごとに作れる。保守者は変更識別子と根拠を示す。配布者は採用版と変換内容を記録する。製品は診断情報として有効なデータ版を示す。試験は変更対象の境界を実際に確認する。公開基盤はどの構築から有効になったかを残す。各証跡は限定的でも、連結すれば現実の状態が見える。

誤った規則を取り消す際、この連結が不可欠になる。上流でrevertしても、すでに配られた製品や保存済みCookieは消えない。どの版が影響を受け、どの端末が未更新で、既存状態を削除または移行すべきかを判断しなければならない。ソースの可逆性と利用者影響の可逆性は別である。

公開説明も層を分けるべきだ。「上流は修正済み」「製品版Xへ収録済み」「配布率はこの範囲」「旧状態には追加対応が必要」と表せば、読み手は自分の位置を理解できる。「問題は解決した」という一文では、誰の何がいつ変わったかを検証できない。

時間についての正確さは、分散環境における安全の一部である。すべてを同時に変えられない事実を欠陥として隠すのではなく、差異を観測し、危険な長期化に責任者を置く。同期そのものより、同期状態を説明できることが重要になる。

一つのリストから同じ政策は導かれない

Public Suffix ListはCookie以外にも利用される。プロジェクトはドメイン表示や履歴の並べ替えを挙げ、ICANNの報告はプロセスやスクリプトの境界、ドメイン解釈、DMARCなどのメール用途を記す。URLライブラリー、分析、プライバシー保護、権限管理などへも同じ計算結果が流れ得る。

同じ入力を使うからといって、用途の安全要求は同じではない。WHATWG URL Standardは、github.io がpublic suffixで whatwg.github.io が登録可能ドメインになる例を示す。同時に、クライアントごとにリストが異なり得るため、public suffixや登録可能ドメインを強いセキュリティー境界にしてはならないと警告し、必要ならscheme、host、portからなるoriginを使うよう促す。

表示上の強調なら短期の差異を許容できるかもしれない。Cookieや実行権限なら同じ差異が機密状態の越境を生む。統計上の近似に適する分類が、アカウントの所有権を示すとは限らない。消費者はまず脅威モデルを示し、その後で一致結果に与える意味を選ぶべきである。

機能の膨張は抽象化の中で起きる。最初の層がCookieのために登録可能ドメインを計算し、次の層がそれを「サイト」と呼び、さらに別の層が「サイト」を組織や利用者の単位として使う。上流の一行が変わったとき、どの機能が動くかを誰も知らない。成功した依存ほど、元の目的が見えにくい。

再利用を禁止する必要はない。必要なのはローカルな契約である。どの節を使うか、版をどう取得するか、未一致やエラー時に何をするか、版の不一致をどう扱うか、どの機能が結果に依存するか、誰が監視するかを明示する。この契約が、隠れた依存を審査可能な方針へ変える。

特に、登録可能ドメインを組織IDとして扱う誘惑には注意が要る。一組織が複数ドメインを持ち、一ドメインを複数主体が共有し、ドメインが譲渡されても文字列は変わらない。境界計算は有用な手掛かりだが、法的または運用上の本人確認ではない。必要なら別の証明層を用意すべきである。

制御できる範囲に責任を置く

名前空間の運営者は、自分のサブドメインが誰にどのように配られるかを知り、制御証明を出せる。リスト保守者は、受理基準、証拠審査、形式の一貫性、履歴を制御する。配布者はデータ変換と更新時期を制御する。製品はアルゴリズムとローカルな効果を制御する。管理者や利用者は導入時期の一部を制御する。全範囲を持つ主体はいない。

この分解は二つの誤りを防ぐ。一つは、第三者が構築したすべての効果を上流ボランティアの責任にすること。もう一つは、製品が「リストに書いてあるから」と自分の方針を隠すことである。上流は受理した境界を記す。Cookieを拒否し、表示を変え、権限をまとめるのは下流の決定だ。

各主体の動機も異なる。プラットフォームは早い掲載で利用者を守り、支援コストを下げたい。保守者は誤った広範囲変更を避けたい。ブラウザーは安全と互換性を両立したい。OSは公開周期を守りたい。利用者はログインが突然壊れないことを望む。手続きは、これらが自然に一致するという前提を置いてはならない。

有効な統治は全員を一つの指揮系統に入れることではない。各技術領域の間に明瞭なインターフェースを置くことだ。申請者は自分が証明できる事実を提出し、保守者は記録の目的に限って判断し、配布者は採用版を示し、製品は効果を所有する。次の層は前の層を検証できても、その権限全部を受け継がない。

これにより多様性と協調を両立できる。製品はリスクに合わせた更新方針を選べる。重要な差異が意図的で、公開され、試験されているなら、完全な同一性は不要である。相互運用とは差異がないことではなく、差異が不意打ちにならないことである。

責任を制御面へ戻すと、投資先も見える。保守者には証拠と履歴、配布者には版と変換の記録、製品には回帰試験と導入観測、運営者にはサービス実態の更新が必要になる。抽象的な権限論ではなく、具体的な故障面へ資源を配れる。

狭い記録者であり続けることが制度を強くする

リストは明確な不足を読みやすい工件で埋める。ドメイン登録を扱わず、商標紛争を裁かず、プラットフォームの善悪を認証せず、すべての端末へ直接配信もしない。この狭さが、異なる組織が共通データを使える理由である。採用者は自分の最終方針を渡さずに、共同の証拠を利用できる。

下流用途が増えるたびに上流の権限を膨らませれば、制度はかえって弱くなる。保守者は観測できない商業、プライバシー、セキュリティーの争いを裁くよう迫られ、申請は各製品で有利な扱いを得る手段になる。ボランティアの能力と説明責任は、広がった期待に追い付かない。

強化すべきは証拠と来歴である。上流は認証を改善し、目的を明確にし、高影響変更を識別し、機械でも扱える由来情報を出せる。配布者は周期と変換を説明できる。製品は版と用途を示せる。標準文書は要求、推奨、不確実性を区別できる。中央権限を増やさずに問責性を高められる。

実行中のコードを優先する考え方は単純な試験を与える。記録が実装へ届かなければ、宣言された効果は生じない。同時に、実行者は採用したテキストへ自分の行為をすべて帰属できない。コンパイル、解釈、更新、起動はそれぞれ決定であり、所有者が必要である。

Public Suffix Listは、インターネット統治の多中心性を小さな形で見せる。コミュニティーが限定的な記録を維持し、独立組織が製品へ取り込み、公共効果は組み合わせから現れる。強さは最高位の肩書ではなく、証拠から利用者の端末まで判断を追跡できることにある。

狭い役割は受動的であることを意味しない。危険な申請を拒み、古くなった規則を見直し、下流へ影響を知らせることは必要だ。ただし、その行為は記録の品質と目的に根差すべきで、全消費者の政策を代理するものではない。この境界を守ることが長期的な信頼を支える。

更新は単なるデータ同期ではない

Public Suffix Listを普通の依存ファイルとして扱うと、変更の意味を見失う。辞書に語を追加しても既存の認証境界は通常変わらないが、ここで一規則を追加すれば、コードを一行も変えずに製品が考える「サイト」が動く。データの版上げは、ソフトウェア保守であると同時に方針変更である。

依存更新の自動化は、形式が読めるか、既存試験が通るかを確認するには有効だ。だが高影響な境界変更では、どの名前が再分類されるか、どの保存状態が残るか、どの利用者が同一サイトから別サイトへ移るかを示す差分が要る。テキスト行の差分だけでは、製品上の差分を説明できない。

完全一致、ワイルドカード、例外では影響範囲が違う。ICANN節の登録方針変更と、PRIVATE節のサービス終了でも必要な確認は違う。製品チームは上流変更を、自分が使うCookie、表示、隔離、分析の機能へ対応付けるべきだ。その対応表があれば、レビューは上流の正しさだけでなく利用者への結果を扱える。

段階的公開では新旧版の相互作用を試す必要がある。同じサービスへ異なる境界判断を持つクライアントが接続し、既存Cookieを再利用する。単一版の単体試験ではこの状態を再現できない。高影響変更には、二版の観測、灰度公開、明確な停止条件、古い状態の処理が必要になる。

長期サポート製品はさらに難しい。組み込み機器や企業環境では、上流変更から何年も更新できない場合がある。「最新リストに依存する」と文書に書くだけでは保護にならない。許容遅延、更新不能時の緩和、サポート終了後の扱いを定めなければ、推奨は実行経路を持たない。

資産管理もコードのライブラリー名だけでは不足する。どのデータ版がどの変換ツールを通り、どの製品へ入ったかを記録すれば、緊急修正時の探索が速くなる。OSが提供する版とアプリ内の版が競合する場合や、ローカル修正がある場合も可視化できる。

すべての変更を重い会議へ送る必要はない。多くは自動で進められる。ただし影響分類があり、広範囲な規則や権限変更を拾い、例外的な審査へ切り替えられることが条件である。速度を止めるのではなく、速度を結果の大きさへ合わせるのが目的だ。

追加より削除が制度の回復力を試す

新規掲載では、申請者に提出の動機があり、テンプレートが必要情報を集められる。削除や訂正は難しい。サービスが終了し、会社が変わり、担当者がいなくなった後で、古い規則が残ることがある。下流にはその規則を前提に作られたCookieや製品方針が蓄積している。回復力は受理の速さより、誤りを安全に撤回できるかで測られる。

撤回理由を区別する必要がある。最初から権限がなかったのか、当時は正しく後に状況が変わったのか、形式だけの誤りか、サービスモデルの廃止か。理由によって証拠、緊急度、下流への通知は変わる。すべてを同じ削除行として扱えば、消費者は移行の危険を判断できない。

問題の発見者も一種類ではない。現運営者、旧申請者、影響を受ける利用者、安全研究者、保守者のいずれも警告を出し得る。公開報告を許しつつ、最終変更は検証可能な根拠へ結び付ける。誰でも報告できることと、誰でも即時に規則を消せることは別である。

上流の撤回と下流の対処も分ける。保守者は共通記録を修正できるが、配布済みの全コピーを遠隔で消せない。製品は帯域外更新が必要か、Cookieやセッションを失効させるか、二重防護を置くかを判断する。各層の緊急手段が連結されて初めて、訂正が利用者へ届く。

初期段階では事実が不足する場合もある。保守者は危険を注記し、追加証明を求め、特定の自動処理を保留できる。下流は保守的な扱いを一時的に選べる。不確実性を正確に示すことは弱さではない。証拠不足を確信に見せるより、期間と解除条件を持つ暫定策の方が安全である。

事後記録は「行を消した」で終わらせない。なぜ失効し、どこまで伝わり、どの制御が失敗し、どの古い版が残り得るかを記す。その学びが申請の検証、影響分類、製品試験へ戻る。最終テキストだけを保存する制度は、同じ失敗を何度も初めて経験する。

何が事実で、何が提案か

一次資料から確認できることは多い。DNSには普遍的な管理境界の印がない。Public Suffix ListはMozillaから始まり、コミュニティーで維持され、ICANN、IANA、IETFの直接統制外にある。形式は二節と一致規則を定め、申請には目的と制御の証拠を求める。下流の配布と解釈は一様ではなく、Cookieなど現実の機能が依存している。

一方、公開資料だけでは全消費者の現在版を確認できない。すべての製品が何日で更新し、どのローカル変更を持ち、何台の端末が永久に古いままかは分からない。Firefoxの来歴表示は有用な例だが、生態系全体の代表値ではない。正確な影響量には各製品からの追加情報が必要である。

本稿が提案する配布証跡の連結は、分散した実態から導いた統治案であり、すでに全体で実施されている機能ではない。制御面に沿った正式な責任分担も規範的な提案である。保守負担、プライバシー、公開可能な情報量を検討し、段階的に評価すべきだ。

更新速度と安定性の緊張も解消できない。迅速な修正は危険な旧分類の期間を短くするが、互換性問題を早く広げる可能性がある。遅い採用は突然の破壊を減らし、露出を長引かせる。すべての用途に一つの最適周期はない。影響別の試験と透明な状態表示が必要になる。

結論は限定的でよい。リストは既知の運用境界について明瞭な記録であり続けるべきで、消費者はその記録を実効的な権限へ変える自分の選択を認めるべきだ。双方の証拠が結び付けば、共同体は協調を主権と取り違えずに誤りを訂正できる。

情報源