requestStorageAccessFor API

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

このバージョン:
https://github.com/privacycg/requestStorageAccessFor
課題追跡:
GitHub
仕様内にインライン表示
編集者:
(Google)
(Google)

概要

requestStorageAccessFor API は、トップレベルサイトが埋め込まれたオリジンに代わってクロスサイト Cookie へのアクセスを要求できるようにします。

この文書の位置付け

この仕様は、HTML 現行標準に統合されることを意図しています。これは WHATWG の現行標準ではなく、 W3C の標準化過程にもありません。

これは Privacy Community Group によって公開されました。 W3C Community Contributor License Agreement (CLA) では、限定的なオプトアウトが認められ、その他の条件も適用されることに注意してください。 W3C Community and Business Groups の詳細をご覧ください。

1. はじめに

この節は規範的ではありません。

多くのユーザーエージェントは、Cookie に保存された非同一サイトデータへのコンテンツからのアクセスを防止します。 これにより、非同一サイト Cookie へのアクセスに依存する埋め込みコンテンツが機能しなくなる可能性があります。

requestStorageAccessFor API を使用すると、開発者は iframe、 スクリプト、画像などの埋め込みリソースについて、非同一サイト Cookie へのアクセスを要求できます。 これは、requestStorageAccessFor(requestedOrigin) を規定することによって実現されます。このメソッドにより、トラバーサブルナビゲーション可能は、別のオリジンに代わって、非分割 Cookie へのアクセスを要求できます。

2. 基盤

この仕様は Infra 標準に依存します。[INFRA]

3. requestStorageAccessFor API

この仕様は、別のオリジンに代わって非分割データへのアクセスを要求するために使用できるメソッド (requestStorageAccessFor(requestedOrigin))を定義します。

Alex が https://social.example/ にアクセスします。ページは Cookie を設定します。この Cookie は ファーストパーティサイトコンテキストで設定されています。

その後、Alex は https://video.example/ にアクセスします。このページには https://social.example/profile-image を読み込む img があります。この場合、social.exampleDocument docサードパーティコンテキストにあり、以前に設定された Cookie が doc.cookie から参照できるかどうかは、ユーザーエージェントのストレージアクセス方針によって異なります。

https://video.example/ 上のスクリプトは、USVString requestedOriginhttps://social.example を指定して doc.requestStorageAccessFor(requestedOrigin) を呼び出すことで、https://social.example に代わってアクセスを要求できます。

注: アクセスを使用する状況は、要求されたオリジンが共有をオプトインする場合に限定する必要があります。詳細については、 § 7 プライバシーに関する考慮事項および§ 8 セキュリティに関する 考慮事項を参照してください。

非分割データとは、 サイトファーストパーティサイトコンテキストで読み込まれた場合に利用できるクライアント側ストレージです。

Documentトラバーサブルナビゲーション可能アクティブな文書である場合、その文書はファーストパーティサイトコンテキストにあります。それ以外の場合でも、 その文書がアクティブな文書であり、その関連する設定オブジェクトオリジントップレベルオリジンが互いに同一サイトである場合、その文書はファーストパーティサイトコンテキストにあります。

Documentファーストパーティサイトコンテキストにない場合、その文書はサードパーティ コンテキストにあります。

3.1. Document への変更

partial interface Document {
  Promise<undefined> requestStorageAccessFor(USVString requestedOrigin);
};
Document doc に対して USVString requestedOrigin を指定して呼び出された場合、requestStorageAccessFor(requestedOrigin) メソッドは、次の手順を実行しなければなりません。
  1. p新しい Promiseとします。

  2. doc完全にアクティブでない場合、p を「InvalidStateErrorDOMException拒否し、 p を返します。

  3. docノードナビゲーション可能トラバーサブルナビゲーション可能でない場合、 p を「NotAllowedErrorDOMException拒否し、 p を返します。

  4. docオリジン不透明なオリジンである場合、p を「NotAllowedErrorDOMException拒否し、 p を返します。

  5. doc関連するグローバルオブジェクトセキュアコンテキストでない場合、p を「NotAllowedErrorDOMException拒否し、 p を返します。

  6. parsedURL を、requestedOrigin に対してURL パーサーを実行した結果とします。

  7. parsedURL が失敗である場合、pTypeError拒否し、 p を返します。

  8. originparsedURLオリジンとします。

  9. origin不透明なオリジンである場合、p を「NotAllowedErrorDOMException拒否し、 p を返します。

  10. docオリジンorigin同一オリジンである場合、p解決して返します。

  11. descriptor を、新しく作成された TopLevelStorageAccessPermissionDescriptor とします。その name は「top-level-storage-access」 に設定し、requestedOriginorigin に設定します。

  12. has activation を、docWindow オブジェクトが一時的なアクティベーションを持つ場合は true、 それ以外の場合は false とします。

  13. 次の手順を並行して実行します。

    1. settingsdoc関連する設定オブジェクトとします。

    2. globaldoc関連するグローバルオブジェクトとします。

    3. existing state を、settings における descriptor許可状態とします。

    4. existing state許可済みである場合:

      1. global を指定し、許可タスクソース上で、 p解決するグローバルタスクをキューに追加します。

      2. 返します。

    5. existing state拒否済みである場合:

      1. docWindow オブジェクトが一時的なアクティベーションを持つ場合、 それを使用してユーザーアクティベーションを消費します。

      2. global を指定し、許可タスクソース上で、 p を「NotAllowedErrorDOMException拒否するグローバルタスクをキューに追加します。

      3. 返します。

    6. docノードナビゲーション可能トラバーサブルナビゲーション可能であることを表明します。

    7. has activation が false である場合:

      1. global を指定し、許可タスクソース上で、 p を「NotAllowedErrorDOMException拒否するグローバルタスクをキューに追加します。

      2. 返します。

    8. permissionState を、descriptor を使用して「top-level-storage-access」 の使用許可を要求した結果とします。

      注: 許可を要求し、プロンプトを表示するかどうかを決定するとき、 ユーザーエージェントは、エンドユーザー体験を形成するために実装定義の動作を適用することに注意してください。特に top-level-storage-access については、ユーザーエージェントが、プロンプトを表示せずに 許可を付与または拒否する独自の規則を適用することが知られています。

    9. permissionState許可済みである場合:

      1. global を指定し、許可タスクソース上で、 p解決するグローバルタスクをキューに追加します。

      2. 返します。

    10. docWindow オブジェクトが一時的なアクティベーションを持つ場合、 それを使用してユーザーアクティベーションを消費します。

    11. global を指定し、許可タスクソース上で、 p を「NotAllowedErrorDOMException拒否するグローバルタスクをキューに追加します。

  14. p を返します。

許可タスク ソースを直接使用すべきではありません。[privacycg/requestStorageAccessFor Issue #15]

3.2. ユーザーエージェントのトップレベルストレージアクセス方針

リクエスト request を使用して、リクエストがトップレベルストレージ アクセスを持つかどうかを判定するには、次の手順を実行します。
  1. settings を、requestクライアント関連するグローバルオブジェクト関連する設定オブジェクトとします。

  2. embedded origin を、requestURLオリジンとします。

  3. descriptor を、新しく作成された TopLevelStorageAccessPermissionDescriptor とします。その name は「top-level-storage-access」 に設定し、requestedOriginembedded origin に設定します。

  4. existing state を、settings における descriptor許可状態とします。

  5. existing state許可済み である場合、true を返します。

  6. false を返します。

4. Permissions との統合

requestStorageAccessFor API は、名前top-level-storage-access」によって識別される強力な機能を定義します。これは、次の許可関連アルゴリズムを定義します。

PermissionDescriptor
top-level-storage-access強力な機能は、PermissionDescriptor を次のように定義します。
dictionary TopLevelStorageAccessPermissionDescriptor : PermissionDescriptor {
    USVString requestedOrigin = "";
};
許可照会アルゴリズム
PermissionDescriptor permissionDescPermissionStatus status が与えられたとき、「top-level-storage-access」 許可を照会するには、次の手順を実行します。
  1. statusstatepermissionDesc許可状態に設定します。

  2. statusstate拒否済みである場合、statusstateプロンプトに設定します。

    注: 開発者にユーザーの判断を公開しないようにするため、 拒否済みの許可状態は公開されません。これは、ユーザーに対する報復や、 ユーザー体験を損なう繰り返しのプロンプト表示を防ぐためです。

許可キー型
top-level-storage-access」 機能の許可キーは、サイト型です。

注: requestedOrigin フィールドにより、許可ストアエントリが二重キー化されます。

許可キー生成アルゴリズム
オリジン originオリジン embedded origin が与えられたとき、 「top-level-storage-access」 機能の新しい許可キーを生成するには、次の手順を実行します。
  1. embedded originorigin同一サイトでない場合、null を返します。

  2. origin からサイトを取得した結果を返します。

    注: embedded originorigin同一サイトであるかどうかの検査は、 クロスサイトフレームからの許可照会を禁止することを意図しています。 これは、top-level-storage-access 許可リクエストがトップレベル閲覧コンテキストでのみ許可されるという不変条件に依存します。したがって、 この検査は query(permissionDesc) でのみ関係します。

許可キー比較アルゴリズム
top-level-storage-access」 機能について許可キー key1key2 を 比較するには、次の手順を実行します。
  1. key1 が null であるか、key2 が null である場合、false を返します。

  2. key1key2同一サイトであるかどうかを返します。

5. Fetch との統合

requestStorageAccessFor(requestedOrigin) は、トップレベル文書から要求されたオリジンへのサブリソースリクエストにおける Cookie の動作にのみ直接影響します。

HTTP ネットワークまたはキャッシュフェッチで、 Cookie をブロックするかどうかを判定するときは、次のアルゴリズムを実行します。結果が true の場合、Cookie のブロックを解除できます。
  1. has top-level access を、request に対してリクエストが トップレベルストレージアクセスを持つかどうかを判定した結果とします。

  2. has top-level access が false である場合、false を返します。

  3. is subresource を、requestサブリソースリクエストである場合は true、 それ以外の場合は false とします。

  4. allowed subresource mode を、requestモードが "cors" であり、かつ request資格情報モードが "include" である場合は true、それ以外の場合は false とします。

  5. is subresource が true で、allowed subresource mode が false である場合、false を返します。

  6. requestクライアント関連するグローバルオブジェクト関連付けられた文書トラバーサブルナビゲーション可能でない場合、false を返します。

  7. true を返します。

6. Storage Access API との統合

注: requestStorageAccessFor(requestedOrigin) の呼び出しが成功した後でも、フレームは Cookie にアクセスするために requestStorageAccess() を明示的に呼び出す必要があります。 この変更により、requestStorageAccessFor(requestedOrigin) は、以前に成功した requestStorageAccess() の許可と同様に、requestStorageAccess() の呼び出しを解決できるようになります。

requestStorageAccess() を変更して、手順 13.4 の前、すなわち一時的なアクティベーションを検査する前に、次の手順を挿入します。
  1. settingsdoc関連する設定オブジェクトとします。

  2. originsettingsオリジンとします。

  3. descriptor を、新しく作成された TopLevelStorageAccessPermissionDescriptor とします。その name は「top-level-storage-access」 に設定し、requestedOriginorigin に設定します。

  4. descriptor許可状態許可済み である場合、global を指定し、許可タスクソース上で、p解決するグローバルタスクをキューに追加し、返します。

  5. descriptor許可状態拒否済み である場合、global を指定し、許可タスクソース上で、p を「NotAllowedErrorDOMException拒否するグローバルタスクをキューに追加し、返します。

7. プライバシーに関する考慮事項

[STORAGE-ACCESS] と同様に、requestStorageAccessFor(requestedOrigin) は、クロスサイト Cookie の削除を可能にすることを意図しています。このメソッドにより、開発者は追加の制約の下で クロスサイト Cookie を再取得できます。

注: Storage Access API § 6 プライバシーに関する考慮事項と同じ考慮事項の多くが適用されます。この節では、主に相違点を扱います。

requestStorageAccess() では、埋め込み文書との対話が必要です。トップレベル文書との対話のみを要求することにより、requestStorageAccessFor(requestedOrigin) は潜在的なプロンプト表示の条件を緩和しますが、埋め込み文書も非常に目立つものにしたり、ユーザー操作を得るために別の 技法を使用したりできます。 実装定義の受諾手順と拒否手順は、ユーザーエージェントが適切と判断するロジックに基づいて 悪用的なリクエストを拒否できるようにすることを意図しています。 使用するプロンプトは、ユーザーが誰によるアクセス要求なのかを理解できるよう、要求の方向を明確に示す必要があります。

requestStorageAccess() と同様に、requestStorageAccessFor(requestedOrigin) にも、ユーザーの同意とプロンプト疲れの間に同じ緊張関係があります。Storage Access API とほぼ同様に、 実装定義の受諾手順と拒否手順は、この問題について異なる立場を持つ実装者が、 適切と判断する妥協を行えるようにすることを意図しています。

もう一つの違いは、コンテキストによっては許可の照会がより機密性の高いものになり得ることです。フレームは、次のいずれの状態も 要求できないようにする必要があることに注意してください。

前者の場合、偽のドメインまたはその組み合わせを識別子として使用できるようになります。後者の場合、無関係なオリジン下の状態が 公開されることになります。

8. セキュリティに関する考慮事項

requestStorageAccessFor(requestedOrigin) が、クロスサイト Cookie の削除後と比較した場合であっても、ウェブプラットフォームのセキュリティ特性を低下させないことが重要です。 サードパーティ Cookie の削除には、認証済みリクエストに依存する攻撃、たとえば CSRF を軽減するという点で、 セキュリティ上の潜在的な利点がありますrequestStorageAccessFor(requestedOrigin) が、そのような攻撃に利用される足掛かりになることは望ましくありません。

注: Storage Access API § 7 セキュリティに関する考慮事項の特性は、この提案の大部分に適用されます。具体的には、フレームレベルのアクセスは、 requestStorageAccess() が正常に呼び出された後にのみ付与されます。 フレームアクセスについて、requestStorageAccessFor(requestedOrigin) は、アクティベーションおよびプロンプトの要件を簡略化するだけです。

requestStorageAccessFor(requestedOrigin) は、トップレベル文書によって行われるサブリソースリクエストと、通知の悪用の可能性という二つの領域で、懸念の範囲を拡大します。

8.1. サブリソースリクエスト

この API によって提案される具体的なセキュリティ制御は、次のとおりです。

さらに、トップレベル文書から開始されたリクエストのみが、SameSite=None Cookie を含める対象となります。 これにより、他の埋め込みフレームが昇格された権限を受け取らないことが保証されます。

8.2. 通知の悪用

[STORAGE-ACCESS] とは異なり、埋め込み文書ではなくトップレベル文書との対話のみが必要です。 これにより、プロンプトが表示される可能性は高まります。

Storage Access API と同様に、拒否時にはユーザーアクティベーションが消費されるため、リクエストの繰り返しが防止されます。

実装定義の拒否手順により、悪用する主体に対して数値的な制限や拒否リストを適用することもできます。

§ 7 プライバシーに関する考慮事項で述べたように、リクエストの方向性を考慮し、 ユーザーエージェントのプロンプトの文言では、どのサイトがストレージアクセスリクエストを開始したかを示す必要があります。

適合性

文書の 規約

適合性要件は、説明的な表明と RFC 2119 の用語を組み合わせて 表現されます。 この文書の規範的な部分におけるキーワード “MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、 “MAY”、および “OPTIONAL” は、RFC 2119 に記載されているとおりに 解釈されるものとします。 ただし、読みやすさのため、 この仕様では、これらの単語はすべて大文字では表記されません。

この仕様のすべてのテキストは、 非規範的であることが明示された節、例、および注を除き、規範的です。[RFC2119]

この仕様の例は、“for example” という語で導入されるか、 class="example" によって 規範的なテキストから区別されます。 次に例を示します。

これは参考例の一例です。

参考注記は “Note” という語で始まり、 class="note" によって 規範的なテキストから区別されます。 次に例を示します。

注: これは参考注記です。

索引

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

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

参考文献

規範的参考文献

[DOM]
Anne van Kesteren. DOM 標準。現行標準。 URL: https://dom.spec.whatwg.org/
[FETCH]
Anne van Kesteren. Fetch 標準。現行 標準。URL: https://fetch.spec.whatwg.org/
[HTML]
Anne van Kesteren; et al. HTML 標準。 現行標準。URL: https://html.spec.whatwg.org/multipage/
[INFRA]
Anne van Kesteren; Domenic Denicola. Infra 標準。現行標準。URL: https://infra.spec.whatwg.org/
[PERMISSIONS]
Marcos Caceres; Mike Taylor. Permissions。URL: https://w3c.github.io/permissions/
[RFC2119]
S. Bradner. RFC で要件レベルを 示すために使用するキーワード。1997年3月。現行のベストプラクティス。URL: https://datatracker.ietf.org/doc/html/rfc2119
Storage Access API (SAA) の Cookie 以外のストレージへの拡張。編集者草案。URL: https://privacycg.github.io/saa-non-cookie-storage/
[URL]
Anne van Kesteren. URL 標準。現行標準。 URL: https://url.spec.whatwg.org/
[WEBIDL]
Edgar Chen; Timothy Gu. Web IDL 標準。現行 標準。URL: https://webidl.spec.whatwg.org/

参考文献

[STORAGE-ACCESS]
Storage Access API。CG 草案。URL: https://privacycg.github.io/storage-access/

IDL 索引

partial interface Document {
  Promise<undefined> requestStorageAccessFor(USVString requestedOrigin);
};

dictionary TopLevelStorageAccessPermissionDescriptor : PermissionDescriptor {
    USVString requestedOrigin = "";
};

課題索引

許可タスクソースを直接使用すべきではありません。[privacycg/requestStorageAccessFor Issue #15]