このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
Webは現存する最も強力なアプリケーションプラットフォームです。適切なAPIがあれば、ブラウザで必要なものを安全に実行できます。
さて、暗号化技術以外に関しては、
2011年にJavascript暗号化が有害と見なされたことは、現在でも同様です。主な問題は、コードの配布です。エンドツーエンド暗号化メッセージングのWebアプリケーションを考えてみてください。アプリケーションは、クライアントのブラウザで暗号化キーを生成し、ユーザーが相互にエンドツーエンドで暗号化されたメッセージを閲覧して送信できるようにします。アプリケーションが侵害された場合、悪意のある行為者がJavascriptを変更するだけでメッセージを流出させることを、どうすれば阻止できるでしょうか？
興味深いことに、スマートフォンアプリにはこの問題がありません。それは、アプリストアがアプリエコシステムにセキュリティを提供するために、多くの大変な作業をしているからです。具体的には、配信されるアプリが改ざんされないことを保証する整合性、すべてのユーザーが同じアプリを利用できるようにする一貫性、そしてアプリのバージョンの記録が真実であり、一般に公開されることを保証する透明性を提供します。
アプリストアのような単一の中央機関を必要とせずに、エンドツーエンド暗号化WebアプリケーションやWeb全体でこれらのプロパティを取得できれば、素晴らしいことでしょう。さらに、このようなシステムは、エンドツーエンドの暗号化アプリだけでなく、ブラウザ内の暗号技術利用すべてに利益をもたらします。たとえば、多くのWebベースの機密LLM、暗号通貨ウォレット、そして投票システムは、その検証チェーンの最終ステップにブラウザ内Javascript暗号を使用しています。
この記事では、Cloudflareが作成を支援した、Webアプリケーションの完全性、一貫性、透明性（WACT）と呼ばれるシステムの早期紹介を提供します。WAICTは、Web全体に強力なセキュリティ保証を提供するために、ブラウザベンダー、クラウドプロバイダー、暗号化通信開発者が連携し、W3Cが支援する取り組みです。解決すべき問題について話し合い、現在の透明性仕様草案に似た解決策を構築していきます。私たちは、近い将来、ソリューション設計に関して、さらに広範なコンセンサスを形成することを期待しています。
Webアプリケーションのセキュリティ保証について話すには、まずアプリケーションが何であるかを正確に定義する必要があります。スマートフォン用アプリケーションは、基本的には単なる圧縮ファイルです。しかし、WebサイトはHTML、Javascript、WASM、CSSなどのアセットで構成されており、それぞれローカルまたは外部でホストすることができます。さらに、アセットが変更された場合、アプリケーションの機能が大幅に変化する可能性があります。したがって、アプリケーションの一貫した定義には、それが読み込むアセットに正確にコミットする必要があります。これは今説明する整合性機能を使って行われます。
単一の一貫したアプリケーションを定義するための重要な構成要素は、サブリソースの完全性 (SRI) です。SRIは、ほとんどのブラウザに組み込まれている機能で、Webサイトは外部リソースの暗号ハッシュを指定することができます。例：
<script src="https://cdnjs.cloudflare.com/ajax/libs/underscore.js/1.13.7/underscore-min.js" integrity="sha512-dvWGkLATSdw5qWb2qozZBRKJ80Omy2YN/aF3wTUVC5+D1eqbA+TjWpPpoj8vorK5xGLMa2ZqIeWCpDZP/+pQGQ=="></script>
これにより、ブラウザはunderscore.jsをcdnjs.cloudflare.comから取得し、SHA-512ハッシュがタグで指定されたハッシュと一致することを検証します。一致する場合、スクリプトがロードされます。そうでない場合は、エラーがスローされ、何も実行されません。
ページ上のすべての外部スクリプト、スタイルシートなどにSRIの整合性属性が付属する場合、ページ全体はHTMLだけで定義されます。これは当社が求めているものに近いものですが、Webアプリケーションは多くのページで構成される可能性があり、ページがリンク先ページのハッシュを強制する方法はありません。
サイト全体、つまりドメインの下にあるすべてのアセットで整合性を適用する方法を持ちたいと考えています。このために、WACTは、整合性マニフェスト（Webサイトがクライアントに提供できる設定ファイル）を定義します。マニフェストの重要な項目の1つは、アセットハッシュ辞書で、ブラウザがそのドメインから読み込む可能性のあるアセットに属するハッシュを、そのアセットのパスにマッピングします。任意のパスで発生するアセット（エラーページなど）を、空の文字列にマッピングします。
"hashes": {
"81db308d0df59b74d4a9bd25c546f25ec0fdb15a8d6d530c07a89344ae8eeb02": "/assets/js/main.js",
"fbd1d07879e672fd4557a2fa1bb2e435d88eac072f8903020a18672d5eddfb7c": "/index.html",
"5e737a67c38189a01f73040b06b4a0393b7ea71c86cf73744914bbb0cf0062eb": "/vendored/main.css",
"684ad58287ff2d085927cb1544c7d685ace897b6b25d33e46d2ec46a355b1f0e": "",
"f802517f1b2406e308599ca6f4c02d2ae28bb53ff2a5dbcddb538391cb6ad56a": ""
}
マニフェストのもう1つの主な構成要素は、整合性ポリシーで、どのデータタイプがどの程度厳密に適用されているかをブラウザに伝えます。例えば、以下のマニフェストのポリシーは次のようになります。
SRIタグがなく、ハッシュに表示されない場合は、実行前にスクリプトを拒否
SRIタグがなく、ハッシュに表示されない場合は、おそらく実行後のWASMを拒否します
"integrity-policy": "blocked-destinations=(script), checked-destinations=(wasm)"
これらをまとめると、整合性のマニフェストが作成されます。
"manifest": {
"version": 1,
"integrity-policy": ...,
"hashes": ...,
}
したがって、SRIと整合性マニフェストの両方が使用される場合、サイト全体とブラウザによるその解釈は、整合性マニフェストのハッシュによって一意に決定されます。これこそが当社が望んでいたものです。Webアプリケーションに真正性、一貫性のある配布などを付与するという問題を、単一のハッシュに同じプロパティを付与するという問題を抽出しました。
先ほど説明したように、透明性のあるWebアプリケーションとは、一般にアクセス可能な、追加専用のログにコードが保存されているアプリケーションのことです。これは2つの点で役立ちます。1) ユーザーが悪意のあるコードを送られて、それについて知った場合、そのユーザーが実行したコードの公開記録が残るので、外部に対して証明することができるため、2) ユーザーが悪意のあるコードを提供しても、ユーザーがそのことについて学習しない場合でも、外部監査人が過去のWebアプリケーションコードを調べて、悪意のあるコードを見つけてしまう可能性があります。もちろん、透明性は悪意のあるコードの検出やその配信の防止に役立つものではありませんが、少なくとも公開監査可能になります。
Webサイトのコンテンツ全体をコミットする単一のハッシュを得ることができたので、次に、そのハッシュがパブリックログに記録されるようにすることについて話できます。ここには、いくつかの重要な要件があります。
既存サイトを壊さないでください。これは当然のことです。どのようなシステムをデプロイする場合も、既存Webサイトの正しい機能を妨げるものであってはなりません。透明性への参加は、厳密にオプトイン（事前承諾）する必要があります。
ラウンドトリップの追加はありません。透明性によって、クライアントとサーバーの間の余分なネットワークラウンドトリップが発生するようなことはあってはなりません。そうしないと、透明性を求めるユーザーにネットワーク遅延のペナルティが発生することになります。
ユーザーのプライバシー。ユーザーは、すでにされている以上に自分自身を特定する必要はありません。つまり、新たな第三者とつながったり、Webサイトに識別情報を送信したりすることはありません。
ユーザーステートレス性。ユーザーがサイト固有のデータを保存する必要はありません。私たちは、サイトごとの暗号化情報の保存やなりすましに依存するソリューションを望んでいません。
非集中化。システム内に単一障害点があってはなりません。いずれかがダウンタイムを経験しても、システムは進行することができなければなりません。同様に、信頼点は存在すべきではありません。たとえユーザーがいずれかの当事者を信用しなかった場合でも、ユーザーはシステムのセキュリティ上の利点をすべて享受できるはずです。
オプトインの容易さ。透明性の障壁は、できるだけ低いようにすべきです。サイト運営者は、専門家でなくても、サイトのログ記録を安価で始められるようにする必要があります。
オプトアウトの容易さ。Webサイトが透明性への参加を停止するのは簡単なことです。さらに、廃止されたHPKP仕様のように偶発的なロックインを回避するために、すべての暗号化マテリアルが失われた場合でも、たとえばドメインの差し押さえや販売によりすべての暗号化マテリアルが失われた場合でも、このような事態が発生する可能性がある必要があります。
オプトアウトには透明性があります。前述のように、透明性はオプションであるため、攻撃者はサイトの透明性を無効にし、悪意のあるコンテンツを提供してから、再び透明性を有効にすることが可能です。この種の攻撃は検出可能であることを確認する必要があります。つまり、透明性を無効にする行為自体をどこかで記録する必要があるのです。
監視可能性。Webサイト運営者は、自身のWebサイトについて公開されている透明性情報を効率的に監視することができる必要があります。特に、サイトがハイジャックされた場合に通知するために、ネットワーク負荷の高い常時接続プログラムを実行する必要はありません。
これらの要件を満たしたら、構築に移ることができます。設計に不可欠なデータ構造を紹介します。
透明性のほぼすべてが追加のみのログです。つまり、リストのように機能し、包摂証明を生成する機能を持つデータ構造であるのです。つまり、要素がリストの特定のインデックスで発生する証明です。一貫性証明など、あるリストが以前のバージョンのリストの拡張であることを証明するものです。2つのリスト間の一貫性証明は、要素が変更・削除されず、追加のみされたことを示します。
最もシンプルな追加のみのログは、ハッシュチェーンです。これは、後続の各要素が実行中のチェーンハッシュにハッシュされるリストのようなデータ構造です。最終チェーンハッシュは、リスト全体を簡潔に表現したものです。
ハッシュチェーン。緑色のノードは、チェーンハッシュ（つまり、その1つ下の要素のハッシュ値）を表し、前のチェーンハッシュと連結しています。
証明構造は非常にシンプルです。インデックスiの要素が含まれていることを証明するために、証明者は、iの前のチェーンハッシュと、iの後のすべての要素を提供します。
ハッシュチェーンの2番目の要素が含まれていることを証明します。検証者が知るのは、最終チェーンハッシュだけです。計算された最終チェーンハッシュが既知の最終チェーンハッシュと同一性を確認します。ライトグリーンのノードは、検証者が計算するハッシュを表しています。
同様に、サイズiとjの連鎖の一貫性を証明するために、証明者はiとjの間の要素を提供します：
サイズ1のチェーンとサイズ3のチェーンの一貫性証明。検証者は、開始チェーンと終了チェーンのハッシュを持ちます。最終的な計算されたチェーンハッシュが、既知の終了チェーンハッシュと同等であることを確認します。ライトグリーンのノードは、検証者が計算するハッシュを表しています。
ハッシュチェーンを使用して、Webサイトの透明性スキームを構築することができます。
最初のステップとして、各サイトにハッシュチェーンとしてインスタンス化した独自のログを与えてみましょう（これらがすべて大きなログにまとめられる方法については後ほど説明します）。ログの項目は、特定の時点でのサイトのマニフェストです。
3つの過去のマニフェストを含む、サイトのハッシュチェーンベースのログ。
実際には、ログにはマニフェスト自体を保存するのではなく、マニフェストハッシュを保存します。サイトは、参照するデータにハッシュをどのようにマッピングするかを知っているアセットホストを指定します。これは、コンテンツアドレス可能なストレージバックエンドであり、強力にキャッシュされた静的ホスティングソリューションを使って実装できます。
ログだけではあまり信頼できません。ログを実行する人は誰でも、自由に要素を追加したり削除したりして、ハッシュチェーンを再計算することができます。チェーンの追加のみの性を維持するために、立会人と呼ばれる信頼できる第三者を指定します。ハッシュチェーンの一貫性証明と新しいチェーンハッシュがあれば、次のようになります：
古いチェーンハッシュと新しい提供されたチェーンハッシュに関する一貫性証明を検証します。
成功した場合、署名タイムスタンプと共に新しいチェーンハッシュに署名します。
現在、ユーザーが透明性を有効にしてWebサイトに移動すると、イベントの順序は次のようになります：
サイトは、マニフェスト、マニフェストがログに表示されることを示す包摂証明、ログチェーンハッシュを検証したすべての立会人からのすべての署名を提供します。
ブラウザは、信頼できる立合人からの署名を検証します。
ブラウザは包摂証明を検証します。マニフェストは、チェーンの最新エントリーである必要があります（古いマニフェストをどのように提供するかについては、後で説明します）。
ブラウザは、通常のマニフェストとSRIの整合性チェックを続行します。
この時点で、ユーザーは、信頼できる立合人によってチェーンハッシュが保存されたログに記録されたことを知ることができるため、マニフェストが履歴から削除されないことを合理的に確信することができます。さらに、アセットホストが正しく機能すると仮定すると、ユーザーは受信したコードがすべて簡単に利用可能であることを知ることができます。
透明性を知らせる必要性上記のアルゴリズムは機能しますが、問題があります。攻撃者がサイトを制御した場合、彼らは透明性のある情報の提供を停止するだけで、検出されることなく透明性を無効にすることができます。そこで、透明性を確保したすべてのWebサイトを追跡する明示的な仕組みが必要なのです。
透明性に登録されたすべてのサイトを保存するには、サイトドメインをサイトログのチェーンハッシュにマッピングするグローバルなデータ構造が必要です。これを効率的に表現する方法の1つが、プレフィックスツリー（別名、トライ）です。ツリーのツリーの成長がすべてサイトのドメインに対応し、その値は、そのサイトのログのチェーンハッシュ、現在のログサイズ、サイトのアセットホストのURLです。サイトが透明性データの有効性を証明するためには、リンク先に含まれる証明を提示する必要があります。幸いなことに、これらの証明はプレフィックスツリーにとって効率的なものです。
4つの要素を持つプレフィックスツリー。各レフトのパスはドメインに対応しています。各リーフの値は、サイトのログの連鎖ハッシュです。
ツリーに自分自身を追加するために、サイトは透明性サービス（つまり、プレフィックスツリーを運営し、アセットホストURLを提供する当事者）にドメインを所有していることを証明します。エントリーを更新するために、サイトは新しいエントリーをCloudflareサービスに送信し、透明性サービスが新しいチェーンハッシュを計算します。透明性を解除するために、サイトはツリーからエントリーを削除するよう要求するだけです（敵対者もこれを行うことができます。これを検出する方法については後述します）。
立会人は、個々のサイトログではなく、プレフィックスツリーを見るだけでよいため、ツリー全体の更新を検証しなければなりません。最も重要なのは、すべてのサイトのログが追加のみであることです。そのため、ツリーが更新されるたびに、すべての新規/削除/変更されたエントリを含む「プルーフ」と、そのエントリに対応するサイトログが適切に追加されたことを示す各エントリの一貫性証明が必要になります。立会人がこのプレフィックスツリーの更新証明を検証すると、ルートに署名します。
サイトのアセットを更新し、透明性を有効にしてサイトを提供するシーケンス。
クライアント側の検証手順は、前のセクションに2つの変更が加えられています。
これで、クライアントは2つの包摂証明を検証します。1つはサイトログの完全性ポリシーのメンバーシップの証明で、もう1つはプレフィックスツリーのサイトログのメンバーシップの証明です。
立合人は個々のチェーンハッシュに署名しないため、クライアントはプレフィックスツリールート上で署名を検証します。前述のように、許容可能なパブリックキーはクライアントが信頼することを証明するものです。
シグネリングの透明性。プレフィックスツリーという信頼のソースが1つあることで、クライアントはツリー内のサイトのエントリを取得するだけで、サイトが透明性に登録されているかを知ることができます。これだけでも機能しますが、「ラウンドトリップの追加なし」の要件に反しますので、代わりに、クライアントブラウザがプレフィックスツリーに含まれるサイトのリストと一緒に出荷されるようにする必要があります。私たちはこれを透明性プリロードリストと呼んでいます。
サイトがプリロードリストに表示されると、ブラウザは、プレフィックスツリーの包摂証明か、プレフィックスツリーの新しいバージョンにおける非包摂証明の提供を期待します。これによって、登録が解除されたことを示します。サイトは、表示される最後のプリロードリストの有効期限が切れるまで、これらの証明のいずれかを提供する必要があります。最後に、プリロードリストがプレフィックスツリーから得られていますが、この関係を強制するものはありません。そのため、プリロードリストも透明性を確保して公開する必要があります。
監視可能性、オプトアウトには透明性があること、単一障害点/信頼点が存在しないことは依然として重要です。今はこれらの詳細を入力してください。
監視可能性の追加。これまで、サイト運営者が自分のサイトがハイジャックされていないことを確認するために、サイトのあらゆる透明性サービスにドメインが改ざんされていないことを常に照会し、改ざんされていないことを確認する必要がありました。これは、CTモニターが取り込む必要がある毎時間50万イベントよりは確かに良いですが、それでもモニターがプレフィックスツリーを常にポーリングする必要があり、透明性サービスに一定の負荷がかかります。
プレフィックスツリーの情報にフィールドを追加します。リークは、ツリーの作成時間を含む「Created」タイムスタンプを格納します。立会人は、「作成済み」フィールドがすべてのリークの更新にわたって同じ状態であることを保証します（リークが削除されると削除されます）。監視するには、サイトの運営者は、リークの最後に観測された「作成された」フィールドと「ログサイズ」フィールドを保持する必要があります。最新のエッジを取得して両方が変更されていない場合、最後のチェック以降に変更がなかったことがわかります。
オプトアウトの透明性を追加する。リークの削除についても、上記と同じことをしなければなりません。リークが削除された場合、モニターは、削除が合理的な時間枠内でいつ行われたかを学習できる必要があります。したがって、透明性サービスは、リードを完全に削除するのではなく、「作成済み」のタイムスタンプのみを含むトークントークン値に置き換えることで、登録解除リクエストに応答します。以前のように、立会人は、リードが永続的に削除される（一定の可視性期間が経過した後）か再登録されるまで、このフィールドが変更されないようにします。
複数の透明性サービスを許可する。単一障害点や信頼点が存在しないことが必要なため、連携せず、合理的に信頼できる透明性のあるサービスプロバイダーがいくつかあり、それぞれが独自のプレフィックスツリーを持っているエコシステムを想像してみます。Certificate Transparency（証明書の透明性）（CT）と同様に、このセットは大きすぎないように注意してください。合理的な信頼レベルを確立できて、独立監査人がそれらすべてを検証する負荷に合理的に対処できるようにするのです。
以上で、この記事の最も技術的な部分は終わります。今日から、このシステムを微調整して、より良いプロパティをすべて提供する方法についてお話します。
サイトが更新されるたびに、それ自体の新バージョンが10万を超えると、透明性は役に立たなくなります。監査人は、ユーザーがマルウェアの標的にされないようにするために、コードの全バージョンを調査しなければなりません。これでは、バージョンの速度が低くても対策が難しくなります。サイトが毎週1つの新しいバージョンを公開するものの、過去10年間のすべてのバージョンが引き続き提供可能な場合、ユーザーは依然として非常に古い、潜在的に脆弱なサイトバージョンを、誰も知らないうちに提供される可能性があります。したがって、透明性を価値のあるものにするためには、一貫性、つまり、すべてのブラウザが一定の時点で同じバージョンのサイトを表示するという特性が必要なのです。
一貫性の最強バージョンを実現することはできないものの、弱い概念で十分であることがわかっています。上記のシナリオとは異なり、あるサイトに8つの有効なバージョンが存在する場合、監査人にとってはかなり管理しやすくなります。ですから、ユーザーがすべて同じバージョンのサイトを表示するわけではないとしても、それでも、ユーザーはすべて透明性の恩恵を受けることができると言えます。
2つのタイプの一貫性の欠如とその軽減方法について説明します。
ツリーの不整合は、透明性サービスのプレフィックスツリーがサイトのチェーンハッシュと一致しない場合に発生し、サイトの履歴が一致しない場合です。これを完全に排除する方法の1つが、プレフィックスツリーのコンセンサスメカニズムを確立することです。簡単なものは、過半数投票です。透明性サービスが5つある場合、サイトは3つのツリーインクルージョン証明をユーザーに提示し、チェーンハッシュが3つのツリーに存在することを示す必要があります。これはもちろん、ツリーインクルージョンのプルーフサイズを3倍にし、システム全体の耐障害性を低下させます（3つのログオペレーターがダウンすると、透明性のあるサイトは更新を公開できません）。
コンセンサスを得るのではなく、透明性サービスの数を制限することによって、単に不整合の量を制限することを選択しました。2025年、Chromeは8つのCertificate Transparencyログを信頼します。当社のシステムにも、同じ数の透明性サービスがあればいいのです。さらに、ルートが立合人によって署名されるため、ツリー間に不整合が存在することを検出して証明することは可能です。ですから、すべての木で同じバージョンを使うことが標準になってしまうと、サイトがこれに違反した場合に社会的圧力がかかる可能性があります。
一時的な不整合は、地理的な位置やCookieの値などの外部要因によって、ユーザーがサイトの新しいバージョンまたは古いバージョン（どちらも有効期限が切れていない）を取得した場合に発生します。極端な場合、前述のように、署名されたプレフィックスルートが10年間有効である場合、サイトは過去10年間のサイトの任意のバージョンをユーザーに提供できます。
ツリーの不整合と同様に、これはコンセンサスメカニズムを使って解決できます。たとえば、最新のマニフェストがブロックチェーン上で公開された場合、ユーザーは最新のブロックチェーンヘッドを取得し、サイトの最新バージョンを取得していることを確認できます。しかし、これではクライアントに余分なネットワークラウンドトリップが発生し、サイトが更新する前にハッシュがオンチェーンに公開されるのを待つ必要があります。さらに重要なのは、このようなコンセンサスのメカニズムを仕様に組み込むと、大幅に複雑さが増加するということです。ここではv1.0を目指しています。
当社では、立合人署名に合理的に短い有効期間を必要とすることで、時間的な不整合を軽減しています。プレフィックスルート署名を有効にするのは、たとえば1週間では、同時にサービス可能なバージョン数が大幅に制限されるためです。そのコストとは、サイトの運営者がサイトに何も変更がない場合でも、新しい署名されたルートとインクルージョンの証明のために、少なくとも週に一度は透明性サービスにクエリを実行しなければならないことです。サイトはこれをスキップすることはできず、透明性サービスはこの負荷に対処できなければなりません。このパラメータは、慎重に調整する必要があります。
整合性、一貫性、透明性を提供することはすでに大きな努力ですが、あまり大きな労力をかけずにこのシステムに統合できるアプリストアのようなセキュリティ機能がいくつかあります。
WAICTでは解決できない問題の1つに、証明に関してがあります。ユーザーが実行しているコードが、正確にはどこから来たのでしょうか？コードの監査が頻繁に行われるような環境では、これは重要ではありません。サードパーティの誰かがコードを読み取る可能性があるからです。しかし、オープンソースソフトウェアの小規模なセルフホスト型デプロイメントでは、これは現実的ではないかもしれません。たとえば、アリスが友人のボブのために自分のバージョンのCryptpadをホストしている場合、ボブはコードがCryptpadのGithubリポジトリの実際のコードと一致することをどう確認できるでしょうか。
WEBCAT。報道の自由財団（FPF）のメンバーが、WEBCATと呼ばれるソリューションを構築しました。このプロトコルにより、サイト所有者は、サイトの整合性マニフェストに署名した、つまり、サイトがユーザーに提供しているすべてのコードとその他のアセットに署名した開発者のIDを公表できます。WEBCATプラグインを持つユーザーは、開発者のSigstore署名を見て、それをもとにコードを信頼することができます。
WAICTは、WEBCATが適合し、透明性コンポーネントの恩恵を受けるのに十分な拡張性を実現しました。具体的には、マニフェストが追加のメタデータを保持できるようにし、これを拡張子と呼びます。この場合、拡張機能は開発者のSigstore IDのリストを保持します。役に立つためには、ブラウザはブラウザプラグインがこれらの拡張値にアクセスするためのAPIを公開する必要があります。このAPIを使用すると、独立した団体はWACT上に階層化したいあらゆる機能のプラグインを構築することができます。
今のところ、私たちは、その場しのぎの攻撃を防止できるものは何も構築していません。Webサイトに侵入した攻撃者は、コード署名拡張子を削除するか、サイトの透明性を完全に解除して、通常通り攻撃を継続することができます。登録解除は記録されますが、悪意のあるコードの場合は記録されないため、登録解除を誰かが目にしても、その時点で既に手遅れかもしれません。
自発的な登録解除を防止するために、クライアント側で登録解除を強制することができます。冷却期間は24時間であると仮定します。その後のルールは、サイトがプリロードリストに表示された場合、クライアントは、1) サイトの透明性が有効になっている、または2) サイトに少なくとも24時間以上経過したトークンストーンエントリーがある、のどちらかを要求します。したがって、攻撃者は、サイトの透明性を有効にしたバージョンを提供するか、破損したサイトを24時間提供するかのどちらかを選ばざるをえません。
同様に、自発的な拡張の変更を防ぐために、クライアントに拡張の冷却を適用することができます。ここでは、コード署名を例に挙げ、開発者のIDの変更が承認されるまでに24時間の待機期間が必要であるとします。まず、拡張機能dev-idsに独自のプリロードリストを持つ必要があり、どのサイトがコード署名をオプトインしているかをクライアントに知らせることが必要です（プリロードリストが存在しない場合、どのサイトでもいつでも拡張機能を削除できます）。クライアントルールは次のとおりです：サイトがプリロードリストに表示される場合、1) dev-idsがマニフェストの拡張子として存在しなければならない、そして2) dev-ids-inclusionには、現在の値が以下を示す包摂証明が含まれていなければなりません。 dev-idの99%は、少なくとも24時間以上経過したプレフィックスツリーにありました。このルールにより、クライアントは1日以上経過したdev-idsの値を拒否します。サイトがdev-idsを削除する場合、まず、1) プリロードリストから削除するようリクエストし、2) その間、dev-ids値を空の文字列に置き換え、dev-ids-inclusionを更新して反映させます。新しい価値を実現できます。
このエコシステムには、多くの異なる役割があります。各役割の信頼とリソース要件を図解してみましょう。
透明性サービス。こうした当事者は、Web上のすべての透明性のあるサイトのメタデータを保存します。ドメインの数が1億あり、各エントリーが各256B（ハッシュ値とURL）が2560億ある場合、1本のツリーで26GBになります。中間ハッシュは含まれません。規模の膨張を防ぐためには、長期間の非アクティブ期間が経過した後にサイトの登録を解除するという削除ルールを設定する必要があるでしょう。すべてのサービスがダウンした場合、透明性に対応したサイトは更新を行うことができないため、透明性サービスのダウンタイムはほぼ無相関であるべきです。したがって、透明性のあるサービスは、中程度の量のストレージを持ち、比較的高可用性があり、ダウンタイムの期間が互いに相関がない必要があります。
透明性サービスにはある程度の信頼が必要ですが、その行動は立合人によって厳密に制約されます。理論的には、サービスは任意のリーフチェーンハッシュをそれ自身のものに置き換えることができ、認証局は（一貫性証明が有効である限り）それを検証します。しかし、そうした変化は、その購入者を監視している人なら誰でも検知できます。
立。プレフィックスツリーの更新を検証し、結果のルートに署名します。ストレージコストは、透明性サービスのコストとほぼ同じです。これは、透明性サービスのすべてについてプレフィックスツリーのフルコピーを保持する必要があるためです。また、透明性サービスと同様に、高い稼働率が必要です。立会人は、少なくとも新しいキーが作成されたときにブラウザのトラストストアが更新されるのに十分な期間、署名鍵を秘密に保つことができる信頼も必要です。
アセットホスト。これらの関係者にはほとんど信頼関係がありません。クエリの応答はすべてハッシュ化され、既知のハッシュと比較されるため、悪いデータを提供することはできません。アセットホストができる唯一の悪意のある行動は、クエリへの応答を拒否することです。アセットホストは、ダウンタイムのために誤ってこれを行う場合もあります。
クライアント。これは最も信頼に敏感な部分です。クライアントは、すべての透明性と整合性のチェックを実行するソフトウェアです。もちろん、これはWebブラウザそのものです。これを信用しなければなりません。
私たちCloudflareは、このエコシステムにできる限り貢献したいと考えています。透明性サービスと立合インシデントの両方を実行することが可能であること。もちろん、立会人は透明性サービスを監視するべきではありません。それどころか、他の組織の透明性サービスを目の当たりにすることができ、私たちの透明性サービスは他の組織によって目の当たりにすることもあります。
WACTは、非標準のエコシステムや、大手プレーヤーが実際には存在しない、あるいは少なくとも大規模プレーヤーが通常存在しないようなエコシステムと互換性がある必要があります。Cloudflareは、ネットワークや信頼環境が異なる代替エコシステムについて、透明性を定義するためにFPFと協力しています。主な例として、Torのエコシステムがあります。
偏狭なTorユーザーは、既存の透明性サービスや立合人を信頼しないかもしれませんし、これらの機能をセルフホストするためのリソースを持つ信頼できる当事者が他にいないかもしれません。このユースケースでは、ブロックチェーンのどこかにプレフィックスツリーを設置することが合理的かもしれません。これにより、通常のドメイン検証は不可能になります（バリデーターサーバーが存在しない）が、オニオンサービスにとってはこれで問題ありません。オニオンアドレスはパブリックキーに過ぎないので、署名はドメインの所有権を証明するのに十分です。
コンセンサスに基づくプレフィックスツリーの結果として、証人は不要で、単一の正規の透明性サービスだけが必要になります。これにより、更新の遅延が犠牲になり、ツリーの不整合の問題はほぼ解決します。
私たちはまだ、標準化プロセスの非常に初期段階にあります。より直近の次のステップの1つは、より多くのデータタイプ、特にWASMとimagesでサブリソースの整合性を機能させることです。その後、整合性マニフェスト形式の標準化を始めることができます。その後、他のすべての機能を標準化して設定できます。私たちは、ブラウザやIETFと密にこの仕様に取り組む予定であり、近いうちにいくつかのエキサイティングなベータ版を提供できることを期待しています。
その間、弊社の透明性仕様草稿をご覧いただき、未解決の問題を確認し、お客様のアイデアを共有してください。プルリクエストや問題は、いつでも歓迎されます！
MozillaのDennis Jackson氏、デザインの打ち合わせが長時間にわたり行われたことと、FPFのGulio BとCory Myers氏に大いに感謝しています。