1. 質問と背景
あなたは複数の加盟店サイトに埋め込まれるサポートウィジェットを保守しています。無関係なトップレベルサイト間で同一ユーザーを紐付けることなく、加盟店ごとに訪問者セッションを記憶する必要があります。ブラウザは、トップレベルサイトとサードパーティオリジンごとに Cookie、localStorage、キャッシュ、ネットワーク状態を分離する可能性があります。
2. 面接官が評価しているポイント
- 共有されたサードパーティオリジンと共有ストレージパーティションを区別できているか。
- CHIPS のスコープ、必要な属性、分離セマンティクスを理解しているか。
- 真に非パーティション化された状態に対して、明示的な同意とフォールバックパスを設計しているか。
- プライバシー、ユーザビリティ、ログイン体験、互換性が1つの意思決定フレームワークに組み込まれているか。
3. 回答前の明確化のための質問
- トップレベルサイト間で何を共有する必要があり、共有アイデンティティは本当に必要ですか？
- 各サイトには独自のテナント、ユーザー、セッションの境界がありますか？
- ユーザーは1回クリックして認証できますか、それともウィジェットはインタラクションなしでロードされる必要がありますか？
- どのブラウザと埋め込みモード（iframe、ポップアップ、トップレベルナビゲーション）が重要ですか？
4. 30秒の回答フレームワーク
データ境界、デフォルト動作、承認された例外、フォールバック、検証の順で回答します。
私はセッションキーのスコープをトップレベルサイトとウィジェットオリジンに設定し、Partitioned 属性を持つセキュア Cookie を使用して、加盟店ごとに独立したセッションを持たせます。クロスサイトログインには、トップレベルナビゲーションを使用して明示的な認可を行い、有効期限の短い使い捨ての認証情報を返します。ブラウザにその機能がない場合は、匿名モードにフォールバックしてサインイン方法を案内します。複数のトップレベルサイト、サイトデータ消去、アクセス拒否テストを用いて分離を検証します。
5. ステップごとの詳細解説
ステップ 1: パーティションキーとデータクラスの定義
Google Privacy Sandbox では、サードパーティのストレージと通信はパーティションごとに分離されると説明されています。MDN では、状態のパーティショニングはクロスサイトトラッキングを削減するためのブラウザプライバシーへの取り組みであると説明されています。データを、加盟店ローカルのセッション状態、パブリックにキャッシュ可能なアセット、またはクロスサイトアイデンティティを真に必要とするアカウント状態に分類します。最初のクラスはパーティショニングをバイパスすべきではありません。
ステップ 2: サイトごとのセッションにCHIPSを使用する
CHIPS を使用すると、サードパーティ Cookie がパーティション化されたストレージを選択できるようになります。レスポンスは Partitioned; Secure を使用し、ブラウザの他の Cookie セキュリティ要件を満たす必要があります。これにより、同一のウィジェットオリジンが加盟店 A と加盟店 B で異なる Cookie ジャーを受け取るため、サポートのコンテキストがサイト間で意図せず統合されることはありません。CHIPS はトップレベルサイトごとの状態を提供するものであり、共有されたクロスサイトログインを提供するものではありません。
ステップ 3: クロスサイトアイデンティティのための明示的な認可の設計
プロダクトが複数のサイトで1つのアカウントを表示することを真に必要とする場合は、例外パスとしてトップレベルナビゲーションまたは Storage Access API を使用します。Storage Access API を使用すると、サードパーティコンテンツは、通常は非パーティション化されてアクセス不能な状態をリクエストできます。アクセスが必要な理由を説明し、適切なタイミングでリクエストし、有用な拒否時パスを提供します。認可をリクエスト元のトップレベルサイトにバインドし、短期間で有効期限が切れるようにし、取り消し可能にします。
ステップ 4: 互換性とプライバシーのマトリックスの構築
CHIPS をサポートするブラウザ、パーティション化 Cookie をサポートしないブラウザ、ストレージアクセスの拒否、サイトデータの消去、複数のトップレベルサイトの同時オープン、iframe の置き換えやナビゲーション後のリロードをテストします。Cookie の分離、セッションの復元、プロンプトの繰り返し、ステートレスモードでもコアアクションが完了するかどうかを検証します。
6. 高品質な回答例
まず、サポートウィジェットが加盟店間で同一ユーザーを特定する必要が本当にあるかどうかを確認します。私のデフォルトの回答は「不要」です。クロスサイトのリンクはプライバシーやコンプライアンスのリスクを生むため、加盟店ごとのセッションは独立しているべきです。
>
デフォルトのパスでは、ウィジェットサーバーは Partitioned; Secure Cookie を設定します。ブラウザはトップレベルサイトとウィジェットオリジンから独立したストレージパーティションを形成するため、加盟店 A のセッションは加盟店 B には存在しません。静的スクリプトや画像は通常のキャッシュを使用できますが、アイデンティティはサイト間で読み取り可能な状態には配置されません。
>
真に統合アカウントが必要なケースでは、「サインイン」ボタンを提供します。アカウントのトップレベルページに遷移して認証を完了し、元の加盟店に有効期限の短いワンタイムコードを返します。サポートされている場合、ウィジェットはユーザーの操作後に Storage Access API 経由で非パーティション化アクセスをリクエストできます。アクセスが拒否された場合やサポートされていない場合は、サイトごとの匿名セッションとトップレベルログインにフォールバックします。アカウントの混同やプロンプトの無限ループがないことを証明するために、2つのトップレベルサイト、単一サイトのデータ消去、認可拒否をテストし、同時にパーティションヒット率とログイン失敗率を追跡します。
7. よくある失敗パターン
- CHIPS をパーティション化された状態ではなく、共有されたクロスサイト Cookie として扱うこと。
- すべての状態を非パーティション化アクセスに移行し、トラッキングや障害の対象範囲を拡大してしまうこと。
- Chrome のみについて議論し、Firefox や Safari、または機能検出の失敗を無視すること。
- ユーザーのアクション、説明、拒否時のフォールバックなしに、iframe ロード時に暗黙的にアクセスをリクエストすること。
- 有効期限の長いトークンをリターン URL に直接配置し、ログ、履歴、リファラーに公開してしまうこと。
8. フォローアップ質問と回答
フォローアップ 1: なぜトップレベルサイトの URL にユーザー ID を含めないのですか？
URL はログ、履歴、分析システム、リファラーに記録される可能性があります。有効期限の短いワンタイムコードを使用し、サーバーサイドでそれを制約付きセッションと交換します。
フォローアップ 2: CHIPS Cookie によってユーザーがサインアウトされたように見えるのはどのような場合ですか？
新しいトップレベルサイトへの最初のアクセスでは、新しいパーティション化 Cookie が付与されます。これは意図的な分離です。他のサイトの Cookie を読み取ろうとするのではなく、明確なトップレベルサインインフローを提供してください。
フォローアップ 3: Storage Access API が拒否された場合、コア機能をどのように維持しますか？
クロスサイトアイデンティティをエンハンスメント（付加機能）として扱います。匿名のサポート、ヘルプコンテンツ、ローカルの加盟店セッションは引き続き機能します。過去のアカウントデータが必要な場合にのみ、ユーザーをトップレベルログインに誘導します。