要約

  • W3Cのプライバシー作業部会は2026年9月24日にGlobal Privacy Controlの作業草案を公開した。9月17日にも前版があり、今回が初公開でも最終的な勧告でもない。
  • Sec-GPC: 1 と navigator.globalPrivacyControl は、ページ読み込み時に保持された希望を伝える。一方、任意の /.well-known/gpc.json はサイト側の一般的な対応姿勢を示す。
  • 対応ファイルは、そのファイルを読んだブラウザーの要求が実際に守られたかを示さない。送信、表明、実際の処理には別々の記録が必要だ。

利用者がページを開いた後にGPCを有効にする場面を考える。設定画面はすぐ変わるが、開いているタブがその時点でサイトに伝えた値まで遡って変わるわけではない。草案では最上位の画面遷移ごとに希望を保持し、読み込み中や読み込み後の変更は次の遷移で反映させる。ブラウザーには、値の異なるタブを知らせて再読み込みを促すことが推奨される。「いま設定がオン」という画面だけでは、先ほど何が届いたかは分からない。

GPCが運ぶのは、個人情報を第三者に売却・共有したり、異なる文脈をまたぐターゲティング広告に用いたりしないよう求める意思だ。保持した値が真ならユーザーエージェントは Sec-GPC: 1 を送り、偽ならこのヘッダーを送らない。DOM上のプロパティーも、その遷移時の値を反映する。要求の表現方法は明確になるが、サイト内外でその後どの処理が走ったかを自動的に報告する仕組みではない。

サイト側には、別の公表手段が用意されている。/.well-known/gpc.json を置くかどうかは任意で、gpc: true は少なくとも法的義務の範囲で要求に従う意図を、lastUpdate は表明時点を示す。仕様はここで明確に線を引く。このファイルは、そのファイルを取得した利用者の要求が守られたかを通知するためのものではない。既定では対応状況は不明だ。ファイルがないことを直ちに違反とみなせず、あることを個別の遵守証明ともみなせない。

残る問題は、受け取った要求がどの判断に結びつき、対象データがどこへ流れたかである。たとえば外部の分析サービスを追加すれば、昨日の表明と今日の経路の関係を再確認しなければならない。Daniel Kadeが提案するのは、受信時点、適用した判断、関連する下流の処理を日時付きで結ぶ運用上の記録だ。これは編集上の提案であり、W3Cが義務づけた監査様式でも、特定事業者の不履行を示す調査結果でもない。

GPCは削除権を一括して行使する道具ではなく、すべての広告や同じ文脈内でのデータ利用を止めるものでもない。法的効果は適用法、個人の所在地、別途の合意などによって異なり得る。草案は今後変わる可能性があり、公開だけでW3Cや会員の支持を意味しない。共通の要求を送る能力と、その要求に応じた行動を説明する責任は、最後まで分けて考えるべきだ。

出典