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

W3C作業草案

このドキュメントの詳細
このバージョン:
https://www.w3.org/TR/2025/WD-gpc-20250916/
最新公開バージョン:
https://www.w3.org/TR/gpc/
最新エディタドラフト:
https://w3c.github.io/gpc/
履歴:
https://www.w3.org/standards/history/gpc/
コミット履歴
編集者:
Sebastian ZimmeckWesleyan大学
Peter SnyderBrave Software
Justin BrookmanConsumer Reports
Aram Zucker-ScharffThe Washington Post
以前の編集者:
Robin BerjonProtocol Labs)(The New York Times(2022年9月まで))
Ashkan Soltani独立
David HarbageDuckDuckGo
フィードバック:
GitHub w3c/gpcプルリクエスト新規イシューオープンイシュー

要約

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

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

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

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

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

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

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

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

1. はじめに

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

今日ウェブサイトを構築する際、多くの場合、ユーザーが直接関わる事業者以外の企業が提供するサービスに依存しています。これは、Web技術の複雑化とサービス間の分業化が進んだ結果です。このアーキテクチャはWeb体験を向上させるために利用できる一方で、プライバシーの侵害にも悪用される可能性があります([privacy-principles])。データは限定的な運用目的でサービスプロバイダーと共有される場合もありますが、多くのユーザーが好ましく思わない行動ターゲティングのために共有・利用されることもあります。

この問題に対処するため、世界各国の法域でさまざまな法的枠組みが提案・施行されています。あるモデルはトラッキングについてユーザーの同意に依存し、他のモデルはデータ最小化原則に基づき、特定のデータ共有や処理自体を禁止しています。

一部の法律や提案は、ユーザーが自身のプライバシー保護を要求できる権利、つまりデータが意図した事業者以外に販売・共有されないように「オプトアウト」要求を出す権利を認めています。しかし、訪れる全てのサイトで毎回手動で権利を行使するのは非現実的であり、ユーザーに「プライバシー労働」を強いることになります([privacy-principles])。

本仕様はこの最後のカテゴリーの法律を念頭に設計されており、HTTPヘッダーまたはDOMを通じて、ユーザーが自身の権利を普遍的にウェブサイト運営者に示す方法を提供することで、ユーザー選択のスケールの難しさを解決します。これにより、データの販売や第三者との共有、クロスコンテキストターゲティング広告での利用を防ぐ権利を主張できます。このシグナルにより、例えばカリフォルニア消費者プライバシー法(CCPA)の「オプトアウトプリファレンスシグナル」に関する条項[CCPA-REGULATIONS]や、コロラド州その他の「ユニバーサルオプトアウトメカニズム」等の法律に基づき、個人情報の販売やターゲット広告の利用を停止することができます。

本仕様は、規制モデルやクロスコンテキストトラッキングそのもの、また同意やデータ最小化に基づく他モデルを推奨・否定するものではありません。特定の法域でユーザーに与えられた積極的権利を行使可能にすることを目的としています。

2. 用語の定義

販売・共有拒否インタラクションとは、ユーザーが自身のデータを、意図した相手以外の第三者に販売または共有しないよう、あるいはクロスコンテキスト広告ターゲティングに利用しないよう、法律で認められる場合を除き要求するウェブサイトとのやり取りのことです。

販売・共有拒否プリファレンスとは、例えばユーザーエージェントで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 null で返す。

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]
Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed.; P. Overell. IETF. 2008年1月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[html]
HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. 1997年3月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
[RFC3339]
Date and Time on the Internet: Timestamps. G. Klyne; C. Newman. IETF. 2002年7月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3339
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. 2017年5月. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
[RFC8259]
The JavaScript Object Notation (JSON) Data Interchange Format. T. Bray, Ed. IETF. 2017年12月. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc8259
[RFC8615]
Well-Known Uniform Resource Identifiers (URIs). M. Nottingham. IETF. 2019年5月. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc8615
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 2018年6月5日. W3C 勧告. URL: https://www.w3.org/TR/webdriver1/
[webidl]
Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. 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?
[privacy-principles]
プライバシー原則. Robin Berjon; Jeffrey Yasskin. W3C. 2025年5月15日. STMT. URL: https://www.w3.org/TR/privacy-principles/