オリジン間ストレージ

1. はじめに

この節は非規範的である。

ストレージは通常、ユーザーのセキュリティとプライバシーを保護するためにオリジンごとに分割される。これは適切な 既定の動作だが、非常に大きく、広く利用され、一般に配布される一部の リソース（AI モデル、WebAssembly モジュール、JavaScript ライブラリー、ゲームエンジン、大きなウェブフォント）には適していない。 これらは、どのサイトが要求しても、バイト単位で同一のファイルである。2 つの 無関係なオリジンがそれぞれ同じ 8 GB のモデルに依存すると、オリジンごとに分割されたストレージにより、 ユーザーはそのモデルを 2 回ダウンロードして保持することになり、ユーザーの帯域幅、ストレージ、 バッテリー、さらにはネットワーク全体にとって無駄となる。

クロスオリジンストレージ（COS）は、コンテンツアドレス方式のキャッシュであり、URL ではなく暗号学的ハッシュを キーとする。これにより、ユーザーエージェントは、このようなリソースの保存済みコピー 1 つを、 利用を選択したオリジン間で共有できる。COS へのリソースの保存は、常に、 保存するオリジンによる明示的なオプトイン操作であり、ユーザーエージェントは、 本来なら読み取りが許可されるオリジンに対しても、そのリソースの存在の確認を差し控えてよい。§ 8 プライバシーと セキュリティに関する考慮事項を参照。

この仕様のエントリーポイントは、getFileHandle() メソッドであり、crossOriginStorageを通じて公開される：

const hash = {
  algorithm: 'SHA-256',
  value: '8f434346648f6b96df89dda901c5176b10a6d83961dd3c1ac88b59b2dc327aa4',
};
try {
  const handle = await navigator.crossOriginStorage.getFileHandle(hash);
  const file = await handle.getFile();
  // ファイルを使って何らかの処理を行う。
} catch (err) {
  if (err.name === 'NotFoundError') {
    // クロスオリジンストレージ内に（開示可能な形で）存在しないため、代わりにネットワークからフェッチする。
  }
}

この仕様は、FileSystemFileHandle、 FileSystemWritableFileStream、 および関連する 基盤を、ファイルシステム標準 [FS]から再利用する。その適用範囲は専用のファイルシステムであり、 オリジン間で共有され、各オリジンの非公開またはユーザーに見えるファイルシステムとは別個のものである。

この仕様は、命令的な JavaScript API と、ホストへの統合の基盤となる共有の保存手順を 定義する。関連する提案は、同じ基盤のキャッシュを他のホスト仕様に統合するものであり、 HTML の crossoriginstorage 属性を link および scriptに追加するもの、 また、 crossOriginStorage JavaScript インポート属性、CSS の cross-origin-storage() <request-url-modifier>、および crossOriginStorage という RequestInit オプションを fetch()に追加するものがある。それぞれは、 各ホスト仕様で定義される。§ 9 他の仕様との 統合を参照。

2. 概念

2.1. ハッシュ

COS ハッシュは、構造体であり、 次の項目を持つ：

アルゴリズム

文字列であり、 [WEBCRYPTO]が認識する「SHA-1」以外のハッシュアルゴリズムの名前を表す。例えば、 「SHA-256」である。

値

文字列であり、小文字の 16 進数で符号化されたダイジェストを表す。このダイジェストは、 アルゴリズムにより生成される。 「SHA-256」の場合、長さは 64 文字である。

algorithm 辞書メンバーの型は、単純な DOMStringである。その値の範囲は、[WEBCRYPTO]の ハッシュアルゴリズムが受け付ける名前の集合と厳密に一致するが、この型を用いる。HashAlgorithmIdentifier は (object or DOMString)であり、その object 分岐は、 [WEBCRYPTO]により Algorithm 形式の 辞書に正規化され、呼び出し元が追加の パラメーターを必要とするアルゴリズムに渡せるようにする（例えば、{name: "HMAC", hash: "SHA-256"}）。ハッシュ アルゴリズムはそのようなパラメーターを取らず、 アルゴリズムは、保存され、 比較され、往復の変換を経る。その際には、コンテンツアドレス方式の キーの一部となり、この仕様の 例における使用箇所はすべて単純な文字列である。ここで任意のオブジェクトを許容しても、機能は増えず、 等価性と直列化を 不必要に複雑にするだけである。したがって、DOMStringが、 このフィールドに対してより限定的で、より適切な型となる。

2 つのCOS ハッシュ値が等しいのは、それらのアルゴリズムの 値が、ASCII 大文字・小文字を区別せず一致し、それらの値が厳密に 等しい場合である。

注: 値は、規範上すでに小文字である（上記を参照）。したがって、その比較は、 単純な 文字列比較となる。アルゴリズムには、規範的に定められた文字の大小がないため、 ASCII 大文字・小文字を区別せず比較される。

コンテンツアドレス方式の ストアとは、そのエントリーのキーが、 等価性によって決まるものであり、比較対象はCOS ハッシュである。2 つのファイルの バイト列が同一であり、ハッシュアルゴリズムが同じであれば、それらを保存したオリジンの数や、 フェッチ元となった URL の数にかかわらず、同じエントリーとなる。

2.2. COS エントリー

COS パーティションは、ある 環境設定オブジェクト settingsに対し、次を行った 結果である： サイトを取得する処理を、settingsのトップレベルオリジンから行う。settingsが ファーストパーティ COS コンテキストであるのは、サイトを取得する処理を、 settingsのオリジンから行った結果が、同一 サイトとなる場合であり、その比較対象は自身のCOS パーティションである。

COS アクセス許可は、構造体であり、 次の項目を持つ： オリジンは、オリジンであり、パーティションは、 COS パーティションであり、 その許可を追加した書き込みのものである。また、ファーストパーティは、 真偽値であり、 その書き込みが、ファーストパーティ COS コンテキストで実行されたかどうかを記録する。許可は、 読み取りのCOS パーティションが、 同一サイトとして自身のパーティションと一致する読み取りに適用される。 COS の開示を 決定するを参照。

各ユーザーエージェントは、単一のCOS レジストリーを持つ。これは、マップであり、COS ハッシュ値から、 COS エントリーという構造体への対応を表し、 クロスオリジンストレージを利用するすべてのオリジンで共有される。 COS エントリーは、次の項目を持つ：

ハッシュ

COS ハッシュ。

バイト列

バイト列であり、そのダイジェストは、ハッシュのアルゴリズムを用いると、 ハッシュの値と等しくなる。

注: エントリーがCOS レジストリーに追加されるのは、 書き込み元がこれらのバイト列を提供し、 ユーザーエージェントがそれらを検証した後に限られる。検証して保存するを参照。要求されたが 完了していない書き込みは、レジストリーにはまったく表現されない。このため、進行中の 書き込みは、読み取り経路では存在しないものと区別できない。§ 8.3 進行中の書き込みを参照。

オリジン群

リストであり、COS アクセス許可を格納し、明示的な、 クロスオリジンの読み取りアクセスを付与する。これは、 公開ハッシュ リストとは独立している。各許可は、すべてのオリジンに及び、その範囲は、同一サイトとなるものであり、比較対象は自身の オリジンである。したがって、 https://a.exampleを列挙すると、https://www.a.exampleも許容される。 許可のファーストパーティが true の場合、その許可は、 ファーストパーティ COS コンテキストの読み取り元にも、任意のトップレベルサイトの下で適用される。 初期状態では空であり、その後は 増加するだけである。これは、 エントリーを誰が読み取れるかを決定する、独立した加算的な 3 つの許可のうちの 1 つであり、 残りの 2 つは、その保存したオリジン群（常に読み取り可能であり、それらと オリジンが 同一サイトとなるものも含む）と、グローバルに 開示可能である。

注: 書き込みのorigins が明示的な空の リスト （origins: []）である場合に付与する許可は、 origins を省略した書き込みが付与する許可と厳密に同じである。すなわち、エントリーの 保存したオリジン群と、それらと同一サイトとなるオリジンであり、すべてのエントリーが持つ基本の許可である （COS の開示を決定するを参照）。上限を 適用する 処理は、空のリストを null に変えるため、どちらの書き込みも、 作成要求を完了するの残りの処理へ同じ状態で到達する。 明示的なリストは、受信先を追加するだけであり、 書き込み元自身のサイトからエントリーを隠すことはない。

グローバルに開示可能

真偽値であり、初期値は false で、エントリーの書き込み時に要求されたかどうかを記録する。 その要求とは、 グローバルな（「*」）利用可能性である。true の場合、エントリーは、要求が § 8.4 利用可能性の制御を通過する任意のオリジンから読み取り可能となる。すなわち、ハッシュがPHL に掲載されており、かつ、 GREASE の適用によって抑制されない場合である。一度設定されると、true のままとなる。

注: これは、別個の項目であり、オリジン群とは分離されている。これにより、 後からの グローバルな利用可能性の要求は、「*」の許可を既存の明示的な オリジン群のリストに追加する。 両者を 1 つのフィールドに混同した場合、 バイト列を提供した書き込み元が、リストを範囲とするエントリーを「*」を範囲とするものに変えられてしまう。§ 8.4 利用可能性の制御は、 「*」の許可にのみ適用されるため、以前はエントリーを読み取れたオリジンでも、その根拠となる リストに基づく読み取りで、 以後は「NotFoundError」 を受け取るようになる。その条件は、ハッシュが、 次に該当しない場合は常にである： PHL に掲載されている。許可を 独立させることで、可視性の変更はすべて厳密に加算的となり、 これは、昇格可能だが決して降格不可能という性質が 要求するものである。

保存したオリジン群

集合であり、COS アクセス許可を格納する。各オリジンとCOS パーティションの組み合わせごとに 1 つ存在し、そのパーティションの下で、 そのオリジンが、このエントリーのバイト列の書き込みを少なくとも 1 回正常に完了している。 それらのファーストパーティは関与しない。ページの読み込みをまたいで保持され、 その後も、 増加する。§ 5.2 追い出しに記述される場合を除き、減少しない。許可の オリジンは、 常にエントリーのハンドルを取得できる。そのために、 getFileHandle() を、許可のパーティションの下で利用でき、 これは、オリジン群や、エントリーのハッシュが、 公開ハッシュリスト（PHL）に掲載されているかどうかとは独立している。§ 3.5.1 元の保存者によるアクセスを参照。

注: 許可のキーをトップレベルサイトとすることで、 埋め込みフレームが得る クロスオリジンストレージの見え方は、ストレージの分割による他のストレージの見え方と同じになる。このキーがなければ、 複数のサイトに埋め込まれたフレームが、あるサイトで小さなファイルを書き込み、別のサイトでそれらを読み戻せてしまう。 その際には保存したオリジンとして振る舞うことで、公開ハッシュリスト、GREASE の適用、 およびあらゆる 検索回数制限を回避でき、これはサードパーティ Cookie に相当する。トップレベルでの書き込みにもキーを付けるため、 追跡者がトップレベルの訪問中に一度書き込んだものを、あらゆる場所のフレームから読み戻すことはできない。 オリジン群の許可が、 ファーストパーティ COS コンテキストから与えられた場合は、ファーストパーティとしても、 任意のトップレベルサイトの下で適用されるため、トップレベルサイト間の制限付き共有は引き続き機能する。グローバルに開示可能にはキーを付けない。 これは、公開ハッシュリストと GREASE の適用が、すでにそれを制御しているためである。

ユーザーエージェントは、関連付けられたクロスオリジンストレージキューを持ち、これは、 新しい並列キューを開始することによって得られる。COS レジストリーに対するすべての操作は、 キューに入れなければならず、その対象はこのキューである。これにより、 キューに 入れられた順序で実行され、互いに処理が入り交じることはない。

2.3. 公開ハッシュリスト

クロスオリジンストレージにハッシュが存在することを確認する行為自体が、 ユーザーの閲覧履歴に関する情報を漏らす可能性がある（§ 8.2 クロスサイトの探索を参照）。これは、 グローバルな 許可に特有のリスクである。エントリーの明示的なオリジン群のリストと、同一サイトに対する基本の許可は、すべての エントリーに 存在し、保存するオリジンの明示的な選択によって、すでに開示範囲が制限されている。一方、 エントリーをグローバルに開示可能にすると、ウェブ上の任意の オリジンに公開される可能性がある。この 特有のリスクを制限するため、グローバルに開示可能なリソースは、開示される場合でも、 その 許可を通じて、自身の保存したオリジン群以外のオリジンに開示できるのは、そのハッシュが追加の、 独立した条件を通過する場合に限られる。その条件とは、公開ハッシュリスト （PHL）への掲載であり、これは、ベンダー中立の、実装定義の許可リストであって、COS ハッシュの 値を含む。ハッシュが公開ハッシュリストに追加されるのは、k-匿名性に類似した 普及度の基準を満たした後に限られる（例えば、バイト単位で同一のものが、所定の最小数以上の独立した オリジンに現れること）。これにより、共有キャッシュ内での存在の確認が、 個々のユーザーに関する情報を与えないようにする。

COS ハッシュ hashが、公開ハッシュ リストに掲載されているとは、hashが、 等しいエントリーを、ユーザー エージェントの現在のスナップショット内に持つことであり、その対象は公開ハッシュリストである。

取得プロトコル、 更新頻度、データ形式、普及度のしきい値、およびガバナンスについて、 公開ハッシュリストの設計は、この仕様の付随成果物として詳細に定められている。これは、 パブリックサフィックスリストという、[URL] 標準の付随データファイルにならったものである。 このリポジトリー内の公開ハッシュリストの解説を参照。その設計は、 WHATWG によるガバナンスを提案しており、パブリックサフィックスリストの複数ベンダーによる 継続的リリースの先例をモデルとし、独立に裏付けられた普遍性に基づく追加基準を設けている。 これは、上記の k-匿名性に類似した基準の具体例であり、一度だけ、オフラインで、 ハッシュの追加手続きの一部として適用されるため、ユーザーエージェントがクエリーごとに繰り返すことはない。これらはいずれも、 この提案の外では、まだ確立されていない。リスト自体の初期段階の非規範的なコードプロトタイプは、 現在、このリポジトリー内の、 public-hash-list/implementation/に置かれている。専用の、 複数ベンダーによるリポジトリーは、引き続き PHL の解説に記述されたガバナンス上の目標である。この 仕様が依存するのは、ハッシュがPHL に掲載されているかどうかだけであるため、 リストの取得機構、ガバナンスモデル、その他の設計がどのように発展しても、正しさは保たれる。

3. CrossOriginStorageManager インターフェース

[Exposed=(Window,Worker), SecureContext]
interface CrossOriginStorageManager {
 Promise<FileSystemFileHandle> getFileHandle(
   CrossOriginStorageGetFileHandleHash hash,
   optional CrossOriginStorageGetFileHandleOptions options = {});
};

dictionary CrossOriginStorageGetFileHandleHash {
 required DOMString value;
 required DOMString algorithm;
};

dictionary CrossOriginStorageGetFileHandleOptions {
 boolean create = false;
 (DOMString or sequence<DOMString>) origins;
};

interface mixin NavigatorCrossOriginStorage {
 [SameObject, SecureContext] readonly attribute CrossOriginStorageManager crossOriginStorage;
};
Navigator includes NavigatorCrossOriginStorage;
WorkerNavigator includes NavigatorCrossOriginStorage;

各Navigator およびWorkerNavigator オブジェクトには、CrossOriginStorageManager オブジェクトが関連付けられる。crossOriginStorage getter の 手順は、 次を返すことである：thisに関連付けられたCrossOriginStorageManager。

各CrossOriginStorageManager オブジェクトには、オリジンが関連付けられ、次に設定される： thisの関連する設定オブジェクトのオリジン。また、関連付けられた パーティションは、COS パーティションに設定される。その対象は、thisの 関連する設定オブジェクトであり、設定はオブジェクトの作成時に行われる。

注: オリジンを関連する設定オブジェクトから取得し、 スクリプト自体に関する事柄とは独立させることは、ワーカーについて明記すべき結果をもたらす。 blob: URL から作成されたワーカーは、オリジンとして、作成元のコンテキストのものを持つため、そのオリジンの クロスオリジンストレージの見え方を完全に共有する。すなわち、そのワーカーが書き込んだものを作成元のページが読み戻すことができ、 ページが保存したものをワーカーが読み取ることができる。blob: URL 自体が独自のオリジンを持つわけではなく、 それを失効させても、ワーカーはその見え方から切り離されない。data: URL から作成されたワーカーは、 不透明なオリジンを持つ。この仕様は、現時点では、 getFileHandle() の動作を、呼び出し元のオリジンが不透明な場合について定義していない。 COS 要求を検証するのオリジン規則が制御するのは、 呼び出し元が指定するオリジンだけである。不透明なオリジンには、キーに使える安定した識別情報がなく、 保存した オリジン群や、同一 サイトかどうかの比較に使えないため、 それに付与して意味のある許可は存在しない。

3.1. getFileHandle() メソッド

3.2. ファイルの読み取り

3.3. ファイルの作成と書き込み

FileSystemFileHandleが、 作成要求を完了する処理によって作成された場合、関連付けられた、 要求されたオリジン群を持つ。これは、検証して保存する処理が、 エントリーを昇格する際に、そのオリジン群に適用しようとする値であり、 ハンドルを通じた書き込みが正常に完了した後に適用を試みる。

すべてのFileSystemFileHandleが、 クロスオリジンストレージファイルシステムを指し示す場合、さらに、 関連付けられたCOS ハッシュを持ち、これは、COS ハッシュのうち、そのハンドルが指し示すものである。また、 関連付けられた、 COS オリジンは、オリジンのうち、そのハンドルを取得したものである。さらに、 関連付けられた、 読み取り可能という真偽値は、 getFile() が、その特定のハンドルを通じて、指し示されたエントリーのバイト列を開示できるかどうかを 制御する。この値は、読み取り要求を完了する処理から返されるハンドルでは true となる。それは、すでに、 利用可能性の制御を通過しているためである。一方、 作成 要求を完了する処理から返されるハンドルでは、検証して保存する処理がその同じハンドルについて成功するまで、false となる。

注: ハンドルが指し示すのは、COS ハッシュであり、COS エントリーではない。作成要求を完了する処理は、 ハッシュに対するハンドルを返すが、そのハッシュは、COS レジストリーにエントリーを持たず、今後も持たない可能性があるため、 参照先のエントリーが存在するのは、検証して保存する処理がそれを作成した後である。

注: これは、意図的にハンドルごとのプロパティとしている。 作成要求は、 ハッシュのエントリーがすでに存在するかどうかにかかわらず、ハンドルを返す（ 作成 要求を完了するを参照）。したがって、エントリーごとの規則にすると、任意のオリジンが、 getFileHandle() を、 create: true で呼び出して、エントリーを直ちに読み取れてしまう。 自身が書き込んだことのないエントリーの内容を、オリジン群、 PHL への掲載、またはGREASE の適用の条件を満たさずに知ることになる。この 仕様におけるすべての開示制御は読み取り経路に適用されるため、エントリーごとの制御では、作成要求が、 それらをすべて回避できてしまう。呼び出し元に、まず正しいバイト列の提供を要求することにより、 作成要求で取得したハンドルを通じた読み取りが成功しても、呼び出し元がすでに持っていたもの以外は開示されない。

FileSystemWritableFileStreamが、 次を呼び出して取得された場合： createWritable() の呼び出し先のハンドルのロケーターが、 クロスオリジンストレージファイルシステムを指し示すものとする。そのストリームが閉じられるとき、[FS]に従い、ユーザーエージェントは、 次の、 検証して保存する手順を、 そのハンドルを指定して実行しなければならない。これは、その終了操作の Promise が、 履行される前に行う。

注: これは、終了を引き起こした方法に、 かかわらず適用される。明示的な、 close() の呼び出し、または、pipeTo() の呼び出しが、その、 ソースの末尾に達した場合であり、後者も、既定では宛先を閉じる。[STREAMS]は、ストリームが閉じられた状態になる、 時点で両者を区別せず、このアルゴリズムも同様である。

createWritable() が、FileSystemFileHandle に対して呼び出され、その指し示す先が、 クロスオリジンストレージファイルシステムである場合、生成しなければならないのは、FileSystemWritableFileStreamであり、 その内容は、 初期状態で空でなければならない。これは、keepExistingDataの値に、 かかわらず、 また、指し示されたCOS ハッシュが、COS レジストリーにエントリーを持つかどうかにかかわらず、適用される。

注: [FS]は、それ以外の場合、keepExistingData を、初期データとして、 既存のファイルの内容をストリームに与えるものと定義する。ここでそれに従うと、呼び出し元は、自身が一度も保有したことのないバイト列について、 保存したオリジンになれてしまう。作成要求は、エントリーが、 すでに存在するかどうかにかかわらずハンドルを返すため、呼び出し元は、別のオリジンが保存したハッシュに対する書き込み可能ストリームを開き、 何も書き込まずに閉じ、引き継がれたバイト列を、要求された値にハッシュさせることができる。これは、 読み取りアクセスを付与することになり、オリジン群、公開ハッシュリスト、および、 GREASE の適用は、一度も参照されない。すなわち、利用可能性の 制御の回避が、 個別には許容される 2 つの操作を組み合わせて成立してしまう。同じ理由により、 検証して保存する処理は、 すべての作成要求に対して、内容全体を要求する。

注: したがって、何も書き込まずに閉じた書き込み可能ストリームは、 空のバイト列を保持する。それは、 呼び出し元が求めるようなエントリーの要求値にはハッシュされないため、検証して保存する処理は、 「DataError」 DOMException で拒否する。これは、他のあらゆる不一致の場合と同じである。実装が、 その場合に、代わりにストレージまたは I/O の失敗を報告すると、検証結果を、 無関係なエラーの背後に隠すことになる。

ファイルシステム標準 [FS]は、現時点では、拡張ポイントを、 それに依存する、 仕様が、書き込みごとの追加検証を、FileSystemWritableFileStreamの、 終了手順に組み込むために定義していない。そのようなフックが存在するまでは、この節が、要求される動作を直接記述する。 将来の改訂では、正式に、[FS]と統合することが想定される。

3.4. フェッチしたリソースの保存

§ 9 他の仕様との 統合に列挙されたホストへの統合は、 フェッチしたリソースを、FileSystemFileHandleを経由せずに保存する。 それらのホスト仕様は、 フェッチしたバイト列が、その統合で要求される完全性検査を、 通過した後で、次のアルゴリズムを実行することが想定される。

注: 検証して保存する処理と同様に、保存には常に、 バイト列全体が必要であり、これは、 エントリーがすでに「written」であっても変わらない。したがって、以前からの存在について何も明かさない。統合による、 検索は、 ネットワークからのフェッチの前に行われる読み取りであり、利用可能性の制御と、 § 8.2 クロスサイトの探索における探索に関する考慮事項に従う。

3.5. リソースの可視性の昇格

COS エントリーの可視性は、 昇格できるが、決して降格できない。

注: 昇格によって行われるのは、オリジン群への追加か、グローバルに開示可能を、 true に設定することだけである。書き込み元がリストを要求すると、すでに、 グローバルに開示可能なエントリーも、そうでないエントリーと同様に、 範囲が拡張される。これは、2 つの許可が、 独立しているためである。新たに列挙されたオリジンは、PHLから独立したアクセスを得る。その間も、 「*」の許可は有効なままである。

注: 元の保存者以外のサイトを含む、任意の、 サイトが、エントリーの、 オリジン群を拡張できる。ただし、 バイト列も提供し、そのハッシュがエントリーのハッシュと一致する必要がある。これは意図的なものである。 あるハッシュに対する正しいバイト列をすでに保有するサイトは、その仕組み上、 そのハッシュが何を表すかについて、元の保存者と同等の権威を持つ。

3.5.1. 元の保存者によるアクセス

オリジンが、正常に完了した処理として、書き込みを行い、その対象が、COS エントリーである場合（すなわち、 そのオリジンが、 エントリーの保存したオリジン群に含まれる任意の許可のものである場合）、常に、 その後、次を通じて、そのエントリーのハンドルを取得できる：getFileHandle()。 取得は、 同じトップレベルサイトの下で行い、これは、エントリーのオリジン群の値とは独立しており、また、 そのハッシュが、PHL に掲載されているかどうかとも独立している。これは、Cache API のモデルに対応しており、そのモデルでは、 オリジンは、自身が保存したものに常にアクセスできる。また、ストレージの分割により、Cache API も、トップレベルサイトをキーとする。他のトップレベルサイトの下では、そのオリジンは、エントリーを、 他のオリジンと同様に読み取る。

4. クロスオリジンストレージファイルシステム

クロスオリジンストレージファイルシステムは、ファイルシステムルートであり、どの オリジンのバケットファイルシステムやローカルファイルシステムへのアクセスルートとも異なる。その エントリーは、COS レジストリーのCOS エントリー項目と一対一で対応する。

クロスオリジンストレージファイルシステムは、[FS]の通常の、呼び出しごとの 許可確認 モデルを使用しない。すべてのFileSystemFileHandleは、 そこから取得される場合、すでに完全に認可されている。その認可は、 § 3.2 ファイルの読み取りまたは§ 3.3 ファイルの作成と 書き込みによって、スクリプトに返される前に行われるため、 getFile() またはcreateWritable() を、そのようなハンドルに対して呼び出しても、 追加の許可プロンプトが表示されることはない。

したがって、このようなハンドルに対するqueryPermission()およびrequestPermission()は、決して次の値を 報告してはならない： 「prompt」。プロンプトが表示されることはないためである。書き込みモードでは、「denied」を報告しなければならない。その対象は、 ハンドルのうち、 作成要求によって取得されていないものである。また、 「granted」 を、それ以外の場合に報告しなければならない。

createWritable() を、FileSystemFileHandle に対して呼び出す際、そのハンドルが、 クロスオリジンストレージファイルシステムを指し示し、 取得元が、 作成要求でない場合、その呼び出しは「NotAllowedError」 DOMExceptionで拒否しなければならず、 その際、FileSystemWritableFileStreamを作成してはならない。

注: 書き込みは、ハンドルが 実際に持たない場合のある唯一の機能である。作成要求だけが、 書き込みに使用できるハンドルを返すため、他のハンドルの書き込みモードについて「granted」と報告すると、 機能があると主張することになるが、createWritable() はそれを拒む。読み取りは、 「granted」のままである。読み取り可能なハンドルを保持する呼び出し元は、それを通じて読み取れるためである。許可を要求しても、 変えることはできない。 表示するプロンプトも、許可を記録できる状態も存在しないため、どちらの回答も変わらない。

getFile() を、FileSystemFileHandle に対して呼び出す際、そのハンドルが、 クロスオリジンストレージファイルシステムを指し示し、その読み取り可能が false である場合、拒否しなければならない。 その理由は、「NotAllowedError」 DOMExceptionとする。 これには、次の 2 つの異なる場合が含まれる：

• 作成要求から取得したハンドルで、まだ書き込みが 完了して おらず、指し示すハッシュのエントリーが、COS レジストリーに存在しない場合。返すための検証済みバイト列が 存在せず、呼び出し元は、自身の未完了の書き込みを、 ファイルの実際の内容であるかのように観測できてはならない。

• 何らかの他のオリジンがすでに書き込んだハッシュに対する、作成要求からのハンドル。 検証済みの バイト列は存在するが、この呼び出し元はそれを提供しておらず、また、 利用可能性の制御を通過していないため、エントリーについて何も知ることができてはならない。 それには、 存在するかどうかすら含まれる。

注: 拒否の内容は、どちらの場合も同一であるため、 何も開示しない。このため、 「NotAllowedError」 は、読み取り経路では意図的に避けられているにもかかわらず、ここでは安全である。このハンドルは、 呼び出し元自身の作成要求によって取得した、自身のものであり、ハンドルは、いかなる 他のオリジンでも逆シリアル化できない（§ 4.1 ハンドルの転送を参照）。したがって、その回答は、 オリジンの境界を越えることがなく、 レジストリーの内容に対して一定である。§ 8.3 進行中の書き込みとは異なり、そこで、 読み取り経路に別個のエラーがあれば、その境界を越えてしまうことになる。

ハンドルの読み取り可能が true になると、getFile() をそのハンドルに対して呼び出すことで返されるのは、Fileであり、 その内容は、指し示されたエントリーのバイト列となる。これは、 [FS]が、 すでに定義する動作と厳密に同じであり、その対象は、ファイル エントリーのうち、 バイナリーデータが、それらのバイト列であるものである。

FileSystemFileHandleが、 クロスオリジンストレージファイルシステムを指し示す場合、その ファイルシステムロケーターのパスは、リストであり、含まれるのは、 単一の 文字列である。それは、自身のCOS ハッシュの値であり、また、 ルート は、クロスオリジンストレージファイルシステムとなる。

注: [FS]は、nameを、 ハンドルのロケーターのパスにおける、 最後のパス成分として定義するため、これにより、nameも定まる： その値は、 ハッシュである。エントリー自体は名前を持たず、ハッシュだけがその識別情報であるため、 それを報告することで、空文字列では捨てられてしまう情報が伝わる。

エントリーには名前も、それを含むディレクトリーもないため、[FS]の構造に関するインターフェースの大部分には、 操作対象がない。同一性は例外であり、これは、コンテンツアドレス方式のエントリーが、 常に答えられる唯一の問いである。COS レジストリーが保持するCOS エントリーは、COS ハッシュごとに高々 1 つであるため、2 つの ハンドルが同じエントリーを指し示すのは、それらのハッシュが等しい場合に限られる。

isSameEntry() を、FileSystemFileHandle に対して呼び出す際、そのハンドルが、 クロスオリジンストレージファイルシステムを指し示し、引数も、 それを指し示すものであり、取得元が、 同じオリジンである場合、2 つのハンドルの、 COS ハッシュ項目が、等しい場合は true、それ以外は false を返さなければならない。

注: これを拒否すると、ユーザー エージェントがすでに保持している情報を捨てることになる。

isSameEntry() を、FileSystemFileHandle に対して呼び出す際、そのハンドルが、 クロスオリジンストレージファイルシステムを指し示し、引数が、 呼び出し元のオリジンが取得したものでない場合、または、 次のもの以外のファイルシステムを指し示す場合：クロスオリジンストレージファイルシステム、その呼び出しは、拒否しなければならない。 その理由は、「NotAllowedError」 DOMExceptionとする。 別のファイルシステムを指し示すハンドル、例えば、 次が、 getDirectory() 返すものについては、[FS]が定義する動作を保持する。その呼び出しの引数が、 FileSystemFileHandle であり、それが、クロスオリジンストレージファイルシステムを指し示す場合も同様である。

注: その場合に false を返すと、 2 つのハンドルが異なるエントリーを指し示すと断言することになり、 これは、呼び出し元オリジンに調べる権利がないハンドルについての主張となる。拒否が述べるのは、 比較を行えなかったということだけである。

move()およびremove()を、 FileSystemFileHandle に対して呼び出し、そのハンドルが、クロスオリジンストレージファイルシステムを指し示す場合、次の例外で拒否しなければならない： 「NotAllowedError」 DOMException。 また、指し示されたエントリーを変更してはならない。

注: エントリーは、自身の保存した オリジン群に含まれるすべてのオリジンで共有されるため、 削除を実行すると、あるサイトが、他のサイトが依存するデータを破壊できてしまう。削除は、 追い出しおよびユーザー自身のストレージ制御が行う。名前の変更や親の変更には、 操作対象がない。エントリーは、自身のCOS ハッシュによって命名され、それを含むディレクトリーが存在しないためである。

注: どちらのメソッドも、[FS]や File System Access API では、執筆時点で定義されていない （WICG/file-system-access#214）。 したがって、エラー名は、removeEntry()に従う。 これは、[FS]が、 エントリーを削除するために定義する操作であり、読み書きアクセスが、 許可されない場合、アクセス結果のエラー名で拒否する。ここでは、拒否することが正確な動作である。これらの操作には意味があり、 その操作が許可されないためである。

createSyncAccessHandle() については、ここで規則を設ける必要はない。その手順は、次の例外で拒否する： 「InvalidStateError」 DOMException。 その条件は、ハンドルが、バケットファイルシステム内にない場合である。 また、クロスオリジンストレージファイルシステムは、ファイルシステムルートであり、どのオリジンのものとも異なるため、 [FS]が、すでに、 拒否することと、そのエラー名の両方を決定している。

注: これは、この仕様が、それとは独立に、 求める結果でもある。 FileSystemSyncAccessHandle は、書き込み可能なファイル記述子を呼び出し元に渡すため、 エントリーのバイト列を変更できてしまう。 そのバイト列は、COS ハッシュに対応付けて、 保存されているにもかかわらず、変更されることになり、 そのエントリーの開示先となる他のすべてのオリジンも、同じバイト列を読み取る。

4.1. ハンドルの転送

FileSystemFileHandle は、シリアル化可能なオブジェクトであるため、[FS]に従い、 COS エントリーを指し示すものも、別の環境設定オブジェクトへ渡せる。例えば、 postMessage(message, options)を使用できる。 これは、このようなハンドルを取得する 2 つ目の方法であり、 getFileHandle()と並ぶものであるため、 ここでも制約を設ける。

シリアル化手順は、FileSystemFileHandle が、次を指し示す場合、 クロスオリジンストレージファイルシステム、 valueおよび serializedを指定して、追加で次を行う：

1. serialized.[[COSHash]] を、valueのCOS ハッシュに設定する。

2. serialized.[[COSOrigin]] を、valueのCOS オリジンに設定する。

3. serialized.[[COSMayRead]] を、valueの読み取り可能に設定する。

逆シリアル化手順は、serialized、 valueおよび realmを指定して、追加で次を行う：

1. serialized.[[COSOrigin]] が、同一オリジンとして realmの、 環境設定オブジェクトのオリジンと一致しない場合、次の例外を送出する： 「DataCloneError」 DOMException。

2. valueのCOS ハッシュを、serialized.[[COSHash]] に設定する。

3. valueのCOS オリジンを、 serialized.[[COSOrigin]] に設定する。

4. valueの読み取り可能を、 serialized.[[COSMayRead]] に設定する。

注: 同一 オリジンの確認がなければ、転送によって、 この仕様のすべての開示制御が一度に無効化されてしまう。ハンドルの読み取り可能が true である場合、 そのハンドルは、すでに、 利用可能性の制御を適用する処理を、それを要求した オリジンについて通過している。それを別の オリジンへ送信すると、そのオリジンにエントリーのバイト列を渡すことになり、オリジン群、 PHL への掲載、またはGREASE の適用を、そのオリジンについて一度も評価しないことになる。これは、 ファイルシステム標準の既存のハンドルの扱いと一致しており、そこでも、ハンドルが役に立つのは、 同一オリジンの受信先に限られる。

注: 読み取り可能は、 ハンドルとともに移動するため、書き込みを完了していない作成要求のハンドルは、 転送後も読み取り不可能のままであり、 読み取り要求のハンドルは、再度の制御を受けずに読み取り可能なままとなる。到着時に制御を再適用すると、 呼び出し元が、同じハンドルを転送することで、 利用可能性を繰り返し探索できてしまう。

5. ストレージ管理

5.1. ストレージの制限

ユーザーエージェントは、オリジンが追加できるバイト数の合計に、上限を設けなければならない。その追加先は、 COS レジストリーであり、成功した書き込みを通じて追加される。これは、 単一のオリジンが、 他のオリジンのエントリーを追い出そうとして、キャッシュを大量のデータで埋め尽くすことを防ぐためである。具体的な上限は、 実装定義である。オリジンの書き込みが、自身の、 上限を超える場合、ユーザーエージェントは、 拒否する対象を、 その書き込みとし、その理由を「QuotaExceededError」 DOMException としなければならず、警告を、 コンソールに記録すべきである。

注: エントリーは、コンテンツアドレス方式であるため、オリジンが、 同じ、 バイト列を同じハッシュで繰り返し書き込んでも、最初の書き込みが成功した時点を超えて、追加の割り当て量を消費しない。 § 2.2 COS エントリーを参照。

ユーザーエージェントは、さらに、実装定義のオリジンリストの最大長を持つ。これは、 正の整数であり、含められるオリジンの数について、単一のオリジン群のリストが、 包含できる数を制限する。これは、リストが最初に提供されるとき（COS 要求を検証するを参照）と、 後から既存のエントリーに統合されるとき（ リソースの可視性を昇格するを参照）の両方で適用される。これにより、単一の呼び出しでも、 長期間にわたる多数の呼び出しの累積効果でも、エントリーのオリジン群を、 無制限に増やすことはできない。これは、メモリー使用量の制限に加えて、 リストに含まれるオリジン群が、 暗黙の、 「*」の代替として使われることも防ぐ。§ 8.2 クロスサイトの探索を参照。

この上限を超えた場合の処理は、その 2 箇所で異なる。これは、2 つの呼び出しが、 操作の中で、まったく異なる時点に行われるためである：

• COS 要求を検証する処理では、上限の確認は、どの、 ファイルについても、フェッチ、ハッシュ計算、または、 書き込みを行う前に実行される。上限を超えた呼び出し元は、直ちに「TypeError」 を受け取り、それ以外は何も起こらない。 これは、他の形式不正なorigins 値と同じ扱いである。

• リソースの可視性を昇格する処理では、上限に達するのは、 累積効果による場合だけである。その対象は、 別個の独立した書き込み呼び出しで要求されたオリジン群であり、無関係なオリジンが、 長期間にわたって要求する場合もある。また、上限が確認されるのは、この呼び出しのバイト列のハッシュ計算、 検証、および永続的な保存が完了した後だけである。その時点で書き込みを拒否すると、成功し、 検証も済んだ、場合によっては非常に大きな書き込みを、無関係な管理上の上限によって破棄することになり、 しかも、単一の呼び出し元の誤りに帰せるとは限らない。したがって、書き込みは、 成功させ、上限を超えたオリジンだけを、オリジン群から除外し、 コンソールに警告を記録する。これは、既存の、 許容的な状態から、より制限された状態への要求の扱いに対応する。オリジンの要求を、 完全には満たせない場合、通知なしに上限で制限され、その要求を伴う書き込み自体は、 成功する。この仕様の他の箇所における§ 8.4 利用可能性の制御と、 同様に、 呼び出し元には、要求したオリジンが、 実際に追加されたかどうかを、後から確実に確認する方法はない。その後に、getFileHandle() を、その、 オリジンとして呼び出しても、オリジンが追加されていても失敗し得る（例えば、エントリーが、 追い出された場合や、ユーザーエージェントが要求を制限した場合）。したがって、その結果を、どちらであるかの確認として、 解釈してはならない。

5.2. 追い出し

この節は非規範的である。

ストレージ容量が逼迫した場合、ユーザーエージェントは、エントリーを、COS レジストリーから追い出してよい。 例えば、最も長い間使われていないものを優先する方針を、保存したオリジン群のうち、 各エントリーに最後にアクセスしたものについて適用できる。ユーザーエージェントは、設定 UI を提供し、 ユーザーが、保存されているファイル、各ファイルにアクセスしたオリジンを確認し、手動で、 エントリーを削除したり、クロスオリジンストレージのすべてのデータを消去したりできるようにすることが想定される。

ユーザーが、あるオリジンのサイトデータを消去するとき、ユーザーエージェントは、その許可の、 オリジンが、そのオリジンであるものをすべて、 各保存したオリジン群の集合から削除すべきである。その削除後に、COS エントリーの、 保存した オリジン群が空となった場合、ユーザーエージェントは、そのエントリーの削除を検討してよい。

5.3. 手動で追加されたエントリー

この節は非規範的である。

上記の設定 UI は、ユーザーが、すでにディスク上に持っているファイルを、直接、 クロスオリジンストレージに追加できるようにしてもよい（例えば、どのウェブサイトとも無関係にダウンロードした AI モデル）。 この操作では、スクリプトが一度も、getFileHandle()を呼び出す必要はない。 このようなエントリーには、 要求元のオリジンが存在せず、書き込みを帰属させることができないため、次の 2 つの問いが生じる。これらには、命令的な、 操作を行う、 API だけでは答えられない：

• 元の保存者は誰か。ここでの用途は、 § 3.5.1 元の保存者によるアクセスである。誰も該当しない。エントリーの保存したオリジン群は、初期状態で空である。 したがって、どのオリジンも、免除されない。 通常の利用可能性の制御と、オリジン群の確認は、 他の場合と同様、すべての要求元オリジンに適用される。これは正しい結果である。どのオリジンも、 実際にはそのバイト列を書き込んでいないためである。

• このようなエントリーを、同一サイトだけに制限すべきか。通常の書き込みで、 origins を省略した場合のようにするべきか。答えは否である。「同一サイト」は、 要求元オリジンとの関係においてのみ意味を持つが、手動の追加にはそれがないため、「同一サイト」の、 対象となるサイトは存在しない。ユーザーエージェントは、そのようなエントリーを、グローバルに 開示可能にすることが、 想定される。その明示的なオリジン群のリストは空のままとする。ファイルを手動で、 事前に配置することが、 その目的（ユーザーがまだ訪問していないサイトが、ユーザーがすでに、 ディスク上に持つファイルを再利用できるようにすること）を果たすのは、他のオリジンが実際にそのファイルを発見できる場合だけである。ユーザーエージェントの設定 UI は、 さらに、より狭い範囲をユーザーが選択できるようにしてもよい。

このように追加された後は、エントリーは、それ以外の点では区別できない。 ウェブサイトが、getFileHandle()を通じて書き込んだものと同じである： 同じ、 利用可能性の制御および可視性の 昇格の規則が適用される。これは、同じ許可を持つ他のエントリーとまったく同じである。 これには、PHL に掲載されていることの確認も含まれる。 その確認は、エントリーが、最終的に、 グローバルに開示可能となる場合に行われ、手動の追加では、これが既定となる。

5.4. 来歴メタデータ

この節は非規範的である。

COS エントリーは、意図的に、 そのバイト列がどこから来たかについて、何も記録しない。識別情報となるのは、 ハッシュだけである。同じバイト列は、 保存したオリジンの数や、 フェッチ元となった URL の数にかかわらず、同じエントリーとなる（§ 2.2 COS エントリーを参照）。URL は、 ある 1 つの、 書き込み元によるフェッチのプロパティであるため、エントリーに対して、恣意的でない方法で 1 つを選ぶことはできない。 複数のオリジンが書き込んだ場合には、特にそうであり、バイト列のように検証することもできない（§ 8.1 リソースの完全性を参照）。 また、ユーザーの閲覧について伝える情報は、粗い粒度のオリジン値が、 保存した オリジン群の中で伝えるものより、はるかに多い。パスやクエリー文字列は、特定の文書、 アカウント、またはセッションを指定できるためである。したがって、エントリーに記録すると、高エントロピーのシグナルが、 開示制限を回避して伝わることになる。その制限は、オリジン群および§ 8.4 利用可能性の 制御が課すために設けられたものである。

それでも、それを求める動機は実在する。複数ギガバイトのファイルを、 § 5.2 追い出しに記述された設定 UI で見ているユーザーも、開発者が、 getFileHandle() の呼び出しで見つからなかった理由をデバッグしている場合も、ファイルが、 どこから来たのかを知りたいはずである。ユーザーエージェントは、そのために、実装内部専用の来歴記録を、 エントリーとともに保持してよい（例えば、その保存したオリジン群のそれぞれが、 その、 バイト列をフェッチした URL と、その時刻）。ただし、記録は、ユーザーエージェントの状態として扱い、 エントリーの外部に保持しなければならない：

• スクリプトには決して公開されない。この仕様のどの部分もそれを開示せず、後から追加されるものも、 開示すべきでない。getFileHandle() も、そこから返される、 FileSystemFileHandle も、その記録が存在するかどうかを明らかにすべきでなく、まして、 その内容を明らかにすべきでない。特に、要求元のオリジンは、自身が、 生成したものでない記録を観測できてはならない。

• 信頼された、ウェブ以外のインターフェースを通じてのみ提示される。具体的には、ユーザーエージェント自身の設定およびストレージ 検査 UI、開発者ツール、および（ユーザーエージェントが拡張機能プラットフォームを持つ場合）、 ユーザーが明示的に付与する許可によって制御される拡張機能 API であり、他の、 閲覧履歴を公開する API と同じ位置付けとする。 ブラウザー拡張機能との統合ポイントの解説を参照。これは、 この、 リポジトリー内にあり、検討中の拡張機能向けインターフェースを説明している。

• 未検証であり、そのように提示される。記録内の URL は、バイト列を書き込んだ、 オリジンによる主張である。ハッシュだけが、内容を保証する（§ 8.1 リソースの完全性を参照）。2 つのオリジンは、異なる URL を、 同じエントリーについて記録してもよく、どちらも、 不正確であったり、意図的に誤解を招くものであったりする可能性がある。

• エントリーおよび帰属先のオリジンと存続期間を共有する。記録は、 エントリーが追い出されたり削除されたりすると破棄され、あるオリジンに帰属する部分は、 そのオリジンの許可が、保存したオリジン群から削除されたときに破棄される。これには、ユーザーが、 その、 オリジンのサイトデータを消去する場合も含まれる（§ 5.2 追い出しを参照）。

このような記録はコンテンツから見えないため、ユーザーエージェントが記録を保持するかどうか、また、どれだけの情報を、 保持するかは、完全に実装に委ねられる。この仕様のどの部分もそれに依存せず、その、 存在または不在をサイトが検出することはできない。

6. 権限ポリシーとの統合

この仕様は、ポリシー制御機能を、[permissions-policy]に従って定義し、識別子を、 文字列「cross-origin-storage」とする。その既定の許可リストは、 selfである。

[permissions-policy]は、使用を許可されていることを、Documentについて定義する。 しかし、 CrossOriginStorageManager は、WorkerGlobalScopeにも公開され、 それは、自身の、 Document を持たない。したがって、確認は、呼び出し元のグローバルオブジェクトについて記述する： ワーカーのグローバルオブジェクトについては、Document群を、 所有関係に従って推移的にたどり、それらのすべてが、 その機能を許可していなければならない。

グローバルオブジェクトについて、このアルゴリズムが false を返す場合、そのオブジェクトからのすべての、 getFileHandle() の呼び出しは、次の例外で拒否される： 「NotAllowedError」 DOMException。 これは、ハッシュの検証、レジストリーの検索、または書き込みが、 行われる前に生じる。

注: 所有者集合をたどって判定することで、その機能の、 オプトアウトが名目だけのものになるのを防ぐ。blob: URL から作成されたワーカーは、作成元ページの、 オリジンで実行され、そのページとクロスオリジンストレージの見え方を完全に共有する（ § 3 CrossOriginStorageManager インターフェースを参照）。したがって、 グローバルオブジェクト自身の、 Document だけを参照する確認は、すべてのワーカーにおいて空虚に満たされることになり、呼び出しを、 new Worker(URL.createObjectURL(…))へ移すことで、 cross-origin-storage=() ポリシーを、 他の何も変更せずに回避できてしまう。

注: ServiceWorkerGlobalScopeの、 所有者集合は空であるため、この、 アルゴリズムは、そこで false を返す。これは、所有者集合の性質による。それは、 存続関係であり、ワーカーの作成時に要素が追加され、そのワーカーが、 まだ積極的に必要とされているかを判断するために参照される。サービスワーカーは、意図的に、どのDocumentとも、そのような関係を持たない： 登録は永続化され、ユーザーエージェントがイベントに応じてグローバルオブジェクトを起動し、 サービスワーカークライアントがまったく存在しない状態でも実行できる。 register() を呼び出したクライアントは、したがって、登録時には把握できるが、 グローバルオブジェクトが実行される時点では、通常はすでに存在しない。また、1 つの実行中のサービスワーカーが、多数のクライアントにサービスを提供し、 それらのポリシーが一致するとは限らない。

注: サービスワーカーを対象に含めるには、保持されたポリシーが必要であり、 その作業は、 [permissions-policy]および[service-workers]が担う。この仕様が、 望ましいと考える形は、サービスワーカーのポリシーを、その、 スクリプト自体のレスポンス上のPermissions-Policy ヘッダーから導出するものである。これは、そのポリシーコンテナーが、 すでに、そのレスポンスの CSP を保持する方法と同じであり、オリジンの制御下に保たれ、 更新確認のたびに再評価される。登録を行ったクライアントのポリシーのスナップショットを取ると、オプトアウトが、 古い状態のままになる。機能を、 ヘッダーから削除しても、登録がたまたま更新されるまで有効にならないためである。そのような、 モデルが存在するまでは、判定できない場合に許可しないことが、オプトアウトの回避に利用できない唯一の回答となる。

注: SharedWorkerGlobalScopeの、 所有者集合は、複数の、 Documentを、 それぞれ異なるポリシーとともに保持でき、ワーカーの存続期間中に所有者が増減する。 すべての所有者がその機能を許可することを要求すると、許可しない所有者が 1 つあれば、 共有ワーカー全体についてクロスオリジンストレージが無効となり、その回答は、2 回の、 getFileHandle() の呼び出しの間で変わり得る。代わりに、許可する所有者が 1 つだけあれば、 よいとすると、その機能を許可する任意の文書が、 許可しない文書に代わって、その機能を再度有効にできてしまう。

7. Cross-Origin-Storage-Allow-Origin ヘッダー

COS エントリーのオリジン群のリストが、 空でない場合、開示先となるオリジンには、 書き込み元オリジンが制御しないものも含まれる。それにもかかわらず、そのリストは、スクリプト（ originsを通じて） またはマークアップによって宣言され、どちらも、 スクリプトやマークアップの注入に成功した攻撃者が設定できる。この宣言を、 バイト列が開示されるオリジンの運営者に、注入されたコンテンツが偽造できない形式で結び付けるため、 この仕様は、そのような宣言が指定できるオリジンを制限するレスポンスヘッダーを定義する。

Cross-Origin-Storage-Allow-Origin レスポンスヘッダーは、 COS スコープ上限を伝える。これは、 集合 であり、オリジンのうち、書き込みが同一サイト以外の、 オリジン群のリストに指定できるものを表す。 バイト列を提供する側がヘッダーを送信するため、その読み取り元は、 開示されるバイト列の元となるレスポンスとなる：

• getFileHandle() による書き込みでは、そのバイト列が、 スクリプト内で生成され、元となるレスポンスを自身では持たない場合があるため、対象は、レスポンスのうち、 呼び出し元のグローバルオブジェクトのDocumentの作成に使用されたもの、 または、ワーカーの場合は、その所有元である、 Document群の、 レスポンスとなる（COS スコープ上限を取得するを参照）。

• ホストとの統合では、対象は、レスポンスのうち、保存されるバイト列を持つ、フェッチしたリソースのものとなる （フェッチしたリソースを クロスオリジンストレージに保存するを参照）。これは、リソースのサーバーであり、 次のもののサーバーと同じである必要はない：Documentのうち、 そのリソースを読み込むもの。

宣言されたリストは、 共通部分を取る処理を、上限との間で行う（ COS スコープ上限を適用するを参照）。したがって、上限は、宣言の範囲を狭めることしかできない。

注: このヘッダーは、 バイト列を提供する側による認可である。そこで指定されるオリジン、 すなわち最終的な読み取り元には問い合わせを行わず、それらは何も送信しない。列挙されたオリジンが関与するのは、その後、 getFileHandle() を、COS ハッシュに対して、他の、 読み取り元と同様に呼び出すときだけである。これは、Access-Control-Allow-Origin [FETCH]とは反対の方向に作用する。そちらでは、 リソースを保持するサーバーが、特定のオリジンによる読み取りをオプトインで許可する。ここでは、バイト列の提供元が、 後からクロスオリジンストレージからそれを読み取れる相手を制限し、書き込みを行う、 ページに注入されたコンテンツは、その制限を拡張できない。提供元のレスポンスヘッダーを設定できないためである。

注: このヘッダーが適用されるのは、リスト形式だけである。 既定の同一サイトの動作は、クロスオリジンの、 受信先を指定しないため、認可を必要としない。また、「*」形式は、読み取り経路で、 利用可能性の制御によって、公開ハッシュリストに照らして制御される。ユーザーごとの、 秘密情報は、その条件を決して通過できないため、書き込み時の上限も必要としない。 「*」にヘッダーを要求しても、設定不要のグローバルな共有を壊すことになり、 公開ハッシュリストがすでに防いでいるもの以外を防ぐことはできない。

すべてのDocument は、COS スコープ上限を持つ。これは、集合であり、要素は、オリジンである。 文書の作成時に、COS スコープ上限を構文解析する処理を、 次を指定して実行した結果に設定される： ヘッダーリストのうち、レスポンスが、 文書の作成に使用された場合の、そのレスポンスのもの。

注: ワーカーの所有者集合全体で共通部分を取ることは、 クロスオリジンストレージの許可を確認する処理に対応する。オリジンが、 ワーカーの上限に含まれるのは、所有元となるすべての、 Documentが、 推移的に、そのオリジンを認可している場合だけである。blob: ワーカーは、作成元ページの、 オリジンとクロスオリジンストレージの見え方を完全に共有するため（ § 3 CrossOriginStorageManager インターフェースを参照）、 ワーカー自体だけを参照する上限は、 すべてのワーカーで空となり、リストを範囲とする書き込みを、 new Worker(URL.createObjectURL(…))へ移すと、ページが認可した受信先が取り除かれてしまう。 所有者の上限の共通部分を取ることで、その認可を保持しつつ、いずれか 1 つの、 所有者がそれを拡張することを防げる。

Documentの、 COS スコープ上限を、そのレスポンスから設定するには、 必要となるのは、 [HTML]の文書 作成手順におけるフックである。これは、[permissions-policy]および[CSP]が、 レスポンス処理時に設定されるのと同じ方法である。そのフックが存在するまでは、この節が、 要求される動作を直接記述する。将来の改訂では、正式に統合されることが想定され、併せて、 [FS]のフックについても、§ 3.3 ファイルの作成と書き込みに記述されている。ホストとの統合には、そのような、 フックは必要ない。それらは、 フェッチしたレスポンスを、フェッチしたリソースをクロスオリジン ストレージに保存する処理に渡し、その処理が、 レスポンスから上限を読み取る。

8. プライバシーとセキュリティに関する考慮事項

この節は、RFC 2119 キーワードを使用する箇所を除き、非規範的である。併せて、 セキュリティとプライバシーに関する質問票を、 リポジトリー内で参照されたい。

8.1. リソースの完全性

すべてのCOS エントリーは、暗号学的ハッシュをキーとし、その、 バイト列も、そのハッシュに対して検証される（ § 3.3 ファイルの作成と書き込みを参照）。したがって、サイトは、 ファイルを、次を通じて取得した場合、 getFileHandle()、 そのバイト列が、自身で、 hashをフェッチした場合に得られるものと厳密に同じであると確信できる。開発者は、クロスオリジンストレージの内容を列挙したり、 ハッシュをすでに知っているのでなければ、ファイルにアクセスしたりすることはできない。

COS ハッシュは秘密ではない。これは、 コンテンツ識別子であり、誰でも、 ファイルをすでに持っていれば容易に計算できる。また、この仕様が対象とする広く配布された、 リソースでは、通常は公知の情報であり、モデルやライブラリーの、 リリースとともに公開されることも多い。したがって、ハッシュを知っていればエントリーを検索するには十分だが、 それ自体がアクセスを付与することはない。検索が成功するかどうかは、完全に、オリジン群と、 § 8.4 利用可能性の制御によって決まる。開発者は、非公開のハッシュを、 アクセス制御の仕組みとして扱ってはならない。 特定のファイルに関心を持つ攻撃者は、そのハッシュを推測する必要はなく、ファイル、 自体を入手すればよいためである（§ 8.2 クロスサイトの探索を参照）。

8.2. クロスサイトの探索

リソースを使用するサイトが限られた集合に属する場合、そのリソースが、 クロスオリジンストレージに存在すると知ることのできる攻撃者は、ユーザーが、そのいずれかのサイトを訪問した可能性が高いと推測できる。 getFileHandle() は、存在を知るための仕組みであるため、その各呼び出しは、 実質的に探索となる。この仕様の 2 つの独立した仕組みが、探索によって、 知ることのできる情報を制限する：

• オリジン群（ § 3.5 リソースの可視性の昇格を参照）により、保存する、 オリジンは、制限できる。 開示先を、選択したオリジンの集合と、オリジンが、同一サイトとしてそれらと一致するものに制限できるため、専有のリソースや普及度の低いリソースを、 必ずしも、 グローバルに探索可能にする必要はない。

• § 8.4 利用可能性の制御は、さらに、開示を差し控える。 「*」を範囲とするリソースについて、 要求元オリジンが、その保存したオリジン群に属さない場合、ハッシュが、PHL に掲載されているのでなければ開示しない。 したがって、リソースを、origins: 「*」で保存しても、 ウェブ上のすべてのオリジンから自動的に探索可能になるわけではない。この条件が適用されるのは、 「*」を範囲とする、 エントリーだけである。リストまたは同一サイトを範囲とするエントリーでは、最初の項目の制限が唯一の、 条件となる。それらについては、保存するオリジンが、すでに開示範囲を明示的に制限しているためである。

最初の項目が成り立つのは、「選択したオリジンの集合」が、ウェブ全体よりも意味のある程度に小さい場合だけである。 origins の形式自体は、呼び出し元が、 非常に多数のオリジンを列挙することを妨げない（例えば、公開された、 人気サイトランキングから組み立てたリスト）。これは、機能的にはグローバルな開示に近付きながら、 「*」だけが要求する、意図的かつ明示的なオプトインを回避することになる。オリジンリストの 最大長（ § 5.1 ストレージの制限を参照）が、これを制限する。上限は、実際の、 複数サイトにまたがるユースケース （共通の管理下にある少数の関連オリジン）を収められる一方、「すべてのオリジン」の意味のある近似には、 遠く及ばない程度とする。これにより、制限付きオリジンの形式であるオリジン群が、 暗黙の「*」の代替として使われることを防ぐ。

ユーザーエージェントは、さらに、繰り返される、 getFileHandle() の呼び出しについて、単一オリジンからの頻度を制限するなど、抑制すべきである。また、 デバイス上のヒューリスティック（例えば、ユーザーごとに生成されたように見えるハッシュへの、 要求パターンの検出）を適用し、探索の試みを識別して遮断してもよい。これは、探索対象の、 ハッシュが、PHL に掲載されているかどうかとは独立して行える。

8.3. 進行中の書き込み

要求されたが完了していない書き込みは、すべてのオリジンにとって、 一度も書き込まれていないハッシュと区別できてはならない。この仕様は、それを構造的に実現する。 COS エントリーが、COS レジストリーに追加されるのは、検証して保存する処理、または、 フェッチしたリソースをクロスオリジン ストレージに保存する処理だけによる。いずれの場合も、バイト列全体が、 ハッシュに対して検証された後に限られる。作成要求を完了する処理は、レジストリーを読み取りも書き込みも、 しない。したがって、 読み取りが観測できるプレースホルダー状態は存在せず、読み取り経路に、 利用可能性の制御を適用する処理より前に応答できる分岐も存在しない。

代わりに、作成要求時にプレースホルダーを登録し、同時に行われる、 読み取りを、区別可能なエラーで拒否すると、呼び出し元は、何らかのオリジンが、 特定のハッシュを現在書き込み中であると知ることができる。その 1 ビットは、些細に見えても、そうではない。それは、次の条件で取得可能となる：

• 任意のオリジンが取得できる。そのエントリーに対する許可を一切持たないものも含まれる。プレースホルダーは、 許可を持たず、読み取りへの応答が、COS の開示を 決定する処理より前に行われるためである。

• 任意のハッシュについて取得できる。PHL に掲載されている状態になく、今後もそうなり得ないものも含まれるため、攻撃者は、 ユーザーごとの値から導出したハッシュを使用できる。これは、まさに、§ 8.6 フィンガープリンティングが、 検出するために設けられたパターンである。

• GREASE の適用を受けずに取得できる。これは、制御の手順に到達する開示にだけ、 適用されるため、 そのビットにはノイズが加わらない。

• バイト列を一切提供せずに取得できるため、オリジンごとのストレージ上限も、 また、 § 5.2 追い出しも、オリジンがそのようなビットを作成できる数を制限しない。

したがって、2 つのサイトに埋め込まれた追跡者は、最初のサイトで任意のビット幅の識別子を生成し、 2 つ目のサイトで読み戻せる。ストレージのコストをかけずに、オリジン群、 公開ハッシュ リスト、および GREASE の適用を、まとめて回避できる。また、プレースホルダーは、サービス拒否の、 攻撃手段にもなる。実際に広く利用されるリソースのハッシュを固定すると、他のすべてのオリジンによる読み取りを、 プレースホルダーが存続する間、抑制できてしまう。

注: この設計によって失われるのは、ある呼び出し元が、 別の呼び出し元によるダウンロードの進行を発見し、 大きなファイルの重複したダウンロードを開始せずに済ませる能力である。これは実際のコストであり、 この仕様の以前の草案が、ここで区別可能なエラーを使用していた理由でもある。この能力は、 最も重要な範囲である単一オリジン内では、次を使用して取り戻せる： Web Locks、BroadcastChannel、 または共有ワーカーであり、 それらはいずれも、 オリジンの境界を越えて何も開示しない。オリジン間での節約は、大部分が理論上のものにとどまる。2 つの無関係な、 オリジンが、同じ瞬間に同じハッシュを巡って競合する必要があり、どちらもまだ、 書き込んでいないエントリーは、いずれにせよ、PHL に掲載されている状態になるまで、他方に開示できないためである。

注: 「NotAllowedError」 は、引き続き、getFile() を、 作成要求で取得し、書き込みを完了していないハンドルに対して呼び出した場合の応答となる（§ 4 クロスオリジンストレージファイルシステムを参照）。この回答は、 レジストリーの内容に対して一定であり、要求を行ったオリジンだけに届く。 ハンドルはクロスオリジンで逆シリアル化できないためである（§ 4.1 ハンドルの 転送を参照）。したがって、これは情報伝達経路にはならない。

8.4. 利用可能性の制御

getFileHandle() による読み取りが、次の範囲外のオリジンから行われる場合、 保存した オリジン群、その成功は、常に、要求元オリジンが、 エントリーの読み取りを許可されているかどうかに依存する。これは、オリジン群によって制御される。「*」を範囲とするエントリーには、2 つ目の、 独立した問いも適用される。ユーザーエージェントが、エントリーが、 そもそも存在することを開示する意思を持つかどうかであり、PHL への 掲載およびGREASE の適用によって制御される。このようなエントリーでは、両方が、 成り立たなければならない。リストまたは同一サイトを範囲とするエントリーには、最初の問いだけが適用される。 規範的なアルゴリズムは、§ 3.2 ファイルの読み取りを参照。「NotFoundError」 は、したがって、 リソースの不在を証明しない。リソースが存在しない場合、要求元の、 オリジンが範囲外の場合、「*」を範囲とするリソースのハッシュが PHL に（まだ、あるいは今後も）掲載されていない場合、または、 GREASE の適用が真陽性を抑制した場合を意味し得る。開発者は、「NotFoundError」 を、 「代わりにネットワークを使用する」よりも具体的な意味として扱ってはならない。

注: サードパーティ Cookie をサポートするユーザーエージェントでは、 「*」の許可によって、追跡者が、 ユーザーのサイト間の訪問を結び付ける能力は、サードパーティ Cookie がすでに可能にしているものを超えない。PHLだけでは、 これを制限できない。攻撃者は、個別には、 PHL の対象となるリソースについて、書き込む部分集合を選ぶことで、サイト間の識別子を構築できる。サードパーティ、 Cookie を遮断するユーザーエージェントも、サイト間の開示を制限すれば、「*」の許可を提供できる。例えば、 トップレベルサイトをキーとし、ページ上のすべてのフレームで共有する、小さなサイト間検索の上限を設け、 その回数を、一定の時間枠で再読み込みをまたいで保持し、書き込んだエントリーを、 「*」の許可を通じて利用可能にするのを、ユーザー操作の後だけにする方法がある。README の、 プライバシーに関する考慮事項が、これらの緩和策を説明している。 GREASE の適用と同様に、これらが適用されるのは、 グローバルに開示可能という許可だけで資格を得るオリジンに限られる。保存した オリジン群、および、 明示的なオリジン群のリストにあるオリジン、ならびに、 オリジンが同一サイトとして、そのいずれかと一致するものは、 COS の開示を決定する処理がエントリーを返すと直ちに、それを読み取れる。ユーザー操作も、 検索回数の上限も必要ない。

8.5. GREASE の適用

ユーザーエージェントは、GREASE の適用（ランダムな拡張を生成し、 拡張可能性を維持する）を行ってよい。これは、ときどき、 開示可能なエントリーが存在しないかのように応答することであり、§ 8.4 利用可能性の制御が、 本来なら、 開示を許す場合でも行う。これによりノイズが加わり、サイトが、実際の不在と、 プライバシー上の理由による偽陰性を区別しにくくなる。これは、 UA クライアント ヒントが適用する手法と類似している。

GREASE の適用対象は、グローバルに 開示可能という、 許可だけで資格を得るオリジンに限られる。これは、公開ハッシュリストによって制御される場合と同じである（COS の開示を決定するを参照）。 ユーザーエージェントは、これを、保存したオリジン群、明示的な、 オリジン群のリストにあるオリジン、または、 オリジンが同一サイトとして、そのいずれかと一致するものに適用してはならない。

GREASE を適用するユーザーエージェントは、対象となるエントリーのサイズに、 見合った判断で行わなければならない。小さなエントリーでは、ネットワークからのフェッチへの切り替えにかかるコストが低いため、ときどき、 偽陰性を返すことは、プライバシー上の妥当なトレードオフとなる。ユーザーエージェントは、エントリーの、 サイズによって、不必要な再ダウンロードが、得られるプライバシー上の利益に対して明らかに不釣り合いとなる場合、 GREASE を適用してはならない（例えば、ギガバイト規模の AI モデルの重み）。そこで偽陰性を返すと、全体を、 観測可能な形で、コストをかけて再ダウンロードすることを強いるためである。

8.6. フィンガープリンティング

攻撃者がクロスオリジンストレージの探索から抽出できる情報は、探索対象の、 リソースがどれほど広く利用されているかによって制限される。ユーザーが、一般的な AI モデルなどの、非常に広く利用されるリソース、 または、広く使われる JavaScript ライブラリーを持つと知っても、それを使用する（場合によっては非常に、 多数の）サイトのいずれかを訪れたことしか分からない。ユーザーが、珍しいリソースや一意のリソースを持つと知ることは、はるかに多くの情報を与える。 ユーザーエージェントは、デバイス上のヒューリスティックを適用し、ハッシュが、 ユーザーごとに意図的に一意にされたように見えるリソース（例えば、単一の、 サイトだけが書き込んだことのあるハッシュ、または、異常な頻度で要求されるハッシュ）を検出し、そのようなパターンを探索の試みとして扱うことが想定される。 これは、名目上の PHL 掲載状況とは独立して行う。

9. 他の仕様との統合

この節は非規範的である。

ここで定義するCOS レジストリーには、 4 つのホストとの統合からもアクセスでき、その際には、 getFileHandle() を直接経由しない。各、 統合は、それぞれのホスト仕様で定義される。この仕様は、共有される、 基盤となる概念（COS ハッシュ、COS エントリー、利用可能性の制御、および、 公開ハッシュ リスト）と、フェッチしたリソースをクロスオリジン ストレージに保存する手順を定義し、 それらの統合は、この手順を基盤とすることが想定される。

• HTML：crossoriginstorage 属性を、 link および、 script 要素のうち、すでに、 integrity [SRI]を持つものに追加する。WHATWG に、 whatwg/html#12770で提案されている。

• JavaScript：ホスト定義の crossOriginStorage インポート属性であり、併用できる、 相手は、 integrityである。これは、インポート属性の、 提案を基盤とし、WHATWG に、 whatwg/html#12771で提案されている。

• CSS：cross-origin-storage() <request-url-modifier>であり、 integrity()と併用できる。 CSS 作業部会に、 w3c/csswg-drafts#14056で提案されている。

• Fetch：crossOriginStorage というRequestInit オプションであり、併用できる相手は、 integrity [FETCH]である。提案先は、 WHATWG であり、 whatwg/fetch#1954に記載されている。 この形式には、ホスト定義の宛先がなく、また、COS エントリーが保存するのは、バイト列だけであるため、 その仕様が、Responseを、 COS レジストリーから提供する際の内容を定義する。想定される、 形は、成功したレスポンスであり、ステータスは 200、ステータスメッセージは OK、そして、 本体は、バイト列のストリームとなる。その Content-Type ヘッダーは、MIME 型として、 その、 呼び出し元が宣言したものを使用し、ネットワークからのフェッチが行われていないため、他のヘッダーは持たない。

説明のためだけに、同じグローバルに共有されるリソースについて、クロスオリジンストレージの利用を、 4 つの形式それぞれで選択する例を示す：

<script src="popular-library.js" integrity="sha256-abc123..." crossoriginstorage="*"></script>

import data from "popular-resource.ext" with {
 integrity: "sha256-abc123...",
 crossOriginStorage: "*",
};

@font-face {
 font-family: "Popular Font";
 src: url("popular-font.woff2" integrity("sha256-abc123...") cross-origin-storage(*));
}

const response = await fetch("popular-resource.ext", {
 integrity: "sha256-abc123...",
 crossOriginStorage: "*",
});

これらのコード片は、説明のためだけのものである。この構文はいずれも、この仕様によって定義されるものではない。 各形式の正式な文法は、制限付きオリジンリストの記述方法も含めて、 それぞれのホスト仕様が定める。記述形式は、意図的に、 異なっている。RequestInit のメンバーは、sequence<DOMString>を取ることができ、 origins と厳密に一致する。一方、属性値、 インポート属性値、および CSS 修飾子の引数は、テキストしか持つことができない。

4 つの形式はすべて、まず、COS レジストリーを参照し、一致する開示可能なエントリーを探してから、 ネットワークからのフェッチへ切り替えるという処理モデルと、 正常にフェッチされ、完全性が検証されたリソースを、COS レジストリーに保存し、 他のオリジンが再利用できるようにする処理モデルを共有することが想定される。これは、getFileHandle() が行うことと、まったく同じである。保存手順は、 フェッチしたリソースをクロスオリジン ストレージに保存する処理であり、各統合は、これを、 フェッチしたレスポンスを指定して実行する。したがって、制限付きオリジンの値は、 そのリソースのレスポンス上の Cross-Origin-Storage-Allow-Origin ヘッダーによって制限される。このヘッダーは、 バイト列を提供するサーバーが送信する（§ 7 Cross-Origin-Storage-Allow-Origin ヘッダーを参照）。 これらの統合に関する議論は、それらを規定するホスト仕様のトラッカーで行うべきであり、 このリポジトリーの課題トラッカーで行うべきではない。

謝辞

Tab Atkins-Bittner、Yash Raj Bharti、および Joshua Lochner による貴重なフィードバック、ならびに、 Kenji Baheux および Kevin Moore による貴重な着想やアイデアに、深く感謝する。

この仕様には、次をモデルとした資料が含まれる： ファイルシステム。これは、 W3C ソフトウェア および文書ライセンスの下で利用できる。