1. はじめに
このセクションは規範的ではありません。
関連ウェブサイトセット（「RWS」）は、開発者がサイト間の関係を宣言するためのフレームワークを提供し、 これによりユーザーエージェントは、ユーザー向けの目的のために、Cookieなどのクロスサイトデータへの限定的なアクセスを許可できます。 これはStorage Access APIの使用を通じて実現されます。
この文書は、ユーザーエージェントが関連 ウェブサイトセットリストとどのように統合すべきかを定義します。RWSリストの構造および提出時に実行される 技術的検証の正規のリファレンスについては、関連 ウェブサイトセット提出ガイドラインを参照してください。
2. インフラストラクチャ
この仕様はInfra標準に依存します。[INFRA]
3. リストの消費
ユーザーエージェントは、正規の関連 ウェブサイトセットリストを定期的に（例：2週間ごとに）消費し、更新可能なコンポーネントとして 個々のクライアント（例：ブラウザアプリケーション）に配信すべきです。
ここで更新間隔について 推奨を行うことはできるでしょうか？ href="https://github.com/wicg/first-party-sets/issues/122">[wicg/first-party-sets Issue #122]
個々のクライアントは、再起動時、または起動時に、新たにダウンロードされた場合には、関連ウェブサイトセットのリストを構築する必要があります。 クライアントは、他のいかなる時点でもリストを再構築してはなりません。
RWSリストは、UTF-8でエンコードされたファイルであり、JSONオブジェクトとして解析可能な内容を含み、 関連 ウェブサイトセット提出ガイドラインに記載された[JSON-SCHEMA]に準拠します。
注: スキーマへの適合性は提出時に検証されます。 したがって、ユーザーエージェントがクライアント上で適合性を再度検証する必要はありません。 この仕様のアルゴリズムは、ユーザーエージェントがRWSリストをどのように解析すべきか、 また特定のセットがクライアントの観点からいつ有効と見なされるべきかを記述します。
Public Suffix Listのバージョンがサーバーとクライアントで異なる場合には、クライアント側の検証が 必要になる可能性があります。 href="https://github.com/wicg/first-party-sets/issues/125">[wicg/first-party-sets Issue #125]
JSON data-link-type="dfn" href="https://infra.spec.whatwg.org/#byte-sequence" id="ref-for-byte-sequence">バイト シーケンス bytesから関連ウェブサイトセットのリストを構築するには、ユーザーエージェントは次の手順を実行すべきです：
-
jsonを、bytesを用いてJSONバイトをinfra値に解析するの結果と する。
-
jsonが解析例外である場合、またはjsonが順序付きマップでない場合、 またはjson[“sets”]が存在しない場合は、リターンし、必要に応じてリストの取得を再試行するか、 その他のエラー回復タスクを実行する。
-
jsonの各entryについて：
-
setを関連ウェブサイトセットとする。
-
entry[“primary”]が存在しない場合は、続行する。
-
この仕様は 現在、リスト全体を拒否するのではなく、無効なセット（primaryエントリが欠落しているもの）をスキップすることを提案しています。 しかし、サーバーが常に有効な情報を保持していることが期待されることを考えると、 完全な拒否に利点がある可能性があります。 href="https://github.com/wicg/first-party-sets/issues/126">[wicg/first-party-sets Issue #126]
-
setのprimaryをentry[“primary”]に設定する。
-
ccTLDsを、entry[“ccTLDs”]から等価マップを解析するの結果とする。 ccTLDsが失敗の場合は、続行する。
-
setのccTLDsをccTLDsに設定する。
-
serviceSitesを、entry[“serviceSites”]からサブセットを解析するの結果とする。 結果が失敗の場合は、続行する。
-
setのserviceSitesをserviceSitesに設定する。
-
associatedSitesを、entry[“associatedSites”]からサブセットを解析するの結果とする。 結果が失敗の場合は、続行する。
-
setのassociatedSitesを associatedSitesに設定する。
-
setをユーザーエージェントの関連ウェブサイトセットのリストに追加する。
ユーザーエージェントは、クライアントが最終的にこの仕様で定義された有効な data-link-type="dfn" href="#list-of-related-website-sets" id="ref-for-list-of-related-website-sets①">関連ウェブサイトセットのリストを保持することを保証する限り、 例えば最適化のために、クライアントへの配信前にリストを別の形式に前処理することを選択してもかまいません。
4. データ構造
ユーザーエージェントは、グローバルな関連ウェブサイトセットのリストを維持します。これは関連ウェブサイトセットのリストです。
関連ウェブサイトセット は、次の項目を持つ構造体です：
primary: セットの主要ドメインを表すサイト。
ccTLDs: 提出者によって指定された、セットの等価な国コードトップレベルドメインを表す等価マップ。
associatedSites: 関連サブセット内のサイトのリスト。
serviceSites: サービスサブセット内のサイトのリスト。
注: これらのフィールドの意味に関する追加の コンテキストについては、関連 ウェブサイトセット提出ガイドラインを参照してください。
等価マップは、 サイトから data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/browsers.html#site" id="ref-for-site④">サイトの data-link-type="dfn" href="https://infra.spec.whatwg.org/#list" id="ref-for-list③">リストへの順序付きマップです。
文字列 inputからサイトを 解析および検証するには、次の手順を実行する：
リスト inputからサブセットを解析するには、次の手順を実行する：
-
listを空のリストとする。
-
inputの各itemについて：
-
siteを、itemからサイトを解析および 検証するの結果とする。
-
siteが失敗の場合は、失敗を返す。
-
siteをlistに追加する。
-
-
listを返す。
順序付きマップ inputから等価 マップを解析するには、次の手順を実行する：
-
mapを空の等価マップとする。
-
inputの各key → valueについて：
-
keySiteを、keyからサイトを解析および 検証するの結果とする。結果が失敗の場合は、失敗を返す。
-
equivalentsを空のリストとする。
-
valueの各equivalentについて：
-
equivalentSiteを、equivalentからサイトを解析および検証するの結果とする。 結果が失敗の場合は、失敗を返す。
-
equivalentSiteをequivalentsに追加する。
-
-
map[keySite]をequivalentsに設定する。
-
-
mapを返す。
5. 関連ウェブサイトセットへの包含の検証
RWSの下では、サイト site1は、等価マップ equivalentsが与えられたとき、 equivalents[site1]がsite2を含むか、 またはequivalents[site2]がsite1を含む場合に、別のサイト site2と等価であると見なされます。
数学的な等価関係と 混同されるのを避けるために、これを改名すべきでしょうか？ href="https://github.com/wicg/first-party-sets/issues/123">[wicg/first-party-sets Issue #123]
所与の関連ウェブサイトセット setにおける、所与のサイト siteのメンバー タイプを判定するには、次の手順を実行する：
-
setのassociatedSitesの各associatedSiteについて：
-
setのserviceSitesの各serviceSiteについて：
-
“none”を返す。
所与のサイト siteの関連 ウェブサイトセットを見つけるには、次の手順を実行する：
-
ユーザーエージェントの関連 ウェブサイトセットのリストの各setについて：
-
typeを、setにおけるsiteのメンバータイプとする。
-
typeが“none”でない場合は、setを返す。
-
-
nullを返す。
注: 関連 ウェブサイトセット提出ガイドラインでは、各サイトが多くても1つの関連ウェブサイトセットにのみ 出現できることが要求されており、これは提出時に検証されます。このため、ユーザーエージェントはこれらの手順を実行する際に、 関連ウェブサイトセットのリストの順序を気にする必要はありません。
単一の関連ウェブサイトセット内の関連 サイトの上限を、実装定義の値として定義し、3とすることを推奨します。
注: この上限は、関連サイトの適格性を判定する際に、 関連サブセットの先頭に列挙されたサイトのみを考慮するために使用されます。これは乱用を抑制し、 ユーザーとユーザーエージェントが特定の関連ウェブサイトセットが存在する必要がある理由を理解するのを助けることを 目的としています。ユーザーエージェントはこの目的に基づいて異なる数を選択してもかまいません。
サイト embeddedSiteは、次の手順がtrueを返す場合、サイト topLevelSiteに埋め込まれたときに同一パーティ メンバーシップの資格がある：
-
setを、topLevelSiteの関連ウェブサイトセットを見つけるの結果とする。
-
setがnullの場合は、falseを返す。
-
topLevelTypeを、setにおけるtopLevelSiteのメンバータイプとする。
-
topLevelTypeが“associated”であり、かつtopLevelSiteとsetが与えられたときの関連サイトの適格性を判定するの結果が falseの場合は、falseを返す。
-
topLevelTypeが“service”の場合は、falseを返す。
-
typeを、setにおけるembeddedSiteのメンバータイプとする。
-
typeが“none”の場合は、falseを返す。
-
typeが“associated”の場合は、embeddedSiteとsetが与えられたときの関連サイトの適格性を判定するの結果を返す。
-
trueを返す。
所与のサイト siteおよび関連ウェブサイトセット setが与えられたときに関連サイトの適格性を判定するには、次の手順を実行する：
-
setのassociatedSitesが siteを含まない場合は、falseを返す。
-
indexを、setのassociatedSitesにおけるsiteのインデックスとする。
-
indexが関連サイトの 上限以上の場合は、falseを返す。
-
trueを返す。
所与の環境設定オブジェクト settingsは、次の手順がtrueを返す場合、そのトップレベルの埋め込み元と同一パーティである：
-
topLevelSiteを、settingsの data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin" id="ref-for-concept-environment-top-level-origin">トップレベルオリジンからサイトを取得するの結果とする。
-
embeddedSiteを、settingsの data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-settings-object-origin" id="ref-for-concept-settings-object-origin">オリジンからサイトを取得するの結果とする。
-
embeddedSiteがtopLevelSiteに埋め込まれたときに同一パーティ メンバーシップの資格があるかどうかを返す。
所与の環境設定オブジェクト settingsと data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/browsers.html#concept-origin" id="ref-for-concept-origin">オリジン originは、次の手順がtrueを返す場合、埋め込みコンテキストにおいて同一パーティである：
-
topLevelSiteを、settingsの data-link-type="dfn" href="https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-top-level-origin" id="ref-for-concept-environment-top-level-origin①">トップレベルオリジンからサイトを取得するの結果とする。
-
embeddedSiteを、originからサイトを取得するの結果とする。
-
embeddedSiteがtopLevelSiteに埋め込まれたときに同一パーティ メンバーシップの資格があるかどうかを返す。
6. Storage Access APIとの統合
requestStorageAccess()
を修正し、ステップ13.5の前（すなわち使用許可を要求するの前）に次の手順を挿入する：
-
settingsをdocの関連設定オブジェクトとする。
-
settingsがそのトップレベルの埋め込み元と 同一パーティである場合、ユーザーエージェントは data-link-type="dfn" href="https://w3c.github.io/permissions/#dfn-granted" id="ref-for-dfn-granted">付与済みでprocess permission stateを実行し、残りの手順を中止してもよい。
requestStorageAccessFor(requestedOrigin)
を修正し、ステップ13.8の前（すなわち使用許可を要求するの前）に次の手順を挿入する：
-
settingsをdocの関連設定オブジェクトとする。
-
settingsとrequestedOriginが埋め込みコンテキストにおいて同一パーティである場合、 ユーザーエージェントは、pを data-link-type="dfn" href="https://webidl.spec.whatwg.org/#resolve" id="ref-for-resolve">解決するために、globalが与えられた権限タスクソース上でグローバルタスクをキューに入れ、残りの手順を中止してもよい。
7. 関連ウェブサイトセットの変更の処理
新しい関連ウェブサイトセットのリストを構築した結果として、サイト siteが関連ウェブサイトセットから離脱する場合、 ユーザーエージェントは、次の手順を実行することにより、そのサイトが関連ウェブサイトセット内の他のサイトが保持する データまたは共有識別子へのアクセスを一切保持しないことを保証しなければなりません：
-
siteが不透明なオリジンでないことをアサートする。
-
domainをsiteのホストとする。
-
ホストの登録ドメインが domainである、ユーザーエージェントに既知の各originについて：
-
descriptorを、
nameを“storage-access”に初期化した、新たに作成されたPermissionDescriptorとする。 -
key[0]がsiteであるか、またはkey[1]がoriginである、descriptorのすべての権限ストアエントリを削除する。
-
ウェブからアクセス可能なストレージがoriginから確実に削除されるように、追加の実装定義の手順を実行する。
このセクションでは、 サイトがいつRWSから離脱するかをユーザーエージェントがどのように把握できるかについて、より詳細を提供すべきです。 href="https://github.com/wicg/first-party-sets/issues/124">[wicg/first-party-sets Issue #124]
8. その他の機能との統合
ユーザーエージェントは、RWSを通じて宣言されたドメイン関係を、その他の実装定義の目的のために使用してもかまいません。 その場合でも、RWSリストの消費および保存、ならびに同一パーティメンバーシップの適格性チェックについては、 この仕様の残りの部分に従わなければなりません。
注: 例えば、 href="https://github.com/GoogleChrome/ip-protection">ChromeのIP保護提案には、 ファーストパーティおよびサードパーティのコンテキストを判定する目的でRWSに依存することが含まれています。
9. プライバシーに関する考慮事項
9.1. ユーザーへの透明性と制御の提供
RWSを使用して2つのサイト間の関係を推論するユーザーエージェントは、このユーザーエージェントの選択について ユーザーが知らされることを保証し、ユーザーエージェントが行った選択をユーザーが閲覧および制御する機会を 提供すべきです。
9.2. 非RWS環境との互換性の確保
一部のユーザーエージェントは、特定の環境（プライベートブラウジングモードなど）で、あるいは一切RWSを サポートしないことを選択する場合があります。すべてのユーザーエージェントおよび仕様は、それぞれのAPI統合において このことを念頭に置き、ユーザーと開発者のために動作するソリューションへと優雅にフォールバックすることを目指すべきです。
クロスサイトCookieへのアクセスを提供するために、この仕様はStorage Access APIの使用を通じて 非RWS環境との互換性を確保することを目指しています。これは開発者に、要求への拒否を処理するインターフェースを提供し、 RWSの代替としてプロンプトやヒューリスティックなどのメカニズムを採用する柔軟性をユーザーエージェントに与えます。
9.3. リスト変更によるプライバシー漏洩の防止
開発者は、サイトを追加または削除するために、自身のセットへの変更を提出する場合があります。セットへのメンバーシップは、 Storage Access APIの自動付与を介して クロスサイトCookieへのアクセスを提供する可能性があるため、これらの移行が、ユーザーがこれまでに所属してきた すべてのRWSにわたってユーザーIDを結びつけることのないよう、注意を払う必要があります。特に、ドメインがそのセット メンバーシップを変更する際に、ある関連ウェブサイトセットから別のセットへユーザー識別子を移転できないように しなければなりません。セットメンバーが常にクロスサイトCookieへのアクセスを要求して付与されるとは限りませんが、 セット移行の処理を簡素化するために、そのようなアクセスは常に付与されるものとして扱うことを提案します。
このため、この仕様は、サイトがセットから削除される際に、それらの権限またはサイトデータに依存する フェッチを開始する前に、所与のサイトのサイトデータおよびストレージアクセス権限をクリアすることを ユーザーエージェントに要求します。
注: ほとんどのフェッチは、クリアが必要な データに依存しないため、ユーザーエージェントは要求のレイテンシを最適化することが推奨されます。
10. セキュリティに関する考慮事項
10.1. 新規および既存のセキュリティ境界の弱体化の回避
プライバシー向上のために境界を厳格化するウェブプラットフォームの変更は、多くの場合セキュリティにも 良い影響を与えます。例えば、キャッシュパーティショニングはキャッシュプロービング攻撃を制限し、 サードパーティCookieのブロックは、デフォルトでクロスサイトリクエストフォージェリ（CSRF）の 実行をはるかに困難にします。ユーザーエージェントが、ウェブ上のサイトまたはオリジンに基づく既存の境界を 置き換えたり拡張したりするために関連ウェブサイトセットを使用しようとする場合、プライバシーへの影響だけでなく、 セキュリティへの影響も考慮することが重要です。
共通のRWS内のサイトは、大きく異なるセキュリティ要件を持つ場合があります。例えば、あるセットには ユーザー認証情報を保存するサイトと、信頼できないユーザーデータをホストする別のサイトが含まれる可能性があります。 同じセット内であっても、サイトはデータ露出を制御し続けるためにクロスサイトおよびクロスオリジンの制限に 依存しています。合理的な範囲で、RWS内の侵害されたサイトが、セット内の他のサイトの完全性に影響を与えることは できないようにすべきです。
この考慮事項には、パフォーマンスや相互運用性などの利益と、ユーザーやサイトにとってのリスクとの間で、 必要なトレードオフが常に伴います。ユーザーエージェントは、このトレードオフを管理するために、 オリジンごとのオプトインまたはオプトアウトなどの追加メカニズムを提供すべきです。
謝辞 class="self-link" href="#acknowledgements">
W3Cプライバシーコミュニティグループの他のメンバーは、以前にもSamePartyクッキーの代わりにStorage Access API、 または同等のAPIの使用を提案していました。@jdcauley（ href="https://github.com/WICG/first-party-sets/issues/14#issuecomment-785144990">1）、 @arthuredelstein（2）、および@johnwilander（ href="https://lists.w3.org/Archives/Public/public-privacycg/2022Jun/0001.html">3）に感謝します。
ブラウザベンダー、ウェブ開発者、およびウェブコミュニティのメンバーは、W3Cプライバシーコミュニティグループでの この提案のインキュベーション中に貴重なフィードバックを提供しました。
この提案には、以前の共同編集者であるDavid BenjaminおよびHarneet Sidhanaからの重要な貢献が含まれています。
また、Chris FredricksonおよびShuran Huangからの貢献にも感謝します。