グローバル・プライバシー・コントロール(GPC)

W3C作業草案

この文書の詳細
この版:
https://www.w3.org/TR/2026/WD-gpc-20260219/
公開されている最新版:
https://www.w3.org/TR/gpc/
最新の編集者草案:
https://w3c.github.io/gpc/
履歴:
https://www.w3.org/standards/history/gpc/
コミット履歴
編集者:
Sebastian Zimmeck (Wesleyan University)
Peter Snyder (Brave Software)
Justin Brookman (Consumer Reports)
Aram Zucker-Scharff (The Washington Post)
以前の編集者:
Robin Berjon (Supramundane Agency) (The New York Times 2022年9月まで)
Ashkan Soltani (Independent)
David Harbage (DuckDuckGo)
フィードバック:
GitHub w3c/gpc (プルリクエスト, 新しいイシュー, オープンなイシュー)

要約

本ドキュメントは、HTTPおよびDOMを通じて送信されるシグナルを定義します。このシグナルは、個人がウェブサイトやサービスに対して、自身の個人情報を第三者に販売または共有しないよう要求するものです。本標準は、そのような要求に法的拘束力を与える既存および今後の法的枠組みと連携することを目的としています。

このドキュメントの位置付け

このセクションは、本ドキュメントが公開された時点での位置付けを説明します。現在の W3C の出版物や、この技術レポートの最新版は、 W3C 標準・草案インデックス で確認できます。

本ドキュメントは プライバシーワーキンググループ により、 勧告トラック を用いて作業草案として公開されました。

作業草案としての公開は、W3C およびそのメンバーによる承認を意味するものではありません。

本ドキュメントはドラフトであり、随時更新、差し替え、廃止される可能性があります。進行中の作業以外の目的で引用することは適切ではありません。

本ドキュメントは W3C 特許ポリシー の下で活動するグループによって作成されました。 W3C関連成果物に関する特許開示の公開リスト を管理しています。 そのページには特許開示の手順も記載されています。ある特許が 必須クレーム を含むと考える場合、その情報は W3C特許ポリシー第6節 に従って開示する必要があります。

本ドキュメントは 2025年8月18日版 W3C プロセスドキュメント に準拠しています。

1. はじめに

このセクションは規範的ではありません。

今日のウェブサイト構築では、多くの場合、利用者が直接やり取りする企業以外の 事業者が提供するサービスに依存することがよくあります。この結果は、Web 技術の 複雑化と異なるサービス間の役割分担の帰結です。こうしたアーキテクチャはより良い Web 体験のために利用され得ますが、同時に プライバシー を侵害するために悪用されることもあります([privacy-principles])。一方、データは 限定的な運用目的のために サービス 提供者 と共有されることがありますが、また共有・利用されて 行動ターゲティングに用いられることもあり、多くの利用者が不快に感じる場合があります。

この問題に対処するために、世界各地の法域でいくつかの異なる法的枠組みが提案または制定されています。 あるモデルは追跡に対する利用者の同意に依拠します。データ最小化の原則に基づく他の モデルは、特定のデータ共有やデータ処理を完全に禁止する場合もあります。

一部の法律や提案は、利用者が自分のプライバシーを保護するよう求める権利を付与しており、 例えば「"opt out"」の要請により、自分のデータが やり取りする予定の事業者を越えて販売または共有されないよう求めることができます。しかし、 人々に訪問するすべてのサイトごとに手動で権利を表明させることは実際的ではなく、 人々に対する「"privacy labor"」の 負担を強いることになります([privacy-principles])。

本仕様はこの最後のカテゴリの法律を念頭に置いて設計されており、利用者の選好をスケールさせる 難しさという問題に対処します。具体的には、HTTP ヘッダや DOM を通じて、利用者が自分のデータの販売 の防止、第三者へのデータ共有の防止、およびクロスコンテキストのターゲティング広告への利用を 防ぐ適用される権利を、すべてのウェブサイト公開者に普遍的に信号として伝える手段を提供します。 この信号により、例えば米国カリフォルニア州の California Consumer Privacy Act における 「opt out preferences signals」に関する規定のような、これらの global opt-out ベースの法律の特定の規定([CCPA-REGULATIONS])や、コロラド州や他の州における 「universal opt-out mechanisms」に関する類似の規定を利用して、利用者が自らの情報の販売や クロス組織的なターゲティング広告への利用をオプトアウトできるようにします。

ただし、Global Privacy Control は、共有およびクロスコンテキストのターゲティング広告からの オプトアウトの表明を可能にするよう設計されていますが、すべての可能なプライバシー権や すべての広告/ターゲティングのオプトアウト権を行使することを意図したものではありません。 たとえば、GPC は削除権の行使を目的として設計されたものではありません。GPC は同一の コンテキスト 内でのデータ収集や広告ターゲティングに対処するためのものでもありません。 詳細については、法的および実装に関する考慮事項ガイドを参照してください。

本仕様は、オプトアウトモデルの規制(あるいはより広くはクロスコンテキスト追跡)を是認するものと 解釈されるべきではなく、また同意やデータ最小化に基づく他のモデルを否定するものでもありません。 代わりに、本仕様は特定の法域で利用者に付与された積極的な権利を行使可能にすることを目的として設計されています。

2. 用語の定義

ある do-not-sell-or-share interaction は、 ウェブサイトとのやり取りで、その 人が、自分のデータがやり取りの相手以外の者に販売されたり共有されたりしないことを求めているか、 あるいは自分のデータがクロスコンテキストの広告ターゲティングに使用されないよう求めていることを指します。 W3Cプライバシー原則 に関して、その人は 少なくとも 一つの データコントローラ しか存在しないことを要求しており、 またそのデータが別の コンテキスト で広告ターゲティングに使用されないことを要求しています。たとえ その コンテキスト が 同じ事業体によって所有されている場合でも。

販売・共有拒否プリファレンスとは、例えばユーザーエージェントでGlobal Privacy Control設定を有効にしたり、その設定がデフォルトのツールを利用したりすることで、「自身のデータを販売・共有しないでほしい」と要求することです(この設定は、そのツールのユーザーの一般的な期待に合致する場合があります)。このプリファレンスが有効な場合、ユーザーは販売・共有拒否インタラクションを伴ってウェブを閲覧することを期待していることを示します。

3. 販売・共有拒否プリファレンスの表明

3.1 表現フォーマット

Global Privacy Controlのプリファレンスは、全てのHTTPリクエスト(HTTPヘッダーとして)および全てのウェブサイト(Web APIプロパティとして)で伝達されるべきです。

このプリファレンスが有効な場合、その値はコンテキストに応じて1またはtrueの単一値として表現されます。

規制上、法的、またはその他の要件がない場合、ウェブサイトは 表明された Global Privacy Control 選好 として、当該の 人にとって最も適切だと判断されるように解釈することができます。 特に、その人のプライバシーに対する期待、コンテキスト、および 文化的状況を踏まえて考慮した場合においてです。同様に、ウェブサイトはこのプロトコルの範囲外にある他の選好情報を 利用することがあり得ます。たとえば、サイト固有の個人の選好や 第三者の 登録サービスなどが、その典型例であり、このプロトコルを通じて明示的な選好が表明されていない場合に、挙動を知らせたり調整したりするために利用されることがあります。

ユーザーエージェントはユーザーのプリファレンスをできるだけ正確に伝えることが期待されます。ユーザーエージェントはGlobal Privacy Control値に関し、ユーザーのプリファレンスを最善と信じる内容を表現するよう努めるべきです

3.2 プリファレンスキャッシュ

プリファレンスは各トップレベルナビゲーション時にキャッシュしなければなりません。これにより、ユーザーの「販売・共有拒否」要求の一貫性が保たれます。つまり、プリファレンスがナビゲーション中またはその後に変更された場合、その変更は次回のナビゲーションまで反映されません。

トップレベル閲覧コンテキストは、gpcAtNavigationというブール値を持ちます。初期値はfalseです。

gpcAtNavigationの値は、プリファレンストップレベル閲覧コンテキストアクティブドキュメントのロード開始時にどうだったかを反映しなければなりません。ユーザーのプリファレンスが有効ならtrue、無効または未設定ならfalseです。

プリファレンスが、gpcAtNavigationのキャッシュ値と一致しなくなった場合、ユーザーエージェントはユーザーに不一致タブを通知し、リロードしてキャッシュを最新のプリファレンスに更新する選択肢を提供するべきです

3.3 HTTPリクエストにおけるSec-GPCヘッダーフィールド

Sec-GPCヘッダーフィールドは、HTTPリクエスト(どのリクエストメソッドでも)において、ユーザーの一般的かつ普遍的なプリファレンス販売・共有拒否インタラクション)を表明する仕組みです。場合によっては、特定の合意により、ウェブサイトが一般的なプリファレンスを無視できることがあります(下記§ 5.3や法的・実装ガイド参照)。

このフィールドの構文([ABNF])は次の通りです:

Sec-GPC-field-name  = "Sec-GPC"
Sec-GPC-field-value = "1"

Sec-GPCヘッダーは、トップレベル閲覧コンテキストgpcAtNavigationfalseの場合、ユーザーエージェントは生成してはなりません

Sec-GPCヘッダーは、トップレベル閲覧コンテキストgpcAtNavigationtrueの場合、値が正確に数字の"1"であるフィールド値で生成しなければなりません

1つのHTTPリクエストで、Sec-GPCを複数生成してはなりません。また、HTTPトレイラーで Sec-GPCフィールドを利用してはなりません

Sec-GPCヘッダーを含むHTTPリクエストを処理するサーバーは、フィールド値が正確に"1"でない限り、このヘッダーを無視し、なかったものとしてリクエストを処理しなければなりません。複数の Sec-GPC ヘッダーが存在し、少なくとも1つが"1"であれば、サーバーは1つの"1"があるものとして扱い、それ以外はないものとして扱わなければなりません

HTTP中継者は値が"1"のSec-GPCヘッダーを削除してはいけませんが、他の値の Sec-GPCヘッダーは削除してもよいです。さらに、あるHTTPリクエストの発信者が販売・共有拒否プリファレンスを持つと考えられる場合、中継者はSec-GPCヘッダーを"1"で追加してもよいです。

3.3.1 Sec-GPCフィールド値の拡張性

Sec-GPCは、意図的に拡張メカニズムを持たせていません。過去の同様のヘッダーの経験から、拡張が存在しない場合でも、多くの人が値の存在確認時にパースではなく文字列比較に依存しがちであることが分かっています。このようなチェックは拡張値が存在する場合失敗し、仕組み自体が形骸化します。拡張が必要になった場合は、他のヘッダーで実装され、このヘッダーが置き換えられるかもしれません。

3.4 プリファレンス検出用JavaScriptプロパティ

globalPrivacyControlプロパティは、クライアントサイドスクリプトが、Sec-GPCヘッダーフィールド値が、トップレベル閲覧コンテキストアクティブドキュメントのロード時に送信されたかどうかを判定できるようにします。

WebIDLinterface mixin GlobalPrivacyControl {
  readonly attribute boolean globalPrivacyControl;
};
Navigator includes GlobalPrivacyControl;
WorkerNavigator includes GlobalPrivacyControl;

Sec-GPCヘッダーフィールドが送信されない場合は値がfalse、そうでなければtrueです。

globalPrivacyControlの値は、トップレベル閲覧コンテキストgpcAtNavigationなければなりません

globalPrivacyControlプロパティは、通常のnavigatorオブジェクトおよびワーカーコンテキストの両方で利用でき、navigator.globalPrivacyControlとして参照できます。

4. GPCサポートリソース

サイトは、少なくとも必要な場合にGPCリクエストを遵守していることを示すために、.well-known URLでリソースを提供してもよいです。GPCサポートリソースの目的は、サイトがGlobal Privacy Controlを認識しサポートしていることを伝えることです。サポートリソースは、リソースへアクセスしているユーザーエージェントのGPCリクエストにサイトが従うかどうかを示すものではありません。デフォルトでは、オリジンのサポート状況は不明です。

GPCサポートリソースは、オリジンサーバーのURLに対して/.well-known/gpc.jsonというwell-known識別子を持ちます [RFC8615]。

GPCサポートリソースを対象とする有効なGETリクエストを受信したオリジンサーバーは、下記で定義されるサイト全体のトラッキングステータスを機械可読な表現で含む成功レスポンス、またはそのような表現に導くリダイレクトの連続(サーバーが他オリジンの場合もありうる)のいずれかで応答します。

4.1 GPCサポート表現

オリジンサーバーは、GPCサポートリソースをapplication/jsonメディアタイプ [RFC8259] で有効な表現として返さなければなりません。そうでなければ、オリジンのサポート状況は不明です。

GPCサポート表現はJSONオブジェクトでなければなりません。そうでなければ、オリジンのサポート状況は不明です。下記にないメンバーはこの仕様では意味を持たず無視しなければなりません。メンバーには以下が含まれます:

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

ユーザーのプリファレンスを(HTTPヘッダーフィールドやnavigator オブジェクトで)公開することは、ユーザーを2つのグループに分け、ブラウザやデバイスのフィンガープリント情報を増やす可能性があります。この追加情報は、シグナルが他のシグナルと完全に相関するか、設定変更不可の状態で有効になっていない限り利用可能となります。したがって実装によっては、GPCシグナルがプライバシーコストを課す場合がありますが、それはシグナル送信によるプライバシー利益によって正当化されることを意図しています。

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

本仕様の機能に起因する既知のセキュリティ影響はありません。

8. 自動化

ユーザーエージェントの自動化やアプリケーションテストの目的のため、本ドキュメントでは以下の拡張コマンドを定義します。 [WebDriver]

8.1 グローバル・プライバシー・コントロールの設定

HTTPメソッド URIテンプレート
POST /session/{session id}/privacy

グローバル・プライバシー・コントロールの設定 拡張コマンドは、現在のセッションの販売・共有拒否プリファレンスを変更します。

リモートエンド手順は、sessionURL variablesparameters を与えられたとき:

  1. gpcparametersgpc プロパティとする。

  2. gpc が未定義またはブーリアンでない場合、エラーコードinvalid argumentでエラーを返す。

  3. gpcがtrueなら、このsessionのユーザーのプリファレンスを記録し、ブラウザは販売・共有拒否インタラクションを行う。falseなら行わない。

  4. success を data null で返す。

8.2 グローバル・プライバシー・コントロールの取得

HTTPメソッド URIテンプレート
GET /session/{session id}/privacy

グローバル・プライバシー・コントロールの取得 拡張コマンドは、現在のセッションの販売・共有拒否プリファレンスを返します。

リモートエンド手順は、sessionURL variablesparameters を与えられたとき:

  1. このsessionのユーザーのプリファレンスによってブラウザが販売・共有拒否インタラクションを行う場合、gpc=trueとする。

  2. そうでなければ、gpc=falseとする。

  3. resultを、プロパティ"gpc"がgpcに設定されたJSON Object とする。

  4. success を data result で返す。

9. 適合性

規範的でないと明示されたセクションの他、本仕様中のすべての著者向けガイドライン、図、例、注記は規範的ではありません。それ以外のすべては規範的です。

本ドキュメント中の MAYMUSTMUST NOTSHOULD というキーワードは、 BCP 14 [RFC2119] [RFC8174] で示される通り、大文字すべてで現れる場合にのみその意味で解釈されます。

A. 実装上の注意点

GPCシグナルは、特定のサイトへのすべてのHTTPリクエストに付与されることを考慮する価値があります。ウェブページのレンダリングには、しばしばこのようなリクエストが数十回発生します。そのため、GPCシグナルがすべてのGPCインタラクションごとにコストのかかる監査証跡を伴う本格的なオプトアウト手続きを発動させると、CDNから配信されるリソースも含め、可能な限り効率的に実行されるべき処理に多大な負荷がかかり、非現実的となる可能性があります。

GPCをサポートする意図のある規制は、そのような実装上の困難も考慮することが推奨されます。対策の一例として、サイト上に販売・共有拒否インタラクション プリファレンスを永続化するためのユーザーインターフェースと、ユーザーエージェントが状態を管理する 販売・共有拒否インタラクションシグナルの提供を区別する方法があります。後者の場合、そのインタラクションは、ユーザーが以前に販売・共有拒否インタラクション プリファレンスを要求し、すでにその プリファレンスが有効な状態であるかのように処理できます。

B. 謝辞

この仕様は主に Tracking Protection Working Group および Tracking Preference Expression (DNT) に貢献した他の方々が開発した概念に依拠しています。

C. 参考文献

C.1 規範的参照文献

[ABNF]
構文仕様のための拡張BNF: ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008年1月。インターネット標準。URL: https://www.rfc-editor.org/rfc/rfc5234
[html]
HTML 標準. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG。リビングスタンダード。URL: https://html.spec.whatwg.org/multipage/
[privacy-principles]
プライバシー原則. Robin Berjon; Jeffrey Yasskin. W3C。2025年5月15日。STMT。URL: https://www.w3.org/TR/privacy-principles/
[RFC2119]
RFCで要件レベルを示すためのキーワード. S. Bradner. IETF. 1997年3月。最良の現行慣行。URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
インターネットにおける日付と時刻: タイムスタンプ. G. Klyne; C. Newman. IETF. 2002年7月。提案標準。URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC8174]
RFC2119キーワードにおける大文字と小文字の曖昧さ. B. Leiba. IETF. 2017年5月。最良の現行慣行。URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
JavaScript Object Notation(JSON)データ交換フォーマット. T. Bray, Ed. IETF. 2017年12月。インターネット標準。URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
Well-Known Uniform Resource Identifiers(URIs). M. Nottingham. IETF. 2019年5月。提案標準。URL: https://www.rfc-editor.org/rfc/rfc8615
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C。2026年2月6日。W3C 作業草案。URL: https://www.w3.org/TR/webdriver2/
[webidl]
Web IDL 標準. Edgar Chen; Timothy Gu. WHATWG。リビングスタンダード。URL: https://webidl.spec.whatwg.org/

C.2 参考情報

[CCPA-REGULATIONS]
CCPA 規則. URL: https://www.oag.ca.gov/sites/all/files/agweb/pdfs/privacy/oal-sub-final-text-of-regs.pdf?