資格情報なし iframe

コミュニティグループ報告書草案、

このバージョン:
https://wicg.github.io/anonymous-iframe/
課題追跡:
GitHub
編集者:
（Google）
（Google）
テスト:
web-platform-tests html/anonymous-iframe/（進行中の作業）

©2022, Google, Inc. All rights reserved.

要約

資格情報なし iframe は、開発者に、サードパーティ iframe 内の文書を、新しく一時的なネットワーク／ストレージ／Cookie コンテキストで読み込む方法を提供します。その代わりに、Cross-Origin-Embedder-Policy (COEP) の埋め込み規則を緩和できます。

COEP を使用する開発者は、COEP を使用しないサードパーティ iframe を埋め込めるようになります。

この文書のステータス

この仕様は、Web Platform Incubator Community Group によって公開されました。 これは W3C 標準ではなく、W3C 標準化トラック上のものでもありません。 W3C Community Contributor License Agreement (CLA) の下では、限定的なオプトアウトおよびその他の条件が適用されることに注意してください。 W3C Community and Business Groups について詳しく学んでください。

1. はじめに

このセクションは規範的ではありません。

2. 問題

このセクションは規範的ではありません。

COEP の展開は、 サードパーティ iframe のため、一部の開発者にとって困難です。典型的なシナリオは次のとおりです:

  1. エンドユーザーは高性能な Web サイトを必要とします。

  2. 一部の開発者は、トップレベル文書でマルチスレッド／SharedArrayBuffer を使用することで、高性能な Web サイトを実現しています。

  3. [Spectre] 攻撃を緩和するため、 Chrome、Firefox、Safari などのブラウザーベンダーは、SharedArrayBuffer の使用を crossOriginIsolated 能力の背後で制限しています。これには COEP と COOP の両方を展開する必要があります

  4. COEP の要件は再帰的です。サードパーティ iframe は、COEP の親の内部に埋め込み可能となるために、COEP を展開する必要があります。

  5. サードパーティが COEP を展開するのを待つことは、開発者にとって苦痛です。多くの場合、 それはほとんど開発者の制御外にあります。

性能以外にも、crossOriginIsolated 能力の背後で制限されている追加機能があります。高解像度タイマー、getViewportMedia などです...

COEP の展開は、 関与する開発者が 1 人ではなく多数いる場合に困難です。たとえば Google Ads はサードパーティコンテンツを含んでおり、 すべての広告作成者が読み込み可能にオプトインする作業を確実に行うことは、やや考えにくいと思われます。

3. 解説

このセクションは規範的ではありません。

[COEP-require-corp] は現在、 より高いリスクを伴う環境で読み込まれることに、クロスオリジンリソースが明示的にオプトインすることを保証することで、 データ漏えい攻撃に対処しています。このようにして、サーバーは脆弱なリソースが高リスク環境で読み込まれることに オプトインしないようにして保護できます。

明示的なオプトインを要求せずに、偶発的なクロスプロセス漏えいに対して十分に堅牢な保護を提供するアプローチを 見つけられれば理想的です。

[COEP-credentialless] は、単純なサブリソースについてこの問題を解決しました: レスポンスからのオプトインを要求する代わりに、リソースは資格情報なしで要求されます。このようにすると、 攻撃者に漏えいする可能性があるのは公開リソースのみです。それらは攻撃者に追加の価値をもたらしません。

資格情報なし iframe も同様ですが、<iframe> 用です。 Iframe は対処がより困難です。Iframe はナビゲーションリクエストによってリソースを取得するだけでなく、 新しいコンテキストも作成します。新しいコンテキストは自分自身でデータを取得できます。また、 ストレージ API からデータにアクセスすることもできます: [WebStorage], [IndexedDB], [web-sql], BroadcastChannel, SharedWorker, ServiceWorker などです

資格情報なし iframe は、iframe 内の文書を新しく一時的なコンテキストを使用して読み込むためのフラグです。 これにより、埋め込まれた Web サイトの「公開」バージョンのみが攻撃者に漏えいし得ることが保証されます。

3.1. 資格情報なし iframe とは何か？

文書は、iframe タグに credentialless 属性を追加することで、資格情報なし iframe を作成できます:

<iframe credentialless src=”https://example.com”></iframe>

このプロパティは iframe に保存されます。また、内部に読み込まれた新しい Window に保存され、継承されます。例:

credentialless inheritance

credentialless フラグの継承。

この属性は <iframe> 上でプログラムにより変更できます。内部に新しく読み込まれる Window に対して効果を持ちます。つまり、その効果は追加のナビゲーション後にのみ発生します。

credentialless フラグの状態は、読み取り専用の定数属性を通じて Window に公開されます:

window.credentialless

これは、資格情報なし iframe の直下、またはそのさらに下に読み込まれた Window で true になります。

3.2. 資格情報なし iframe と資格情報

資格情報なし iframe は、そのオリジンの既存の資格情報や共有ストレージを使用できません。白紙の状態が与えられます。 サンドボックス化されたフレームとは異なり、ストレージ API を使用したり Cookie を登録したりできます。ただし、 それらの資格情報とストレージは、ページ内の資格情報なし iframe 内の文書によってのみ共有できます （通常のオリジン制限を満たす場合）。ユーザーが別のトップレベル文書へナビゲートすると、それらには もうアクセスできなくなります。本質的に、資格情報なし iframe には、現在のトップレベル文書内の 資格情報なし iframe にパーティション化された一時的な storage shelf が与えられます。

これを実現するために、資格情報なし iframe によって共有ストレージへアクセスするために使用される storage key の変更に依存します。クライアント側ストレージパーティショニングの取り組み （ストレージ API、ネットワーク 状態、Cookie 状態 にわたって展開される）の一部として、 環境の storage key は、仕様で現在記述されているような単純なオリジンではなくなります。 代わりに、オリジンとトップレベルサイト URL の組み合わせになります。資格情報なし iframe では、 パーティションキー内のトップレベルサイト URL を、トップレベル文書ごとに一度決定される nonce 値で置き換えます。 その結果、nonce は同じトップレベル文書の子孫であるすべての資格情報なし iframe によって共有されます。 ユーザーが別の文書へナビゲートするたびに nonce は異なるため、資格情報なし iframe は異なるページ間、 またはクロスドキュメントナビゲーション間でストレージを共有しません。

nonce in partition-key

ストレージと資格情報は、通常のサイト／オリジンアクセスチェックに従って、資格情報なし iframe 間でのみ共有されます。

page’s nonce

*資格情報なし iframe によって作成されたストレージと資格情報は、トップレベルフレームが別のトップレベル文書へ ナビゲートした後はアクセスできなくなります。これは、資格情報なし iframe の Storage key が異なるためです。 つまり、ナビゲーション後にトップレベル文書が解放されると、資格情報なし iframe が使用したストレージは もう使用されないため、ブラウザーによって消去できます。

back-forward cache は、トップレベル文書とその資格情報なし iframe をより長く存続させることができます。 それらに割り当てられた nonce は、それらが復元されたときにも引き続き使用されます。

資格情報なし iframe によって開かれたポップアップは資格情報なしではありません。しかし、 資格情報なし iframe によって開かれるポップアップには rel = noopener が設定された状態で開かれることを課します。これは、OAuth ポップアップフローが資格情報なし iframe 内で 使用されることを防ぐためです。この制限を課す理由についての議論は、脅威モデル の部分を参照してください。

3.3. 資格情報なし iframe は COEP とどのように相互作用するか

私たちの提案は、資格情報なし iframe は、COEP ヘッダーを送信してオプトインしていなくても、 COEP ページに埋め込むのに十分安全であるというものです。したがって、資格情報なし iframe 内の文書へ ナビゲートする場合、その親が unsafe-none の COEP ではない場合でも、COEP および CORP ヘッダーがあるかどうかを チェックしません。

これはまた、資格情報なし iframe は、内部の文書が COEP を展開しなくても、クロスオリジン分離ページに 埋め込むことができることを意味します。

3.4. 資格情報なし iframe と自動入力／パスワードマネージャー

自動入力またはパスワードマネージャー機能を実装するブラウザーは、それらを資格情報なし iframe で 使用できないようにするべきです。資格情報なし iframe の目的は、iframe の機能に重要なストレージを保つ一方で、 ユーザーが資格情報なし iframe にログインすることを避けることです。自動入力とパスワードマネージャーは ログインを容易にするため、ユーザーが誤ってログインすることを防ぐために避けるべきです。 これにより、資格情報なし iframe はフィッシングページに似た 脅威モデル を持つこともできます（以下のこの解説の 脅威 モデル の部分を参照）

3.5. COEP:credentialless との比較

COEP:credentialless と iframe credentialless は、同じ目標を共有する 2 つの提案です: 開発者が COEP を展開するのを支援することです。どちらも、公開リソースは攻撃者にとって価値がないという考えに 基づいています。公開データは、サーバーからの明示的なオプトインなしに安全にプロセスへ入ることができます。 同じプロセス上の攻撃者は Spectre を使ってデータを読み戻せますが、何の利益も得ません。

比較はそれ以上には広がりません。2 つの機能の実装は非常に異なります。一方は文書に読み込まれる単純な サブリソース用であり、もう一方は <iframe> 内に異なる文書を読み込むためのものです。

credentialless という名前は、非常に異なる意味を持ちます:

4. 検討された代替案

このセクションは規範的ではありません。

4.1. サンドボックス化された iframe

allow-same-origin フラグのないサンドボックス化された iframe は、サブリソースリクエスト用の ストレージ API や Cookie にアクセスできません。しかし、sandbox iframe の文書は依然として 資格情報付きでリクエストされる可能性があり、これは 脅威モデル に適合しません。サンドボックス化された iframe を変更し、 文書も資格情報なしでリクエストされるようにすることはできます。

では、なぜ新しい sandbox フラグでサンドボックス化された iframe を使うだけではなく、新しい属性の導入を 提案しているのでしょうか？

第一に、メインリソースが常に資格情報なしでリクエストされるようにサンドボックス化された iframe の挙動を 変更すると、新しい概念を導入する場合とは対照的に、既存の Web サイトを壊す可能性があります。

第二に、iframe 内のコンテンツに課される混乱の量を最小限にしたいと考えています。サンドボックス化された iframe を使用すると、iframe は Cookie やストレージ API をまったく使用できず、文書内の他のフレームにも アクセスできません。これは、crossOriginIsolation にオプトインするための credentialless 解決策の展開可能性を 制限するのではないかと懸念しています。私たちは、できるだけ展開しやすい解決策を開発者に提供したいと 考えているため、iframe に課す制限ができるだけ少ない新しい解決策を導入したいのです。

これらの制限を sandbox フラグ、たとえば allow-partitioned-storage として成文化しようとすることもできます。 これは、Firefox と Safari に出荷されているストレージアクセス sandbox フラグと調和させるのが おそらく困難です。特に、新しい sandbox フラグはデフォルトでオフになるためです。

これはひいては、COEP 展開のためにサンドボックス化された iframe に依存することの別の問題です。 すべてのフラグがデフォルトでオフであるため、新しいフラグはサンドボックス化された iframe の挙動に 影響を与える可能性があります。さらに、Cookie／ストレージへのアクセスを除くすべての機能を得るには allow-same-origin 以外のすべてのフラグを追加する必要があるため、構文がやや複雑です。

4.2. 不透明オリジン

私たちが提案する資格情報なし iframe モデルは、storage key 内の nonce を使用するパーティション化ストレージ （解説を参照）に依存しています。サンドボックス化された iframe と同様に、資格情報なし iframe に 不透明オリジンを割り当てることも検討しました。これにより、資格情報なし iframe は既存の資格情報と 共有ストレージにアクセスできないことが保証されます。なぜなら、それらのオリジンが不透明なものへ 変更されているためです。

この解決策は互換性の問題にぶつかります:

4.3. COEP:credentialless が <iframe> に影響するようにする

もともと、COEP:credentialless のスコープは、現在そうであるような単純なサブリソースだけでなく、 <iframe> も含むことを意図していました。後者は性質が非常に異なります。これはリクエストの 資格情報だけでなく、文書によって後で行われるすべてのストレージ API の使用にも関わるからです。 そのため、ここでは延期されています。

難しい点は、ほとんどの場合、Web サイトには次のようなものが混在することです:

したがって、親が iframe ごとに判断できることが重要です。この判断は子によって直接行うことは 決してできない点に注意してください。これはナビゲーションのリクエストの資格情報に影響するためです。 その時点では手遅れになります。

COEP:credentialless では、サイト作者は request.mode を調整し、cors と no-cors の間で判断することで、リソースごとに資格情報を送信するかどうかを決定できます。 一方はサブリソースが埋め込みにオプトインすることを要求し、もう一方は資格情報を省略します。

<iframe> 要素にも同様の仕組みが必要です。その結果として credentialless 属性になりました。

5. テスト

ステータス: https://wpt.fyi/results/html/credentialless-iframe/

6. 仕様

6.1. HTML との統合

注: これは次の HTML 仕様変更に対応します: whatwg/html/pull/7695.
マージされると、このセクションは廃止されます。

6.1.1. Iframe 属性

the iframe element セクションで、 HTML iframe の credentialless 属性を定義します:

credentialless 属性は、iframe によってホストされる文書を、 新しく一時的なストレージパーティションで読み込むことを可能にします。これは boolean 値です。既定値は false です。

これは Javascript の HTMLIFrameElement インターフェイスに公開されます:

partial interface HTMLIFrameElement {
  attribute boolean credentialless;
};

IDL 属性 credentialless は、 同名の対応するコンテンツ属性を 反映 しなければなりません。

6.1.2. Window 属性

読み取り専用の定数 credentialless 属性を Window オブジェクトに追加します。 

partial interface Window {
  readonly attribute boolean credentialless;
};

6.1.3. 新しい閲覧コンテキストの作成

creating a new browsing context セクションで: ステップ 5 を追加します:

  1. browsingContext が与えられたとき、initial window credentialless フラグを決定した結果を credentialless とします。

その後、新しい Window を作成するためにそれを使用します。

6.1.4. 閲覧コンテキストのナビゲーション

navigation params struct に、credentialless パラメーターを追加します:

credentialless
新しい Window に課す credentialless フラグ

navigate アルゴリズムで、ステップ 18 を追加します:

  1. browsingContext が与えられたとき、navigation’s credentialless flag を計算した結果を credentialless とします。

その後、同じアルゴリズム内で、この変数を使用して navigation params を構築します。

これは、process a navigate fetch アルゴリズムへの新しい引数としても渡されます。 このアルゴリズムも、新しい navigation params を作成するために使用されます。

次に、initialize the document object アルゴリズムで:

browsing context 内で新しい Window を作成するときに、credentialless 値を渡します。

Window オブジェクトは、navigation params 内のものと異なる credentialless フラグを 保持することにつながる場合、再利用してはなりません。

例: これは次の場合に有用です:

const iframe = document.body.createElement("iframe");
iframe.credentialless = true;
document.body.appendChild(iframe);
iframe.credentialless = false;
iframe.src = "https://example.test";
// about:blank 用と https://example.test 用の Window は異なる必要があります。

6.1.5. noopener でポップアップを開く

window open steps で、ステップ 5 を追加します:

  1. entry global object の credentialless フラグが true の場合、noopener を true に設定します。

6.1.6. 一般セクション

Loading web pages セクション内に、Sandboxing one と Sandboxing one および Cross-origin opener policies の間に、「Credentialless iframe」サブセクションを追加します:

7.7 Credentialless iframe
各 iframe 要素は、可変の credentialless フラグ属性を持ちます。
各 Window は、定数の credentialless フラグを持ちます。

credentialless Window は、Window であり、その credentialless フラグが true であるものです。

新しい browsing context browsing context が与えられたとき、initial window credentialless flag を計算するには:

  1. embedder を browsing context の container に設定します。

  2. embedder が要素でない場合、false を返します。

  3. そうでなければ、parentWindow を、embedder の node document の relevant global object に設定します。

  4. 次の和集合を返します:

browsing context browsing context が与えられたとき、navigation’s credentialless flag を計算するには、initial window credentialless flag アルゴリズムと同じステップに従います。

他のアルゴリズム内に分散した変更を集約するために、一般セクションにいくつかの注を追加します。

注: 新しい Window の credentialless フラグは、新しい browsing context に対する initial window credentialless flag アルゴリズムから、 または既存の browsing context 内でのナビゲーションについて、ナビゲーション開始時に実行される navigation’s credentialless flag アルゴリズムから計算されます。

注: credentialless Window から開かれたポップアップは、 常に noopener が設定されます。

注: トップレベルの credentialless Window は存在しません。

6.1.7. COEP 埋め込み元チェック

COEP 埋め込みチェックは 緩和できます。

check a navigation response’s adherence to its embedder policy に新しいパラメーター credentialless を追加し、 navigationParams の credentialless を渡します。

check a navigation response’s adherence to its embedder policy を、response response、browsing context target、embedder policy responsePolicy、および boolean credentialless が与えられたときに行うには:

  1. target が child browsing context でない場合、 true を返します。

  2. parentPolicy を、target の container document の policy container の embedder policy とします。

  3. parentPolicy の report-only value が compatible with cross-origin isolation であり、かつ responsePolicy の value がそうでなく、かつ credentialless が false の場合、response、"navigation"、parentPolicy の report only reporting endpoint、"reporting"、および target の container document の relevant settings object を用いて、queue a cross-origin embedder policy inheritance violation します。

  4. parentPolicy の value が compatible with cross-origin isolation でない、または responsePolicy の value が compatible with cross-origin isolation である、または credentialless が true である 場合、true を返します。

  5. response、"navigation"、parentPolicy の reporting endpoint、"enforce"、および target の container document の relevant settings object を用いて、Queue a cross-origin embedder policy inheritance violation します。

  6. false を返します。

6.1.8. 自動入力

「Credentialless iframe」セクションで、Web ブラウザーが自動入力機能をどのように構成すべきかを定義します。

Autofill and credentialless iframe: ユーザーエージェントは、 ユーザーがフォームに入力するのを支援する機能を持つことがあります。たとえば、ユーザーの住所、パスワード、 または支払い情報を事前入力する機能です。ユーザーエージェントは、そのデータがユーザーと Web サイトの両方に 固有である場合、それらの機能を無効にしなければなりません。

6.1.9. 環境の partition nonce

「Credentialless iframe」セクションで、page credentialless nonce を定義します。

各トップレベル Window には、関連付けられた page credentialless nonce があります。これは不変の nonce（「一度だけ使われる数」）です。

environment オブジェクトに partition nonce 属性を追加します。

A partition nonce

識別子または null。これは環境をさらに識別し、分離するために使用されます。とりわけ、credentialless Window では non null です

6.1.9.1. Navigation の場合

process a navigate fetch で、ステップを追加します:

  1. credentialless が true の場合、partitionNonce を browsingContext の top-level browsing context の page credentialless nonce とし、そうでなければ null とします。

partitionNonce は後で Environment を作成するために使用されます。 ステップ 13.3.4 を変更します:

13.3.4. request の reserved client を、id が一意な 不透明文字列、target browsing context が browsingContext、creation URL が currentURL、top-level creation URL が topLevelCreationURL、top-level origin が topLevelOrigin、 そして partition nonce が partitionNonce である新しい environment に設定します
.
6.1.9.2. Window の場合

initialize the document object で、ステップ 6.9 を追加します:

6.9. navigationParams の credentialless が true の場合、partitionNonce を browsingContext の top-level browsing context の page credentialless nonce とし、そうでなければ null とします。

次に、それをステップ 6.10 で Environment の作成へ通します:

6.10 creationURL、realm execution context、 navigationParams の reserved environment、 topLevelCreationURL、topLevelOrigin、および partitionNonce を用いて Set up a window environment settings object します。

partitionNonce は、このように set up a window environment settings object に渡されます:

set up a window environment settings object を、URL creationURL、JavaScript execution context execution context、null または environment reservedEnvironment、URL topLevelCreationURL、origin topLevelOrigin、および 識別子 partitionNonce が与えられたとき、次のステップを実行します:

これはステップ 6 で使用されます。

  1. settings object の creation URL を creationURL に、settings object の top-level creation URL を topLevelCreationURL に、settings object の top-level origin を topLevelOrigin に、そして settings object の partition nonce を partitionNonce に設定します。

6.1.9.3. Worker の場合

script settings for workers アルゴリズムで、ステップ 8 を追加します:

  1. settings object の partition nonce を、outside settings の partition nonce に設定します。

6.1.9.4. Worklet の場合

set up a worklet environment settings object アルゴリズムで、 ステップ 7 を変更します:

  1. settingsObject の id を新しい 一意な不透明文字列に、creation URL を inheritedAPIBaseURL に、top-level creation URL を null に、 top-level origin を outsideSettings の top-level origin に、partition nonce を outsideSettings の partition nonce に、target browsing context を null に、 そして active service worker を null に設定します。

6.2. Fetch との統合

注: これは次の HTML 仕様変更に対応します: whatwg/fetch/pull/1416.
マージされると、このセクションは廃止されます。

6.2.1. partition-nonce を通す

environment の partition nonce を network partition key に追加します。 次の変更を行います:

network partition key は次から成るタプルです:

determine the network partition key, given an environment environment を行うには、次のステップを実行します:

  1. topLevelOrigin を environment の top-level origin とします。

  2. topLevelOrigin が null の場合、topLevelOrigin を environment の top-level creation URL の origin に設定します。

  3. Assert: topLevelOrigin は origin です。

  4. topLevelSite を、topLevelOrigin が与えられたときに obtaining a site した結果とします。

  5. secondKey を null または implementation-defined 値とします。

    2 番目のキーは、細部がまだ発展中であるため、意図的に少し曖昧です。 issue #1035 を参照してください。

  6. nonce を environment の partition nonce とします

  7. (topLevelSite, secondKey, nonce) を返します。

6.3. CHIPS との統合

このセクションは、[CHIPS] に対する monkey-patch を定義します。 これはそれ自体が [COOKIES] に対する monkey-patch です。

注 / 要約: Cookies Having Independent Partitioned State (CHIPS) は Cookie の partition key を導入します。資格情報なし iframe を実装するために、environment の partition nonce が定義されている場合:

  1. "Partitioned" cookie 属性がない場合でも、 "partition-key" は定義され、(top-level-site, partition-nonce) を含みます。

  2. __Host- prefix は要求されません。

  3. environment は、"partition-key" が 定義されている Cookie にのみアクセスできます。

[CHIPS] セクションを変更します: https://github.com/WICG/CHIPS/blob/main/README.md#algorithm

以下は、ブラウザーが cookie 行を解析するために使用できるアルゴリズムです。このアルゴリズムは RFC6265bis の section 5.3 に追加できます。

  1. "partition-key" を null とします。

  2. environment の partition nonce が定義されている場合、または attribute-name が文字大小を区別せずに 文字列 "Partitioned" と一致する場合、次を行います:

    1. site を environment の top-level origin の site とします。

    2. site が First-Party Set 内にある場合、site を "https://" とそのサイトのセットの "owner domain" の 連結に設定します。

    3. nonce を environment の partition nonce とします。

    4. partition-key を tuple (site, nonce) に設定します

  3. attribute-name が "PartitionKey"、attribute-value が partition-key である属性を cookie-attribute-list に追加します。

以下は Partitioned Cookie を保存するためのアルゴリズムです。これらのステップは、 ユーザーエージェントが cookie の __Host- prefix を処理した後に、RFC6265bis の section 5.4 に追加できます。

  1. cookie-attribute-list が attribute-name "PartitionKey" を持つ属性を含み、attribute-value が null または non-null の nonce を持つ tuple (site, nonce) である場合、 次のステップをスキップして、その Cookie を cookie store に挿入します。

  2. cookie-name が、文字大小を区別して文字列 "__Host-" で始まらない場合、 次のステップを中止し、その Cookie を完全に無視します。

  3. cookie 行に [SameParty attribute](https://github.com/cfredric/sameparty) も含まれる場合（SameParty 属性が cookie-attribute-list に読み込まれる正確な意味論は TBD）、 次のステップを中止し、その Cookie を完全に無視します。

  4. cookie の partition-key を、attribute-name が "PartitionKey" である attribute-list 内の要素の attribute-value に設定します。

以下は、Partitioned Cookie をリクエストに付加するためのアルゴリズムです。 これらのステップは、最初のステップの後に、RFC6265bis の section 5.5 で説明されているアルゴリズムへ追加できます。

cookie-list 内の各 cookie について、次を行います:

  1. environment を、そのリクエストを開始した environment とします。

  2. cookie の partition-key が null であり、かつ environment の partition nonce が null である場合、このステップの次の部分をスキップします。

  3. request-top-site を environment の top-level origin の site とします。

  4. request-partition-nonce を environment の partition nonce とします。

  5. request-top-site が First-Party Set 内にある場合、request-top-site を "https://" と request-top-site のセットの "owner domain" の連結に設定します。

  6. request-partition-key をタプル (request-top-site, request-partition-nonce) とします。

  7. cookie の partition-key が request-partition-key と完全に一致しない場合、 その cookie を cookie-list から削除します。

6.4. storage-partitioning との統合

[StoragePartition] (link) Work Item では、ほとんどの ストレージ API は追加キー、すなわちトップレベルサイトによってキー付けされます。

資格情報なし iframe を実装するには、別のキーを追加し、それを environment の partition nonce として定義するべきです。

nonce
environment の partition nonce

6.5. storage との統合

注: これは次の [STORAGE] 仕様変更に対応します: whatwg/storage/pull/139.
マージされると、 このセクションは廃止されます。

6.5.1. storage-key

environment の partition nonce を、 storage key 内の追加キーとして追加します。

storage key は、次から成る tuple です:

obtain a storage key for non-storage purposes を、environment environment が与えられたときに行うには、 次のステップを実行します:

7. セキュリティ考慮事項

7.1. 脅威モデル

資格情報なし iframe は crossOriginIsolated コンテキストに 埋め込むことができるため、Out-of-Process-Iframes を持たないブラウザーでは、その埋め込み元が [Spectre] 攻撃を実行して、HTML を含む 資格情報なし iframe のリソースを読み取ることができることを考慮する必要があります。被害者は 資格情報なし iframe 内に読み込まれた文書であり、他の文書が攻撃者です。

この脅威に対する私たちのアプローチは、攻撃の発生を防ぐことではなく、パーソナライズされたデータの読み込みを避け、 攻撃者が公開利用可能なデータにのみアクセスできるようにすることです。

そのため、さまざまな可能な攻撃を考慮します:

7.2. 既存の資格情報の使用

最も危険な攻撃は、最も単純な攻撃でもあります。攻撃者は、ユーザーがすでに資格情報を持っているリソースを 含む資格情報なし iframe を埋め込みます。そして攻撃者は iframe 内のパーソナライズされたリソースを読み取ります。 これらは公開データではありません。

緩和策:

資格情報なし iframe は、そのオリジンによって保存された既存の資格情報にアクセスできません。 これには Cookie が含まれます。オリジンの共有ストレージ内の任意のデータも含まれます。これは、 それが資格情報を使用して取得された可能性があり、したがってパーソナライズされている可能性があるためです。 資格情報なし iframe は、攻撃者が既存の資格情報を使用してリソースを読み込むことを防ぐため、 白紙の状態から始まります。

7.3. 新しい資格情報の使用

この攻撃では、攻撃者は資格情報なし iframe を埋め込みます。上で説明したように、資格情報と共有ストレージに 関して、資格情報なし iframe は白紙の状態から始まります。しかし、資格情報なし iframe は新しい資格情報を 登録し、それを使用してパーソナライズされたリソースを要求することができます。攻撃者はそれらを読み取ることが できます。実際には、このシナリオは 2 つに分けられます。第一は、iframe サイトを機能させるために必要な状態を 保存する資格情報の使用であり、それは特定のユーザーに固有ではありません。この場合は、公開アクセス可能な データであるため問題ありません。第二は、ユーザーによってパーソナライズされた状態であり、これはユーザーが 資格情報なし iframe にログインした後に取得されます。

最後に、そのような資格情報がどれくらい持続すべきか、また資格情報なし iframe 間でどのように共有されるべきか という問題があります。たとえば、ユーザーが正当なページを訪問し、同じオリジン A の資格情報なし iframe A で ログインしたとします。その後、ユーザーが同じオリジン A の資格情報なし iframe を持つ攻撃者ページを訪問します。 もし A にまだログインしているなら、攻撃者ページはパーソナライズされたサブリソースからデータを盗むことができます。

緩和策:

ユーザーが iframe に直接資格情報を入力してログインする場合、そのユーザーは、オムニボックスに表示される URL とは異なるページ内の iframe にログインしています。これは、攻撃が発生するために必要なユーザー操作と 結果の両方において、フィッシング攻撃に似ています。この場合、追加の緩和策は必要ないはずです。

ユーザーがポップアップ駆動の OAuth フロー（または今後の WebID API）を使用している場合、 状況はユーザーの視点から理解するのがより困難です。これが起こるのを防ぐため、iframe がポップアップを開く能力 （例: すべてのポップアップは no-opener が設定された状態で開かれる）と、出荷時の WebID API へのアクセスを制限します。

資格情報の存続期間と共有に関しては、それらは資格情報なし iframe の存続期間に束縛されます。 したがって、ページが資格情報なし iframe を作成した場合、資格情報なし iframe のサブツリー内の文書は 資格情報と共有ストレージの白紙の状態を得ます。サブツリー内の文書は資格情報を作成できます。 それらは（同一オリジンポリシーを尊重する限り）互いに共有でき、かつ互いの間でのみ共有できます。 したがって、同じオリジンを持つ 2 つの資格情報なし iframe が同時に 2 つのページで開かれている場合、 資格情報なし iframe は資格情報を共有できません。資格情報なし iframe が破棄されると、そのサブツリーで 作成された資格情報にはもうアクセスできなくなるべきです。これにより、資格情報なし iframe の機能を可能な限り 保ちつつ、誤ってデータを漏えいするリスクを最小限に抑えることが保証されます。

7.4. ネットワーク上の位置に基づくパーソナライズされたリソース

これは前述の攻撃の変種であり、ユーザーが、自身のネットワーク上の位置のためにのみアクセスを許可されている プライベートサブリソースを持つ iframe を埋め込む場合です。たとえば、ユーザーのプライベートネットワーク上に あるリソース、またはユーザーの IP アドレスに基づいてパーソナライズされたリソースです。

緩和策:

プライベートネットワークの場合は、Private Network Access 制限を展開することで対処する予定です。 Private Network Access restrictions によって導入される CORS プリフライト中に、サーバーは Sec-Fetch-COEP ヘッダーを確認することで、そのリソースが資格情報なし iframe コンテキストでレンダリングされるかを チェックできます。HTTPS を有効にしているローカルネットワーク文書のみが潜在的に露出する可能性がある点に 注意してください（COI を持つページによって HTTP リソースが読み込まれることは MIX が防ぐべきであるため）。 これは強力な緩和策ではありませんが、一般的な IoT デバイスのようなものでは重要になります。 IP アドレスに基づいてパーソナライズされたリソースの他のケースは、そもそもセキュリティ上の落とし穴であると 論じられます。全体として、より多くのリクエストで資格情報を使用しない利点と比較して、そこでのリスク増加は 許容できると考えています。

7.5. ユーザー入力の取得

この攻撃では、攻撃者はユーザー入力を受け取ることができる資格情報なし iframe を埋め込みます。 そしてそれがユーザー入力を読み取ります。

緩和策:

これは資格情報なし iframe の範囲外です。攻撃者は、公開利用可能なリソースを使用して偽ページを構築し、 ユーザーにデータを入力させるフィッシング攻撃をすでに実行できます。この攻撃は同等です。 なぜなら、ナビゲーションバーにユーザーへ表示される URL は依然として攻撃者のものだからです。

7.6. サイドチャネルを使用して自身をパーソナライズする資格情報なし iframe

資格情報なし iframe は、資格情報がないにもかかわらず、サイドチャネル（例: broadcast channels, postMessage）を使用して何らかのパーソナライズを得ようとする可能性があります。すると、パーソナライズされたリソースは 埋め込み元によって読み取り可能になります。

緩和策:

上で強調した仕組みがリソースをパーソナライズする一般的な方法であるかどうかによっては、これは範囲外かもしれません。 私たちが防御したいのは、疑っていない Web サイトが埋め込まれ、その埋め込み元によって攻撃されてユーザーデータを 盗まれることです。資格情報なし iframe が credentialless iframe の制約を逃れて自身をパーソナライズしようと 強く望むなら、その iframe は読み込まれるコンテキストとリスクを理解し、それを受け入れていると論じることができます。 私たちのセキュリティモデルが資格情報なし iframe の外部で十分安全であるなら、そのパーソナライズは いずれにしても iframe と同一オリジンのリソースにのみ影響します。フレーム化された文書へのクロスオリジンリソースは 依然として非パーソナライズのままであり、セキュリティの観点からは COEP:credentialless と同等になります。

8. プライバシー考慮事項

この API がもたらす主なプライバシー上の脅威は、[Spectre] のようなサイドチャネル攻撃による データ漏えいのリスクです。上記の 脅威モデル で詳述したように、 この API は [Spectre] 攻撃に対する意味のある防御を提供し、 したがってプライバシーリスクをもたらさないと考えています。

9. セルフレビュー質問票

[SecurityPrivacyQuestionnaire] (link) を参照してください

9.1. この機能は Web サイトまたは他の関係者にどのような情報を公開する可能性があり、その公開はどのような 目的で必要ですか？

window.credentialless メソッドは、文書が資格情報なし iframe 内に読み込まれているかどうかを公開し、 既存の資格情報または保存済みリソースの可用性に応じて文書が挙動を変更できるようにします。

9.2. 仕様内の機能は、意図した用途を可能にするために必要な最小限の情報を公開していますか？

はい。公開される唯一のものは、文書が資格情報なし iframe 内に埋め込まれているかどうかです。

9.3. 仕様内の機能は、個人情報、個人を識別可能な情報 (PII)、またはそれらから派生した情報を どのように扱いますか？

この機能は PII を扱いません。

9.4. 仕様内の機能はセンシティブな情報をどのように扱いますか？

この機能はセンシティブな情報を扱いません。

9.5. 仕様内の機能は、閲覧セッションをまたいで永続する、オリジン用の 新しい状態を導入しますか？

いいえ、この機能はオリジン用の新しい状態を導入しません。

9.6. 仕様内の機能は、基盤プラットフォームに関する情報をオリジンに公開しますか？

いいえ、この機能は基盤プラットフォームに関係なく同じように振る舞います。

9.7. この仕様は、オリジンがデータを基盤プラットフォームへ送信することを許可しますか？

いいえ、この機能はオリジンが基盤プラットフォームへ送信できるデータを変更しません。

9.8. この仕様の機能は、オリジンがユーザーのデバイス上のセンサーへアクセスすることを許可しますか？

いいえ、この機能はセンサーアクセスに影響しません。

9.9. この仕様の機能は、新しいスクリプト実行／読み込み機構を有効にしますか？

いいえ、この機能は新しいスクリプト実行／読み込みを有効にしません。

9.10. この仕様の機能は、オリジンが他のデバイスへアクセスすることを許可しますか？

いいえ、この機能は 1 つのデバイス内に厳密に限定されます。

9.11. この仕様の機能は、ユーザーエージェントのネイティブ UI に対する一定程度の制御を オリジンに許可しますか？

いいえ、この機能は UI に影響しません。

9.12. この仕様の機能は、どのような一時識別子を作成または Web に公開しますか？

一時識別子は作成されません。

9.13. この仕様は、ファーストパーティコンテキストとサードパーティコンテキストでの挙動を どのように区別しますか？

ファーストパーティとサードパーティが資格情報なし iframe を埋め込む能力の間に区別はありません。 これは COEP の再帰的な性質によるものです。フレーム内で COEP を展開するには、すべての子フレームが まず COEP を展開する必要があります。これは COEP の展開を支援する仕組みであるため、サードパーティ iframe にも、 自身のサードパーティコンテンツを資格情報なし iframe として埋め込めるようにすることで、 自分自身の COEP 展開を容易にする選択肢を提供したいと考えています。

9.14. この仕様の機能は、ブラウザーのプライベートブラウジングまたはシークレットモードの コンテキストでどのように機能しますか？

通常モードとの違いはありません。

9.15. この仕様には "Security Considerations" と "Privacy Considerations" の両方のセクションがありますか？

はい:

9.16. 仕様内の機能は、オリジンが既定のセキュリティ保護を低下させることを可能にしますか？

この機能は secure context と同一オリジンポリシーに影響しません。現在 COOP と COEP が有効であることの背後で 制限されている機能を使用できるようにはします。しかし、これを安全にするために文書に制限を課します。

9.17. あなたの機能は、非「完全にアクティブ」な文書をどのように扱いますか？

資格情報なし iframe は iframe 内の文書にのみ影響します。back/forward cache 機能はメインフレームナビゲーションに対してのみ実装される、という一般的な仮定があります。 この仮定のもとでは、特別に行うべきことはありません。

サブフレームレベルで back/forward cache を実装する仮想的な Web ブラウザーは、 "credentialless" 属性が変更された iframe 内の文書を復元すると何が起こるかを確実に考える必要があります。 たとえば、back/forward cache がその文書を復元することを防ぐことができます。

索引

この仕様で定義される用語

参照により定義される用語

参考文献

規範的参考文献

[CHIPS]
Dylan Cutler; Kaustubha Govind. CHIPS (Cookies Having Independent Partitioned State). URL: https://github.com/WICG/CHIPS
[COOKIES]
Mike West; John Wilander. Cookies: HTTP State Management Mechanism. URL: https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis-07
[CSS-COLOR-3]
Tantek Çelik; Chris Lilley; David Baron. CSS Color Module Level 3. URL: https://drafts.csswg.org/css-color-3/
[DOM]
Anne van Kesteren. DOM Standard. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMASCRIPT]
ECMAScript Language Specification. URL: https://tc39.es/ecma262/multipage/
[FETCH]
Anne van Kesteren. Fetch Standard. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML Standard. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra Standard. Living Standard. URL: https://infra.spec.whatwg.org/
[STORAGE]
Storage. URL: https://storage.spec.whatwg.org/
[StoragePartition]
Client-Side Storage Partitioning. URL: https://privacycg.github.io/storage-partitioning/
[URL]
Anne van Kesteren. URL Standard. Living Standard. URL: https://url.spec.whatwg.org/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL Standard. Living Standard. URL: https://webidl.spec.whatwg.org/

参考情報

[COEP-credentialless]
Arthur Sonzogni; et al. COEP: credentialless. URL: https://wicg.github.io/cross-origin-embedder-policy/
[COEP-require-corp]
Mike West. COEP. URL: https://wicg.github.io/cross-origin-embedder-policy/
[IndexedDB]
Nikunj Mehta; et al. Indexed Database API. URL: https://w3c.github.io/IndexedDB/
[SecurityPrivacyQuestionnaire]
Theresa O’Connor; et al. Self-Review Questionnaire: Security and Privacy. URL: https://www.w3.org/TR/security-privacy-questionnaire/
[Spectre]
Paul Kocher; et al. Spectre Attacks: Exploiting Speculative Execution. URL: https://spectreattack.com/spectre.pdf
[WEB-SQL]
Ian Hickson. Web SQL Database. 18 November 2010. NOTE. URL: https://www.w3.org/TR/webdatabase/
[WebStorage]
Ian Hickson. Web Storage (Second Edition). URL: https://w3c.github.io/webstorage/
[WhyCoopCoep]
Eiji Kitamura; Demenic Denicola. Why you need "cross-origin isolated" for powerful features. URL: https://web.dev/why-coop-coep/

IDL 索引

partial interface HTMLIFrameElement {
  attribute boolean credentialless;
};

partial interface Window {
  readonly attribute boolean credentialless;
};