Intent to Prototype: Global Privacy Control

[Maciej Czarnecki]

Contact emails

mccz...@gmail.com

Specification

https://w3c.github.io/gpc

Summary

Implementation of Global Privacy Control (GPC) signal to enable users to communicate their preference for privacy protection across websites. This feature implements the W3C GPC specification (https://github.com/w3c/gpc/blob/main/explainer.md) and includes: (1) a user preference setting to enable the Global Privacy Control signal, (2) automatic transmission of the Sec-GPC HTTP header with a value of "1" on all outgoing requests when enabled, and (3) JavaScript API exposure via the navigator.globalPrivacyControl property allowing websites to detect the user's GPC preference. When enabled, this signal indicates the user's request to limit the sale or sharing of their personal information with third parties.

Blink component

Blink>Loader

Web Feature ID

gpc

Motivation

The signal is already implemented by other browsers and Chrome should catch-up with this privacy setting. This year California signed a bill under the CCPA/CPRA that obligates the browsers to provide ability to communicate do-not-sell-or-share preference before 2027. Currently, Chrome allows to send GPC header only via an extension which may be not sufficient to be compliant with the bill.

Initial public proposal

No information provided

Search tags

gpc, global privacy control, Sec-GPC, CCPA, CPRA

Requires code in //chrome?

False

Tracking bug

https://issues.chromium.org/issues/40745270

Estimated milestones

No milestones specified

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5137324344213504?gate=5161638758055936

This intent message was generated by Chrome Platform Status.

[Maciej Czarnecki]

CL with initial implementation:
https://chromium-review.googlesource.com/c/chromium/src/+/7319383

It has no user-facing settings, as I would need some decisions in regards of the place it should be put and its labels. Also Do-Not-Track toggle has a modal with an explanation what it does. Should GPC has it as well?

[Mike West]

I think prototyping a GPC implementation in the Blink and //content layers of Chromium is quite reasonable. A number of embedders implement the feature, and shifting those to a common implementation would likely be best for the project at large. Have you talked to any other Chromium based browsers about their implementations? It would be ideal to ensure that the implementation we land on is compatible to the extent reasonable with existing implementations (e.g. global flag vs content setting if any embedders have chosen to allow users to make more granular decisions about the scope of the signal).

That said, you raise some important questions about the UX, both in terms of the settings necessary and the explanatory text around them. It seems likely that different embedders will make different decisions about how the feature should be represented to users, and that those decisions could be interpreted as having legal and policy implications. I'd suggest that it would be best to allow each embedder to implement their own settings and explanations for the moment rather than baking one interpretation into //chrome.

Thanks for taking this on!

-mike

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2b54581d-fae3-4909-b2d8-55411fbe7dben%40chromium.org.

[Shivan Sahib]

Thanks for doing this!

On Thu, Jan 8, 2026 at 1:02 PM Mike West <mk...@chromium.org> wrote:

I think prototyping a GPC implementation in the Blink and //content layers of Chromium is quite reasonable. A number of embedders implement the feature, and shifting those to a common implementation would likely be best for the project at large. Have you talked to any other Chromium based browsers about their implementations? It would be ideal to ensure that the implementation we land on is compatible to the extent reasonable with existing implementations (e.g. global flag vs content setting if any embedders have chosen to allow users to make more granular decisions about the scope of the signal).

Just chiming in case it's helpful, this is the pull request that added GPC support in Brave: https://github.com/brave/brave-core/pull/6743/. There were a couple of follow-ups, an important one being exposing navigator.globalPrivacyControl to workers: https://github.com/brave/brave-core/pull/17474.

The HTTP header implementation was done using a network delegate helper: https://github.com/brave/brave-core/blob/master/browser/net/global_privacy_control_network_delegate_helper.cc. This was all back in 2020 though so probable that best practices have changed. 

 

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAoq_usTaF3cDvXh%2BUsgsjd1dLF4fzbB__F%2B26K%3DYhr4MwHMGg%40mail.gmail.com.

[Maciej Czarnecki]

Hello,

Thank you for your input! I’ve checked implementations in 2 Chromium-based browsers - Brave and Cromite (via this patch) and wanted to share some observations regarding the current prototype. Disclaimer: I don't know what chromium-based projects are the most important. I picked browsers, because I was able to quickly find the implementation on their side.

1. Preference Naming & Consistency There seems to be a divergence in how the setting is keyed:

• Brave: brave.global_privacy_control_enabled

• Cromite: enable_gpc

• Current Prototype: enable_global_privacy_control

So if there is no one key that we can follow, I recommend sticking with the unfolded `enable_global_privacy_control`. This maintains consistency with existing `enable_do_not_track` and avoids ambiguity caused by the acronym.

2. Default State Considerations Brave and Cromite ship with GPC enabled by default. While this aligns with their privacy-first positioning, I’m curious if there has been any internal discussion regarding the default state for Chromium. Given that a default-on status has a significant impact on the advertising ecosystem, I don't know how much the project is dependent on Google's decisions. On the other hand, having it enabled by default may align with privacysandbox.google.com

3. Blink Module Implementation Regarding the IDL and Blink module structure:

• The prototype’s attribute name `globalPrivacyControl` align well with Brave and Cromite implementations, which should help with web compat.

• However, I noticed a discrepancy in the ImplementedAs value: The current prototype uses `NavigatorGlobalPrivacyControl`, whereas Brave/Cromite use `GlobalPrivacyControl`. I will modify the prototype to match other implementations.

Link to the prototype:
https://chromium-review.googlesource.com/c/chromium/src/+/7319383 

As it's my first time working on an "intent to prototype", I would be very grateful for any guidance on what I should focus on.