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

W3C作業草案

この文書の詳細
この版:
https://www.w3.org/TR/2026/WD-gpc-20260924/
公開されている最新版:
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])を侵害するために悪用されることもあります。データは、 限定された運用目的でサービス プロバイダーと共有できますが、多くのユーザーが好ましくないと考える方法で、 行動ターゲティングのために共有または使用されることもあります。

この懸念に対処するため、世界各地の法域で いくつかの異なる法的枠組みが提案または制定されています。一部のモデルは追跡についてユーザーの同意に依存します。その他の データ最小化の原則に基づくモデルでは、特定のデータ共有または データ処理を全面的に禁止します。

一部の法律や提案では、ユーザーに対して、自らのプライバシーが 保護されるよう要求する権利を付与しています。これには、自らのデータが、やり取りすることを意図した 事業者以外に販売または共有されないよう求める「オプト アウト」要求が含まれます。しかし、訪問するすべてのサイトごとに自らの 権利を手動で表明するよう人々に要求することは非現実的であり、 人々に「プライバシー労働」を 課すことになります ([privacy-principles])。

この仕様は、この最後の種類の法律を対象として設計されており、 HTTPヘッダー またはDOMを通じて、すべてのウェブサイト運営者に対して普遍的に、データの販売を防止するために適用される権利、 データの第三者との共有、およびクロスコンテキスト・ターゲット 広告へのデータ利用を防止する権利を本人が主張するための方法を提供することで、ユーザーの選択を大規模に扱うことの難しさに対処します。このシグナルにより、ユーザーは、これらの グローバル オプトアウト に基づく法律の一部に存在する特定の規定を利用できます。たとえば、個人情報の販売または共有の販売を停止するための California Consumer Privacy Actにおける「オプトアウト選好 シグナル」に関する規定 [CCPA-REGULATIONS]、またはColorado州 およびその他の州の法律にある「ユニバーサル・オプトアウト メカニズム」に関する類似の規定を利用して、ユーザーが自らの情報の販売または 組織横断型ターゲット広告への利用をオプトアウトできるようにします。

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

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

2. 定義

販売または共有を拒否するインタラクションとは、 ウェブサイトとのインタラクションであり、その中で 本人が、自らがやり取りすることを意図する相手以外のいかなる当事者にも自らのデータを販売または共有しないこと、 または自らのデータをクロスコンテキスト広告ターゲティングに使用しないことを要求するものです。 W3Cのプライバシー 原則の用語では、本人は少なくとも、 データ管理者が1つだけ存在すること、 およびそのデータが別の コンテキストで広告ターゲティングに使用されないことを要求しています。その コンテキストが 同じ事業者によって所有されている場合でも同様です。

販売または共有を拒否する選好とは、 本人が 自らのデータを「販売または共有しない」よう 要求することです。たとえば、ユーザーエージェントでGlobal Privacy Control 設定を有効にすることや、そのような設定を既定とするツールを使用することによります(場合によっては、 この設定がそのツールのユーザーの最も一般的な期待に一致するためです)。 設定されている場合、この選好は、本人が 販売または共有を拒否するインタラクションでWebを閲覧することを期待していることを示します。

3. 販売または 共有を 拒否する選好の表明

3.1 表明形式

Global Privacy Controlの選好は、すべてのHTTPリクエスト(HTTPヘッダーの形式) およびすべてのウェブサイト(Web APIプロパティの形式)について伝達されるべきです。

設定されている場合、この選好は、単一の値1、または コンテキストに応じて同等の trueとして表明されます。

規制上、法律上、またはその他の要件がない場合、ウェブサイトは、 表明されたGlobal Privacy Controlの選好を、特に本人のプライバシーへの期待、 コンテキスト、 および文化的事情に照らして、当該本人に最も適切と考える方法で解釈できます。同様に、ウェブサイトは、 このプロトコルの範囲外にあるその他の選好情報、 たとえばサイト固有の本人の選好や 第三者の 登録サービスを利用して、このプロトコルを通じて明示的な選好が 表明されていない場合の動作を決定または調整することもできます。

ユーザーエージェントは、本人の選好を可能な限り正確に伝達することが期待されます。ユーザー エージェントは、Global Privacy Control値に関してユーザーエージェントが本人の 選好であると最も適切に判断したものを表すようSHOULD努めるべきです。

3.2 選好のキャッシュ

本人のデータを「販売または共有しない」という要求の伝達に一貫性を確保するため、 選好は、各 トップレベル ナビゲーションでMUSTキャッシュされなければなりません。これは、トップレベルナビゲーション中またはその後に選好が変更された場合、 次のナビゲーションまでその変更が反映されないことを意味します。

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

gpcAtNavigationの値は、 選好を、 トップレベル 閲覧コンテキストのアクティブ 文書の読み込みが 開始された時点での本人の状態としてMUST反映しなければなりません。 本人の選好が有効であった場合は trueになり、 本人の選好が無効であったか、設定されていなかった場合はfalseになります。

選好が、 トップレベル 閲覧コンテキストにキャッシュされた一部の gpcAtNavigationと整合しないように変更された場合、ユーザーエージェントは、 不整合なタブについてユーザーに通知し、 それらを再読み込みして、キャッシュされたgpcAtNavigationを現在の選好を反映するよう更新する選択肢を提供するようSHOULDすべきです。

3.3 HTTPリクエストの Sec-GPC ヘッダーフィールド

Sec-GPC ヘッダーフィールドは、HTTP リクエスト (任意のリクエストメソッド)において、本人が選好する一般的かつ普遍的な販売または共有を拒否するインタラクションを表明するための仕組みです。 場合によっては、その本人との特定の取り決めにより、ウェブサイトが一般的に適用される選好を無視することが認められる場合があります(以下の§ 5.3および 法的および実装上の 考慮事項ガイドを参照してください)。

このフィールドの構文([ABNF])は次のとおりです。

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

トップレベル 閲覧コンテキストの gpcAtNavigationがfalseの場合、ユーザーエージェントは Sec-GPC ヘッダーフィールドを生成してはMUST NOTなりません。

トップレベル 閲覧コンテキストの gpcAtNavigationがtrueの場合、ユーザーエージェントは、 フィールド値が数値文字「1」と正確に一致する Sec-GPC ヘッダーフィールドを生成するMUST必要があります。

ユーザーエージェントは、特定のHTTP リクエスト内で複数の Sec-GPC を生成してはMUST NOTならず、 HTTPトレーラーで Sec-GPC フィールドを使用してもMUST NOTなりません。

Sec-GPC ヘッダーを含むHTTPリクエストを処理するサーバーは、 フィールド値が文字「1」と正確に一致しない限り、そのヘッダーを無視し、 そのヘッダーが指定されていなかったかのようにリクエストを処理するMUST必要があります。複数の Sec-GPC ヘッダーがあり、そのうち少なくとも1つのフィールド値が正確に「1」である場合、サーバーは リクエストを、 フィールド値が 「1」である Sec-GPC ヘッダーが1つだけ存在するかのように扱うMUST必要があります。それ以外の場合は、ヘッダーが存在しないものとして扱います。

HTTP中継者は、「1」に設定された Sec-GPC ヘッダーを削除してはMUST NOTなりませんが、 その他の値を含む Sec-GPC ヘッダーは削除してもMAYかまいません。さらに、特定のHTTP リクエストを発信したそのその本人が販売または共有を拒否する選好を持っていると考える理由があるHTTP中継者は、 「1」に設定された Sec-GPC ヘッダーを挿入してもMAYかまいません。

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であるMUST必要があります。

globalPrivacyControl プロパティは、 通常のコンテキストとワーカーコンテキストの両方で navigatorオブジェクトから利用できるため、 navigator.globalPrivacyControlから読み取ることで確認できます。

4. GPCサポートリソース

オリジンは、少なくともそうすることが要求される場合に、 GPCリクエストに従うことを表すため、.well-known URLにリソースを生成してもMAYかまいません。GPCサポートリソースの目的は、 オリジンから提供されるページにおいてGlobal Privacy Controlを認識し、 サポートしていることをオリジンが伝えることです。 サポートリソースは、そのリソースにアクセスするユーザーエージェントからのGPC リクエストにオリジンが従うかどうかを伝えることを意図していません。 既定では、オリジンのサポート状況は不明です。

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

GPCサポートリソースを対象とする有効なGETリクエストを受信したオリジンサーバーは、 オリジンから提供されるページがどのようにGPCを尊重するかについて機械可読な表現を含む正常なレスポンス、 またはそのような表現へと導く一連のリダイレクト (別のオリジンにあるサーバーが提供してもMAYかまいません) のいずれかで応答します。

4.1 GPCサポート表現

オリジンサーバーは、 application/jsonメディアタイプ[RFC8259]を使用した有効な 表現としてGPCサポートリソースを返すMUST必要があります。それ以外の場合、 オリジンのサポート状況は 不明です。

GPCサポート表現は JSONオブジェクトであるMUST必要があります。それ以外の場合、 オリジンのサポート状況は不明です。このJSONオブジェクトに含まれる、以下の一覧にないメンバーは、 この仕様では意味を持たず、無視するMUST必要があります。メンバーには次が含まれます。

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

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

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

この仕様の機能による既知のセキュリティ上の影響はありません。

8. 自動化

ユーザーエージェントの自動化およびアプリケーションテストを目的として、この文書では、 次の拡張コマンドを定義します。[WebDriver]

8.1 Global Privacy Controlを設定する

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

Global Privacy Controlを設定する拡張コマンドは、現在のセッションに対する 販売または共有を拒否する選好を変更し、 更新された設定を 返します。

リモートエンドの 手順は、 session、URL variables、 parametersが与えられた場合、次のとおりです。

  1. gpcを、parametersのプロパティgpcとします。

  2. gpcがundefinedであるかbooleanでない場合、エラーコードinvalid argumentのエラーを返します。

  3. このsessionについてユーザーの選好を記録し、 gpcがtrueの場合、ブラウザーが 販売または共有を拒否するインタラクションを 実行し、 gpcがfalseの場合、 販売または共有を拒否するインタラクションを実行しないようにします。

  4. resultを、プロパティ「gpc」がgpcに設定されたJSON Object とします。

  5. データ resultを伴う成功を 返します。

8.2 Global Privacy Controlを取得する

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

Global Privacy Controlを取得する拡張コマンドは、現在のセッションに対する 販売または共有を拒否する選好を返します。

リモートエンドの 手順は、 session、URL variables、 parametersが与えられた場合、次のとおりです。

  1. このsessionについてのユーザーの選好により、 ブラウザーが 販売または共有を拒否するインタラクションを実行する場合、 gpcをtrueとします。

  2. それ以外の場合、gpcをfalseとします。

  3. resultを、プロパティ「gpc」がgpcに設定されたJSON Object とします。

  4. データ resultを伴う成功を 返します。

9. 適合性

非規範的と明示されているセクションに加えて、この仕様に含まれるすべてのオーサリングガイドライン、図、例、および注記は 非規範的です。この仕様のそれ以外のすべては規範的です。

この文書のキーワードMAY、MUST、MUST NOT、および SHOULDは、 ここに示すようにすべて 大文字で記述されている場合に限り、 BCP 14 [RFC2119] [RFC8174] に記載されているとおりに解釈されます。

A. 実装上の考慮事項

GPCシグナルは、特定のサイトに対して行われるすべてのHTTPリクエストに 付加されることを考慮する価値があります。Web上でページをレンダリングするには、多くの場合、そのようなリクエストを数十回行う必要があります。そのため、 GPCとのインタラクションのたびに、コストの高い監査証跡を伴う本格的なオプトアウト手続を GPCシグナルによって開始することは非現実的となり得ます。これは、 可能な限り効率的に実行する必要があるコンテンツ配信ネットワーク(CDN)から提供されるリソースを含め、 大量の処理を発生させるためです。

GPCをサポートすることを意図する規制では、このような実装上の 困難を考慮することが推奨されます。これらに対処する方法の1つは、サイト上に保持される 販売または共有を拒否するインタラクションの 選好を要求する目的で人々に提供されるユーザーインターフェイス上の操作手段と、 ユーザーエージェントによって状態が保持される 販売または共有を拒否するインタラクションのシグナルの提供とを 区別することです。後者の場合、そのインタラクションは、 本人が以前にそのような販売または共有を拒否する インタラクションの選好を要求しており、 その選好がすでに有効な状態でインタラクションしているかのように処理できます。

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/info/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/info/rfc2119/
[RFC3339]
インターネット上の日付と時刻: タイムスタンプ. G. Klyne; C. Newman. IETF. 2002年7月. 提案標準. URL: https://www.rfc-editor.org/info/rfc3339/
[RFC8174]
RFC 2119のキーワードにおける大文字と小文字の 曖昧さ. B. Leiba. IETF. 2017年5月. 現行のベストプラクティス. URL: https://www.rfc-editor.org/info/rfc8174/
[RFC8259]
JavaScript Object Notation (JSON) データ 交換形式. T. Bray, Ed. IETF. 2017年12月. インターネット標準. URL: https://www.rfc-editor.org/info/rfc8259/
[RFC8615]
Well-Known Uniform Resource Identifier (URI). M. Nottingham. IETF. 2019年5月. 提案標準. URL: https://www.rfc-editor.org/info/rfc8615/
[WebDriver]
WebDriver. Simon Stewart; David Burns. W3C. 2026年 7月2日. 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?