プロンプトとスコープ
企業はWebアプリケーション、モバイルクライアント、アナリティクス、および広告連携を運用しています。ブラウザレベルのGlobal Privacy Controlシグナル、明示的なユーザーの選択、および変化する管轄区域のルールを尊重する必要があります。匿名ビジター、ログイン済みユーザー、複数デバイス、パートナー、およびポリシーの更新を含む、コントロールプレーンとリクエスト時の適用パスを設計してください。
中核となるスキルは分散ポリシーの適用とプライバシー状態のモデリングであるため、これはsystem-designに属します。
面接官が評価するポイント
第一に、シグナルと法的判断を分離できるか。Sec-GPCヘッダーやブラウザプロパティは入力にすぎません。適用可能性と許可される処理は、ポリシーとコンテキストから導き出されます。
第二に、優先順位とスコープを定義できるか。グローバルオプトアウトは、ルールによってブラウザ、アカウント、世帯、または管轄区域に適用される場合があります。システムはスコープを暗黙的に統合することを避けなければなりません。
第三に、データが境界から出る前に適用できるか。アナリティクス、アドテク、エクスポート、およびパートナーAPIには、バナーだけでなく、共通の判断ポイントが必要です。
第四に、判断を説明可能かつ失効可能にできるか。個人データを最小限に抑え、後からの撤回をサポートしながら、ポリシーのバージョン、ソース、タイムスタンプ、有効期限を保存します。
第五に、安全にフェイル（fail-safe）できるか。ポリシーストアの停止、古いキャッシュ、または未知の管轄区域の場合、最も制限の厳しい共有モードをデフォルトとし、観測可能な理由を出力する必要があります。
最初に明確にすべき質問
- どの管轄区域と目的がスコープに含まれ、どのルールに権限がありますか？
- GPCシグナルはログイン後のアカウントに適用されますか、それともブラウザコンテキストのみに適用されますか？
- どの目的がブロックされますか：販売、共有、ターゲティング広告、測定、またはすべてのオプション処理ですか？
- 失効はキャッシュ、キュー、ウェアハウス、パートナーにどれくらい迅速に伝播する必要がありますか？
- どのような証跡を保持する必要があり、どのデータを削除または匿名化する必要がありますか？
- すべてのアウトバウンド統合が同じポリシー決定サービスを呼び出すことができますか？
30秒の回答フレームワーク
「ブラウザのシグナルと明示的な選択をバージョン管理されたプライバシー意図に正規化し、すべてのデータ送信（egress）境界で管轄区域および目的のポリシーに照らして評価します。決定にはスコープ、ポリシーバージョン、有効期限、および理由が含まれ、オプションの共有についてはフェイルクローズ（fail-closed）動作を伴って短時間キャッシュされます。イベントによって失効がキューやパートナーに伝播され、追記のみの監査証跡に最小限の証拠が保存されます。匿名からログインへの遷移、競合するスコープ、ポリシーの変更、キャッシュの陳腐化、パートナーの障害をテストします。」
ステップごとの回答
ステップ 1: 過剰な識別を行わずに追跡入力を正規化する
エッジで、GPCシグナル、オリジン、ユーザーエージェントコンテキスト、アカウント状態、および申告された地域を取得します。ポリシーによってリンクが許可されるまで、匿名のブラウザ識別子とアカウント識別子を分離しておきます。明示的な選択を販売、共有、測定、パーソナライゼーションなどの目的に正規化します。
ステップ 2: バージョン管理されたポリシーを評価する
ポリシーサービスは、サブジェクトスコープ、目的、管轄区域、ソースシグナル、および時刻を受け取ります。allow、deny、またはunknownに加えて、ポリシーバージョン、有効期限、および理由コードを返します。GPCシグナル自体は、すべての目的があらゆる場所で禁止されていることの証明ではありません。評価エンジンが関連するルールセットを適用します。
ステップ 3: すべての送信（egress）境界で強制適用する
アナリティクス、アドテク、エクスポート、またはパートナーAPIにイベントを送信する前に、決定トークンを要求します。SDKによって偶発的な収集を減らすことはできますが、クライアントは変更される可能性があるため、サーバー側で適用する必要があります。キューやバッチジョブは、エンキュー時だけでなく、配信前にも決定を再確認します。
ステップ 4: 変更と失効を伝播する
スコープ設定されたサブジェクト参照をキーとするプライバシー意図イベントを発行します。コンシューマーはキャッシュを無効化し、以後のエクスポートを停止し、保持されているデータに該当する削除または抑制ワークフローのマークを付けます。パートナーは、目的、スコープ、有効期間、および検証データを含む最小限の契約を受け取ります。トークンで十分な場合に生の識別情報をブロードキャストしてはなりません。
ステップ 5: ペイロードではなく決定を監査する
リクエストクラス、サブジェクトスコープハッシュ、目的、ポリシーバージョン、シグナルソース、決定、およびタイムスタンプを記録します。アクセスを暗号化し、保持期間を制限し、運用ログをユーザー向けの開示説明から分離します。監査レコードは、機密性の高いイベント内容をコピーすることなく、転送が許可または拒否された理由に答えられるようにする必要があります。
ステップ 6: フェイルクローズとオブザーバビリティの確保
ポリシーの検索や失効の伝播に失敗した場合、オプションのデータ共有をブロックし、再試行のために作業をキューに入れます。メトリクスには、未知の決定、古いポリシーバージョン、拒否された転送、パートナーの確認応答、失効までの時間を表示する必要があります。アラートは、ポリシーの停止と正当なオプトアウトの増加を区別できなければなりません。
ステップ 7: 境界と敵対的ケースをテストする
匿名ブラウジング後のログイン、複数タブ、アカウントとブラウザのスコープ競合、クロックスキュー、地域移動、シグナルのリプレイ、キャッシュの期限切れ、キューの再配信、パートナーのタイムアウト、ポリシーのロールバックをテストします。拒否された決定が代替のエクスポートパスを介してバイパスされないことを検証します。
模範回答
「バージョン管理されたプライバシー決定サービスを構築し、すべてのオプションのデータ送信境界でその短命な決定トークンを要求します。エッジはブラウザスコープとアカウントスコープを区別したまま、GPCと明示的な選択を正規化します。ポリシー評価は、目的、管轄区域、ソース、および有効期間を組み合わせ、理由とポリシーバージョンを返します。キューとパートナーは配信前に再確認し、失効イベントはキャッシュを無効化して抑制ワークフローをトリガーします。
このサービスはオプションのデータ共有に対してフェイルクローズし、最小限の決定証拠を記録し、未知の決定、陳腐化したキャッシュ、確認応答、失効までの時間のメトリクスを公開します。テストでは、ログイン遷移、競合するスコープ、リプレイ、地域の変更、再試行、および代替エクスポートパスをカバーします。バナー単体では強制力になり得ません。」
よくある間違い
- GPCを普遍的なブール値として扱う → スコープと管轄区域が失われる → シグナル、目的、およびポリシーを一緒に評価する。
- ブラウザ内でのみ強制適用する → 改変されたクライアントがコントロールをバイパスする → サーバー送信時に適用する。
- 匿名IDとアカウントIDを即座にリンクする → 不要なプロファイリングになる → 正当な理由ができるまでスコープを分離しておく。
- エンキュー時のみ同意を確認する → 失効と配信の間で競合が発生する → 送信前に再確認する。
- ポリシー停止時にフェイルオープンする → オプションのデータが漏洩する → フェイルクローズして再試行する。
- 完全なペイロードを監査ログに記録する → ログがプライバシーリスクになる → 最小限の決定証拠を保存する。
- パートナーの確認応答を無視する → 伝播が未検証になる → 受領確認と期限を追跡する。
フォローアップ質問
フォローアップ 1: GPCは同意バナーを置き換えるものですか？
いいえ。これはブラウザレベルのシグナルであり、その意味は適用されるポリシーによって異なります。ユーザーインターフェースで追加の選択肢を収集することはできますが、強制適用は評価された決定に従う必要があります。
フォローアップ 2: ログイン後は何が起こりますか？
ブラウザとアカウントのスコープを明確に区別したまま、文書化されたリンクルールを適用します。ポリシーの裏付けなしに、匿名のシグナルをより広範なアカウント設定に暗黙的に変換してはなりません。
フォローアップ 3: 決定はどのくらいの期間キャッシュできますか？
リスクとポリシーが許容する期間に限られます。短いTTL、バージョン管理された無効化、および鮮度が証明できない場合のフェイルクローズ動作を使用します。
フォローアップ 4: オフラインのパートナーはどのように処理しますか？
確認応答の期限後にオプションの配信を停止し、最小限の再試行レコードを保持し、パートナーが復帰した後に調整（リコンサイル）します。
フォローアップ 5: 監査レコードには何を含めるべきですか？
スコープ参照、目的、シグナルソース、ポリシーバージョン、決定、理由、および時刻で通常は十分です。イベントペイロードのコピーは避けてください。
フォローアップ 6: バイパスが存在しないことをどのように証明しますか？
すべての送信パスをインベントリ化し、共有ミドルウェアで決定トークンを要求し、SDK、バッチジョブ、エクスポート、およびパートナーの再試行に対して拒否テストを実行します。